Recently, I answered a question about how to do the story point accounting when a user story spans multiple sprints. The scrum team had several user stories that were started in sprint one, but completed in sprint two. Since velocity is a measure of the rate at which the team is delivering stories, we found it best to count all the points for a story in the sprint in which it is completed.
Now let’s examine the question from the point of view of a scrum master. A scrum master’s job is to help the team improve and progress toward the goal of becoming a continuously-improving, high-performing, self-organizing, possibly-over-hyphenated scrum team.
The question is being asked because the team members are feeling some pain. They have worked hard on four stories, but only completed one. This doesn’t feel good and they are looking for a way to alleviate the pain. The quick fix is an accounting trick to give the team ‘credit’ for working on, but not delivering, their stories. This only accommodates the team’s dysfunction. A scrum master will want to help the team find and fix the root causes of the pain. In this way, they may fix the problem instead of perpetuating it.
Common root causes are:
- The stories are too big
- Management is using velocity as a metric
- The team is starting too many stories at once
- The team isn’t working together
- The team doesn’t understand how to use story points and velocity
I’ve already covered what to do if the scrum team’s user stories are too big. In the coming weeks, I will examine several of these root causes and offer ideas as to how a scrum master could help the team and the organization become healthier and more productive.
Perhaps you can think of other root causes that may be at play here. Leave a comment and I’ll do my best to explore and discuss those too!
Cheers,