A common problem among the scrum teams that I coach is user stories that are too big. When a user story is too big, it is hard understand, estimate and implement. So what is a good size for a user story? My guidance is that the user stories at the top of the product backlog should be sized such that the scrum team could easily complete four to six stories a week.
When a team’s user stories are smaller, they complete stories more frequently. This is good on many levels. Each time a story is completed the team has delivered value, which is what the business pays us to do. We also get many types of feedback with each completed story. We can update our release (storypoint) burndown chart and get important schedule feedback, allowing us to inspect and adapt the schedule. We also get product feedback every time we finish a story. We have something new to show our stakeholders and they can give us feedback and guidance so that we can adjust the product plan, to better build the product that our stakeholders desire. Additionally, we get technical and architectural feedback. It isn’t until we have working user stories that we can see how well the technical and architectural choices we have made are serving us. If our original ideas are not working out as we had hoped, then we will need to adjust the architecture to better support the functionality that is being developed.
OK, smaller stories are better. How does a team take the big stories in its product backlog and split them into smaller stories?. I have 4 techniques that I use to split user stories, and I have yet to run across a user story that would not yield to at least one of these approaches. Someday I will find such a story, and hopefully I will learn a fifth technique.
Before applying these techniques, start by writing your story in the common user story form:
As a (type of stakeholder),
I want (something),
so that (some value is created).
This isn’t the only way to write a good story, but any well-formed story can be written this way. The advantage is that writing the story in this format captures three important aspects of any good story:
1. Who is this functionality for?
This is described by the first line: As a (type of stakeholder). The more specific the stakeholder, the better the story.
2. What we should create?
This is described in second line: I want (something).
3. Why is it valuable to the user?
Yes, this is the third line of the story: So that (some value is created).
If we don’t know the “who, what, and why”- then we don’t really understand the story yet. If we don’t understand the story, then we probably can’t split it. Once we have the story in the traditional format, we are ready to begin splitting it. Tune in next week, when I’ll share the first, and easiest, of the four techniques I use to split user stories.
Here are quick links to all of the user story splitting posts.
- Introduction To User Stories And Splitting Stories
- Splitting User Stories With Conjunctions And Connectors
- Splitting User Stories With Generic Words
- Splitting User Stories With Acceptance Criteria
- Splitting User Stories With Timeline Analysis
- Quick Reference Guide For Splitting User Stories
- Stories To Practice On
Chris Sims is co-author of Elements of Scrum as well as a Certified Scrum Trainer, agile coach, and recovering C++ developer who helps software development teams improve their productivity and happiness.