What to do with user stories whose technical or functional feasibility is uncertain or at risk?
It happens sometimes, when facing projects that will use new technologies, architectural approaches, new processes that the team feels a bit scared, worried, but it decides to not be open with the Product Owner.
This mostly because of a sort of fear to fail or to be judged incompetent.
This lack of transparency between the team and the Product Owner leads inevitably to problems with the estimations and the execution of the work involved.
Estimations will grow up, because of the uncertainty and the contingency the team will add for sure to the estimation itself.
Furthermore, because of the exploratory activity the team must do to understand how to implement such a feature and the fact that the time passes inexorably, it could happen that the final way chosen for the implementation, is not the right one, putting at risk the completion of the entire story and hence the whole sprint goal.
However, in a healthy agile environment, the team freely admits its lack of knowledge, allowing everyone to reason about how to manage the related risks associated.
In these cases Spikes are great tools/techniques to use. But, before to start using spikes, it is necessary to take into account some preconditions:
- the user story the Product Owner is presenting must be clear in terms of business value to be achieved,
- the acceptance criteria for that story must exist and well described. The team must absolutely and clearly know, when they will reach the top of the mountain,
- as already mentioned above, transparency is mandatory.
A spike is used to lower the risk of a story and to avoid any undesirable surprise.
Let’s say, for example, that the Product Owner presents a story that helps the user of an e-commerce platform, to buy a product via credit card and, afterwards, it starts a rich communication with external systems through dedicated services.
Such as internal accounting systems to query in order to create the invoice, delivering of the shipping note, updating the warehouse stocks, create ad-hoc reports for management and so forth.
Suppose also that the team can manage credit card transitions, but it is not aware of the internal systems, services exposed, interfaces and related behaviors. What can you do?
If the PO asks for an estimate right now, the team probably protects itself adding lots of contingency.
A really effective approach, however, is to create a new story (a spike) only for the obscure side of the story, in order to explore and check it and verify the feasibility.
This should lower the risks associated with the story, by making assumptions that the spike will verify, and let the team be more confident on the estimation and the work to be done.
In order to be really effective on approaching to a spike, it is very important to stick to some basic guidelines:
- Max time duration
- Reusability of the code developed for the spike, is not strictly mandatory
- Test End-to-End feasibility
- Spike planning
- Be open to change
Max time duration
Remember, the spike needs to be an effective way of dissolving the fog in front of a technical/functional solution. You have to be completely focused only on that, avoiding any distractions and not be worried on writing clean refactored code, ready to be reused (see next point). You just need to find and test the solution as soon as possible.
Obviously the time you will spend on that could vary on the difficulties, but what I suggest is to plan no more than one day (two days at most) for each spike.
If your spike needs more time, decompose it in more “spikes”.
Reusability of what done is not mandatory
Like we were novice programmer and we were experimenting, we understood we were successful when the screen finally printed: “Hello world!‘.
It didn’t matter, initially, what was the quality of the code we wrote, because we were only interested to see weather we were able to do it or not.
A spike follows the same rule: it is not important to spend time in refactoring the code or following the rules of a good Object Oriented Programming. What does matter is to see if it works. Remember we have just a couple of days available!
We will have, afterwards, the necessary time to write clean code, according to the exploration just done, when implementing the real story.
We must be ready to throw away what we’ve done once we proved it works, rewriting it from the beginning in the right way.
End-to-End feasibility
When planning for a spike you have to define exactly what the boundaries within which, the spike will work.
What the technology to use? Who will call the spike giving input? And to whom the spike will be supply it output? How many systems to call? What about the interfaces to call? Is the services signature already fixed? What the data? And so on. Then you must identify the right sequence of steps to execute.
Finally, you are ready to functional test the End-to-End feasibility of your spike.
Spike planning
A spike brings with it the uncertainty and the risks of the original story.
One rule of thumb is to anticipate the spike at least of one sprint than the parent business story.
This to avoid a situation where the spike is not successful for any reason, putting at risk the entire sprint goal.
Be open to change
It could happen that the spike proves that there’s no feasibility. The story cannot be completed that way.
The PO here should change the story and its business value according to what has been discovered during the spike.
Spikes bring with them better information about a risk or opportunity,
This is the reason why, the iterative and incremental approach of product development, combined with spike techniques, is one of the most powerful and effective risk management approach.
