Skip to main content

don't let broken stories wreck your team's velocity

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.
    Bad: "UI team needs to fix scheduled-payment section." This story is overlarge and clear as cat litter. It also points to...what user? The UI team?

    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:
    "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" 
    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.

    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:

    Popular posts from this blog

    the case for incremental redesign: part i

    Consider the dashboard of your automobile. Aside from a number of extras that have crept in over the decades, it's essentially configured the same as the dash of the car you drove as a kid. In fact, the design of the automobile's critical controls hasn't significantly altered since the Model T Ford. It's worked for more than 100 years, and we love it.

    Plone Advocate Andreas Mantke to Lead Site-Administration Workshop at 2012 LibreOffice Conference

    I just published this article at on Andreas Mantke, a deputy member of the Board of Directors of the Document Foundation for LibreOffice . Mantke led a workshop for new Plone site administrators in the LibreOffice community during its annual conference last week. See the full article at .