Dealing with uncertainity when sizing stories. Spikes or bigger user story size?

I think everything you suggested is a valid approach.  Spike's purpose is to learn more about something in order for it to become ready for a Sprint.  But you should always be willing to move forward on things with a bit of uncertainty because you will never know everything before you start. Especially with junior developers they need to learn that new information will be gained as work begins.  This is something that senior developers and development managers need to help them learn. 

I suggest that you keep doing what you are and help them learn that you start working on stories when you know enough not when you know it all.  Also for your Spikes, don't point but do provide a timebox.  For example put a 3 hour timebox on the work for a specific Spike.  When that timebox is reached, discussion on whether more time would be valuable should occur with the entire time.  That way it isn't just hanging out there all Sprint. They will need to show progress and discuss just as if this was a normal user story.

Or when we size we should take into account a certain degree of uncertainity? Therefore if there is more uncertainity, the story size should be bigger?

Wouldn’t you take uncertainty into account anyway, even with a more experienced team? Wouldn’t you be comfortable doing so, and have no desire to falsely pad out the size of an item?

The fact that the team is (primarily) composed of junior developers is not very relevant to the problem. Uncertainty exists in many different types of efforts, and coping with this uncertainty is a strength of agility and the Scrum framework. What may change, however, is what the team is uncertain about.

As far as the idea of Spikes goes, I find it equivalent to Product Backlog Refinement. The Scrum Guide recommends allocating about 10% of the Development Team's capacity to Product Backlog Refinement. However, nothing is really said about how to go about refinement. Spikes are just one way, out of many, for a team to identify and organize around the refinement that needs to happen in order to ensure that Product Backlog Items are sufficient enough for a Sprint Planning.

I'd also point out that, unlike other events, the 10% capacity for refinement-related work is not a timebox. The amount of time spent on refinement is going to vary Sprint-by-Sprint and team-by-team. If there are lots of unknowns and uncertainty, I would expect more time in refinement until there's a good chunk of the Product Backlog that's well understood and ready to be worked on by the Development Team.

Hi Daniel Wilhite, 

Thank you very much for your input.

I suggest that you keep doing what you are and help them learn that you start working on stories when you know enough not when you know it all

I find this very useful, in practice it is very easy to fall in this misunderstanding and that they use the spike story to solve the whole case instead of learning "just enough" to size the real user story on order to work on it for next sprint. 

The time-box solution on 3 hours time-box which has to be renewed or not after reporting on status also sounds quite practical in real life, so it can be shown progress during the sprint.

Thanks for those tips, very useful. 

Hi Ian Mitchel,

Thank you! Yes, now I have concluded I that a certain level of uncertainty should be included when we size the story. The problem is when the team members are not sure the technical solution path they would take and the uncertainty is too great to give a number and therefore the use of spikes. But they are tricky, sometimes the developers could use the spike to solve the whole issue instead of get just enough knowledge to size the case. 

I would then try to limit the use of spikes just for those cases where the uncertainty is too great and not use it always. A “certain level” of uncertainty should be accepted on the story and include it when we size it. According to Mike Cohn when we size we should take into account: amount of work, risk/uncertainty and complexity. Any of these factors would give more points since the effort is bigger. So the investigation part would be part of the story and not on a separate spike on those cases... 

But as I said if uncertainty is too great maybe we could justify the use of spikes and limit it in a way that the developer will not use it to solve the whole case 

Would you agree with this? Or maybe other thoughts? 

Hi Thomas Owen

Thank you so much for you input. I agree with you that spike is a form of refinement. But if we do not time box it, how can we be sure that will not pass the 10% of the capacity of the team? 

In our case the uncertainty is not about acceptance criteria or requirements since we have pre established refinement meetings with the  PO to ask for this.. but it is after in how to solve it technically in order to size.. 

Anyway, if there is more time used in a technical refinement then it is a good way to justify a decrease in velocity. 

The good thing about spikes is that the developer can show it in the Scrum board on stand up that has an spike or investigation task on him/her and can justify the work that is doing at the time. 

As I said above, the downside of the spike according to my experience so far, at least in this type of technical uncertainty,  is to prevent that the developer does not end up solving the whole case in the spike instead of using it to learn just enough to accomplish a certain comfortable level of uncertainty in order to do a size and work on the real user story..

I agree with you that spike is a form of refinement. But if we do not time box it, how can we be sure that will not pass the 10% of the capacity of the team?

You don't, and you don't have to worry about it. Unlike the other Scrum events, refinement is not a timeboxed activity. The current iteration of the Scrum Guide states that "Refinement usually consumes no more than 10% of the capacity of the Development Team". Personally, I would consider two or more Sprints where the amount of time spent performing Refinement was lower than 10% to be something worth talking about with the team. It's OK to spend more time refining, as long as the team is delivering valuable work over the course of the Sprint. I'm not sure it's easy to quantify a maximum threshold that would cause me to start to worry about the team - I'd have to think about that some more.

In our case the uncertainty is not about acceptance criteria or requirements since we have pre established refinement meetings with the  PO to ask for this.. but it is after in how to solve it technically in order to size.. 

Anyway, if there is more time used in a technical refinement then it is a good way to justify a decrease in velocity.

I'm not sure I would consider this refinement. This feels more like design work. This is totally internal to the team and the Product Owner and stakeholders don't need to be involved in order to solve the problem technically. However, without being there, I can't say for sure. I'd be curious to know why there is so much uncertainty in the technical direction to complete the work.

The only case that I can think of where this is true is where you are considering introducing new technical decisions that the whole team isn't familiar with. An example from software may be a new programming language, library, tool, or framework. Perhaps there's one person on the team familiar enough with the technology to be able to suggest it as a viable solution, but other members of the team need to allocate specific time to learn and maybe prototype this technology to ensure that it is a correct decision before incorporating the work into the deliverable product and making it available for stakeholders to use.

The good thing about spikes is that the developer can show it in the Scrum board on stand up that has an spike or investigation task on him/her and can justify the work that is doing at the time. 

As I said above, the downside of the spike according to my experience so far, at least in this type of technical uncertainty,  is to prevent that the developer does not end up solving the whole case in the spike instead of using it to learn just enough to accomplish a certain comfortable level of uncertainty in order to do a size and work on the real user story..

I'd want to dig deeper in why there's so much technical "refinement" happening and address that. Refinement should be more about what to build. That should give the team enough information to size it and figure out how to build it as part of Sprint Planning and continuously refine the details of how to build it throughout the Sprint.

This could be indicative of the team trying to do a big design up front instead of more iterative and incremental design approaches, but I don't have enough details at this point in time.

The good thing about spikes is that the developer can show it in the Scrum board on stand up that has a spike or investigation task on him/her and can justify the work that is doing at the time. 

one of the other ways to handle this spike is to create a Sprint - with the Sprint goal as for example: Finalise the DB schema or architecture design or tech - decisions for the next sprint xxx"



this way the acceptance criteria for this sprint could be" have enough to build the story xxx" this way it's time boxed and there is a visibility on the board on the work being done, and the team will just do enough to keep it going with the details required not solving the next sprint