Introduction to User Stories and Splitting Stories

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.

2 Comments

My group is new to Agile, and we deliver Operating System and microcode software. It seems really unrealistic that we can create user stories that require a day or less to deliver. What is your guidance for system level software story size?

Try the four techniques! With super technical stories, I find that the acceptance criteria technique is often fruitful. Also, the timeline analysis can be a sequence of verifiable technical behaviors. Once you think of it that way, it also tends to work well.

[...] and other members of our team. Questions, comments, and invitations to lunch are always welcome!« Introduction to User Stories and Splitting StoriesSplitting User Stories with Generic Words »Splitting User Stories with Conjunctions and [...]

[...] the fourth part of my series on splitting user stories. If you are just joining us, start with the first installment and work your way forward from there. Today’s technique is the third of four techniques to split [...]

[...] 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. The first 3 techniques I shared are my favorites, and I manage [...]

[...] master. I suspect the answer to this will take multiple articles, much like our recent series on splitting big user stories into smaller user stories. Let’s begin!The QuestionLet’s say you’re doing weekly sprints and this is Week 1. You [...]

[...] team doesn’t understand how to use story points and velocityI’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 [...]

[...] and adapt their architecture, design and technology choices. I’ve previously written about how to break big user stories into smaller user stories. Might the team go overboard with this? I’ve never seen it. I’ve worked with hundreds [...]