User stories and story points in the middle of the sprint
I have a user story that I am working. I'm realizing, four days into the sprint, that one story ought to have been decomposed further during sprint planning. I committed to having the work done by the end of the sprint, but there are roadblocks on one part of the story that mean I know it cannot be completed. It also means that I can't show the parts that are all the way done as the sprint progresses, so the scrummaster is hyperventilating that we're four days in and our burndown is nowhere near perfect.
Nothing in my training explains what to do in this situation.
What I want to do is 1) decompose the story and 2) update the story points to reflect what I know now, then 3) work the stories.
Is there a better approach recommended by Scrum.org or other persons' experience?
What I want to do is 1) decompose the story and 2) update the story points to reflect what I know now, then 3) work the stories.
@Katharyn Bine, The approach you suggested above is perhaps the truest form of Inspection and Adaptation. I am assuming you are part of the Development Team and this is an item in your Sprint Backlog. As a result what you've expressed is perfectly in line with what Scrum teaches. Here's the excerpt from the Scrum Guide.
The Development Team modifies the Sprint Backlog throughout the Sprint, and the Sprint Backlog emerges during the Sprint. This emergence occurs as the Development Team works through the plan and learns more about the work needed to achieve the Sprint Goal.
A few areas to consider improving would be to use backlog refinement to decompose stories. Since you discovered this mid Sprint, you may want to make the issue transparent to the Product Owner and check if some of the scope can be removed and if the Sprint Goal can still remain intact. Finally, utilize the Retrospective to bring transparency over the issue you faced and how you and the team can prevent such issues in the future.
Hope that helps.
PS: Scrum does not state that you have to use a burn down and burn down whilst useful has its disadvantages too, especially if it is being used in an electronic tool. Also a burn down cannot be perfect, unless you want it to be (if you understand what I mean)
Thanks Steve. The short term fix I want to do within the scope of the sprint--decompose the story, assign story points to the separate stories, declare victory on the parts I can, work to complete all the parts by the end of the sprint--seems like the best available option. The burndown will look a bit odd but we've got an explanation and solution for avoiding it in future.
Agreed, our team needs to spend more time decomposing stories during backlog refinement and sprint planning.
I'll add it to the list of things to discuss during the futurespective (because I like focusing on what we're going to do in the next sprint rather than focusing on what went sideways in the past one).
The burndown will look a bit odd but we've got an explanation and solution for avoiding it in future.
@Katharyn Bine, Once again, consider if you want to focus on how the burn down chart looks like or the outcomes of the Sprint.
The first thing that stands out to me is that neither individuals nor the team should be committing to having work done by the end of the Sprint. Instead, the team should commit to the Sprint Goal that is established as part of the Sprint Planning. A portion of the selected Product Backlog Items for the Sprint are most likely related to the Sprint Goal, but the goal should not be to simply to work but deliver value and enable outcomes for stakeholders.
If, by the inability to complete a particular piece of work, the Sprint Goal is in jeopardy, the Product Owner should be brought in. Often, achieving the Sprint Goal is what stakeholders are most interested in. If this goal is at risk, the Product Owner can help figure out the best way to either manage stakeholder expectations or to adjust the work to still meet some aspects of the goal. However, if this work is not related to the Sprint Goal, make sure the goal takes priority and this can be a lesson to discuss in the Sprint Retrospective to figure out how to better slice or decompose the work and appropriate plan it should something similar happen in the future.
Likewise, the idea that the Scrum Master is "hyperventilating" over the burndown is also telling. Again, the focus should be on the Sprint Goal and not the work. The burndown can be a useful tool for visually indicating if there are roadblocks or impediments. However, the burndown chart measures output, and not value and outcomes.
As far as restimating goes, I don't think it's that big of a deal. I prefer not to reestimate and talk, in the Sprint Retrospective, about what went wrong and what can be improved when refining, estimating, and planning the work. Playing around with estimates after the fact is, in my opinion, wasteful and your time and energy is best spent executing the work and working toward the Sprint Goal.
Have the team been involved in finding a solution to this, and in any replanning and re-estimation of work?