Here is a question that just showed up in my in-box regarding how to calculate a scrum team’s velocity when they are doing stabilization sprints. This notion of stabilization sprints has become more popular lately, as they are included in SAFe (Scaled Agile Framework).

Question

We do a 2-week stabilization sprint every 4th sprint where we complete regression testing, etc. but don’t take any new stories. Is there a rule of thumb around including a stabilization sprint in the team’s velocity?

Answer

The purpose of tracking a scrum team’s velocity is to give stakeholders (and the team) predictability into the rate at which they will complete the planned deliverables (the stories). Velocity is the rate of delivery. The stabilization work doesn’t represent specific deliverables that the stakeholders have asked for; it is simply a cost that you are paying every 4th sprint, because you aren’t really done with the stories during the non-stabilization sprints.
Read the full article…

A common complaint I hear from scrum teams: We didn’t finish all the stories we committed to deliver in the sprint. While there are many reasons for this, one often-overlooked one is: The user stories were not ready to enter the sprint in the first place. The solution is for the scrum team to decide which stories are sprint ready before the sprint planning meeting even starts.

The sprint ready vote typically happens during a backlog refinement session (AKA story time or product backlog grooming meeting). Sprint ready means the team is confident they can accomplish the story in one sprint. They have:

• Confirmed and agreed on the acceptance criteria
• Estimated the size
• Confirmed all the story’s dependencies are complete
• The story is small enough to be comfortably completed in a sprint (with all surrounding required processes)

I know this sounds amazing, even too good to be true. Think about how the chances of work being completed in one sprint would increase if all those aspects of story preparation were completed before the team started? I know – mind-blowing!

So how do you get there? A few small changes in story time and sprint planning make this possible.
Read the full article…

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.
Read the full article…

This is the last of five installments in my series on splitting large user stories into smaller user stories. If your scrum team isn’t able to complete a minimum of four user stories every week, then start with the first installment and work your way back to this one. Occasionally, I find a user story that I cannot split using conjunctions, generic words, or acceptance criteria. When this happens, I use timeline analysis.

With this technique, I ask my stakeholder to pretend the user story is already done, and then I ask “What happens when the functionality gets used?” They will then describe a sequence of events. Even for things that happen non-deterministically, or which could happen in parallel, they still describe it sequentially; it’s just the way our brains and our language work. I then identify the verifiable steps in the timeline.
Read the full article…