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 happens during story time (aka the 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.
- When the team is having story time, discuss whether the acceptance criteria is clear. If not, then the story is not sprint ready.
- When the team estimates the size of the story, make sure they are taking into account all work required to make a story production ready.
- Is the size estimate small enough that the team could complete four to six stories of that size in a week? If not, the story needs to be split into smaller stories and it’s not sprint ready.
- Review any dependencies on the development work. If there are outstanding dependencies, then it’s not sprint ready.
What if a story isn’t sprint ready? The development team and the product owner can discuss what’s needed to get it sprint ready, and then take the appropriate actions. This means that story might be presented in story time more than once, which is fine – remember, refinement is part of the process.
When it comes to sprint planning, the product owner can only offer sprint ready stories to the team. They should offer them one at a time until the team says “Enough!” The product owner should not walk into sprint planning with the sprint already loaded with a whole set of stories, as this creates an unhealthy pressure on the team.
That’s it! It’s really pretty simple – however as with most things scrum – not always easy. So try it out. You don’t have much to lose, except maybe those undone stories.
while I agree with most of your post I have some problems with “Confirmed all the story’s dependencies are complete”. To clear out all dependencies the team also has to spend some (often unpredictable) time which also has to be planned – I guess. So the question is how. Do you have any advice?
Your observation on being “sprint-ready” is right on. I’ve worked (as a contractor and consultant) on many teams where development managers simply refuse to listen to this concept and it always leads to pain.
Very often, it’s a non-technical issue, such as simply being granted access to systems that host required services; contracts being signed to bring said services online; or customer-facing management providing essential specs or inputs.
Bottom line: no. If the story is not ready to go, as I usually put it, before the sprint planning meeting–then it is not ready to be included in the sprint. It’s not even okay to depend on things that will be provided during the sprint, because that distorts the team’s ability to manage its own timebox.