Skip to main content

Saved Posts

Scrum: Committing While Discovering

Isaac Hogue
Reading: Scrum: Committing While Discovering

towingicebergOne 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 than 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 decide if this clarification will take place as 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!

Next How Do I Prioritize Work?

Isaac is an Enterprise Agile Coach with LeadingAgile. Prior to joining LeadingAgile he served in various leadership roles across both product management and research & development organizations.

Comments (4)

  1. Lindsay
    Reply

    For the most part, I agree with this approach. When a lot of uncertainty exists around a certain story or task, I prefer my teams create a “research” story that allows them to dive in and find answers to alleviate most of the uncertainty before actually taking on the “work.” It’s my feeling that a team cannot possibly give an accurate estimate on a card if they have no idea what the actual work might entail. We try to incorporate some research stories into each sprint so that we always have time set aside to learn a “sprint ahead.”

    Reply
    • Isaac Hogue
      Reply

      Hi Lindsay, that’s a great approach and it probably provides a lot of clarity for both the business and the teams.

      Reply
  2. Rusty Divine
    Reply

    In the last year my team has done two or three 13 point stories, we almost always break them down into smaller stories when they get that big.

    Cases where we’ve done big points have been a messy refactoring that had to be all-or-nothing and some major business analysis we knew would take most/all of an iteration.

    Reply
    • Isaac Hogue
      Reply

      Hi Rusty! Thanks for reading and sharing your experiences. Do you have a limit within the teams where you generally draw the line? Based on this experience I would be tempted to recommend the line be drawn at 8 for your teams and would even likely consider drawing the line a little bit lower towards a 5 depending on how well the teams performed with 8 point stories.

      Reply

Leave a comment

Your email address will not be published. Required fields are marked *