committing while discovering

One of the more common themes that I come across while working with teams is the question of “how can we make a sprint commitment if we are still discovering how to solve for a story or set of stories”.

This is a great question. I may have lost some of you already due to my use of commitment and scrum in the same sentence 🙂

Hang with me if you will for a moment and then share your thoughts.

First a bit about my perspective on commitment and scrum: I feel that making a commitment in scrum helps to maintain transparency for both the delivery teams and also the stakeholders.  I think that Scrum has a great tool in the use of both velocity and story points. Story points are an entirely nebulous unit of measurement that is usually derived from a combination of (1) complexity, (2) time, and (3) uncertainty or risk. Velocity is the average number of story points a team is able to complete during a normal sprint.  So, the team’s velocity reflects how many of these points a team can usually complete within their next sprint, or their capacity.

I coach teams that they will usually need to look at a story roughly 3 times (or more) before it is committed to as part of a sprint. This usually takes place during regular backlog refinement sessions and then finally during the sprint planning session. During these sessions, if the team feels there is a lot of uncertainty around “how” the story will be fulfilled the points for the story should be relatively higher that it would be had the uncertainty been low. This could mean that a story that would have been rated as “5 points” if there were low uncertainty may now be ranked as an 8, 13, 20 or even 40 now depending on how large the uncertainty is.

So, given all of this, how do I answer the initial question of “how can we make a sprint commitment if we are still discovering how to solve for a story or set of stories”?

I generally advise teams not to take on stories that are larger than an 8 or 13 (depending on the relative sizes of their stories) into their sprint. If the uncertainty is high enough that they are not able to take the story in, then I will typically recommend that they try to split out the uncertainty from the story in the form of new risk stories. The original story will then be made dependent on the new risk stories. Each of these risk stories will then have a specific question or concern that needs to be clarified. The team can then decide if this clarification will take place as a part of a backlog refining session or if they are comfortable allocating a portion of the sprint’s capacity towards answer/resolving the risk. Once resolved, the original story is unblocked and allowed into the next sprint.

Thoughts?

Thanks!