Capturing requirements in Agile stories is finicky business. Stories need to be just the right size and shape, have the right bits of detail, point to a clear outcome. They must capture the who, what, and why in a way that speaks unequivocally to the user and to the team. Badly written user stories will slow down your team in any number of ways.
A few recommendations...
Get the right people writing the story.
Even if you've done lots of requirements gathering, or the functionality seems like a no-brainer, don't assume that you have sufficient information to compose stories without stakeholder participation. In fact if at all possible, the stakeholders should do the writing. You are there to ask questions and help clarify.
Without this collaboration, you will end up going into iteration planning with hobgoblins, not real stories. The team then must devote time to figuring out what's actually needed, returning to the stakeholder with lots of questions, rewriting and rejiggering.
And if these half-baked stories sneak through planning and make it onto Kanban, the whole iteration slows down while the team strives to make sense of them.
Be specific.
That sounds elementary, but stories are written all the time with no actual users in mind, only "theoretical" ones. Or the stories themselves are hazy and dreamlike.
Imprecise stories are velocity killers. They waste everybody's time because they're sooooooo open to interpretation. They lead to unnecessary work that nobody asked for, fixes and back-outs of code that never should have happened, and a rebuild (or discard) of the system once you finally do get feedback from real users.
Make sure stories represent actual people who can answer questions, help with details, and verify that the team is meeting requirements. Then, make sure they are written so that both the product owner and the team understand what's needed upon the first read.
Much Better: "As a credit union member, I need to see my scheduled-payment history displayed on a single webpage." This story represents a real user. And you don't have to tease it apart to find out what the user is asking for.
Scale it down.
Epic stories—in which nothing is done until everything is done—linger in the iteration backlog accumulating bulk, then haltingly heave across the Kanban board leaving wide snail tracks. They obfuscate progress, and the team learns very little about what it can actually accomplish.
Epic stories have a place: It's in the product backlog. Leave them there, and break out stories small enough to be completed in one iteration.
Don't forget the exit criteria.
If a story does not clearly indicate when the work is considered done, you run several risks. You can end up doing too much, exceeding what's required, tying ribbons all over the car engine. Or you can fall short of what's needed. Or you can simply do the wrong thing.
Defining exit criteria also can help to determine if a story is sized correctly. A long list of criteria indicates that the story should be broken up into smaller ones. Conversely, if stories are too small, exit criteria frequently overlaps.
Take these three stories:
Read some more about user stories.
Mike Cohn's book User Stories Applied is a good read for any Agile team looking to improve story writing. And here are a few links that I've found useful:
A few recommendations...
Get the right people writing the story.
Even if you've done lots of requirements gathering, or the functionality seems like a no-brainer, don't assume that you have sufficient information to compose stories without stakeholder participation. In fact if at all possible, the stakeholders should do the writing. You are there to ask questions and help clarify.
Without this collaboration, you will end up going into iteration planning with hobgoblins, not real stories. The team then must devote time to figuring out what's actually needed, returning to the stakeholder with lots of questions, rewriting and rejiggering.
And if these half-baked stories sneak through planning and make it onto Kanban, the whole iteration slows down while the team strives to make sense of them.
Be specific.
That sounds elementary, but stories are written all the time with no actual users in mind, only "theoretical" ones. Or the stories themselves are hazy and dreamlike.
Imprecise stories are velocity killers. They waste everybody's time because they're sooooooo open to interpretation. They lead to unnecessary work that nobody asked for, fixes and back-outs of code that never should have happened, and a rebuild (or discard) of the system once you finally do get feedback from real users.
Make sure stories represent actual people who can answer questions, help with details, and verify that the team is meeting requirements. Then, make sure they are written so that both the product owner and the team understand what's needed upon the first read.
Much Better: "As a credit union member, I need to see my scheduled-payment history displayed on a single webpage." This story represents a real user. And you don't have to tease it apart to find out what the user is asking for.
Scale it down.
Epic stories—in which nothing is done until everything is done—linger in the iteration backlog accumulating bulk, then haltingly heave across the Kanban board leaving wide snail tracks. They obfuscate progress, and the team learns very little about what it can actually accomplish.
Epic stories have a place: It's in the product backlog. Leave them there, and break out stories small enough to be completed in one iteration.
Don't forget the exit criteria.
If a story does not clearly indicate when the work is considered done, you run several risks. You can end up doing too much, exceeding what's required, tying ribbons all over the car engine. Or you can fall short of what's needed. Or you can simply do the wrong thing.
Defining exit criteria also can help to determine if a story is sized correctly. A long list of criteria indicates that the story should be broken up into smaller ones. Conversely, if stories are too small, exit criteria frequently overlaps.
Take these three stories:
All three involve many of the same tasks to put this functionality in place. So why have they been broken apart? Fragmenting work in this way causes complicated interdependencies between stories and makes it next to impossible to make story-point or time estimates."User should be able to select thumbnail of image""User should be able to select 200-pixel-wide version of image""User should be able to select 600-pixel-wide version of image"
Read some more about user stories.
Mike Cohn's book User Stories Applied is a good read for any Agile team looking to improve story writing. And here are a few links that I've found useful:
- Do's and Don'ts for User Stories, Use Cases, Scenarios
- Writing Good User Stories
- When is a Story Too Large For a Sprint?
- User Story Examples and Counterexamples
- Size Matters: Why You Should Prefer Small User Stories
