Many teams struggle with defining “good” Agile Stories. Newly formed agile teams sometimes struggle with the basics, “What is a story?” and can be challenged by understanding the difference between a story, group of stories, epics or tasks. A mature team can easily overwhelm a Story with implementation details and acceptance criteria to the point where the value of the story to the User can get lost in all the details.

I should point out that there is plenty of good reading on this topic; Mike Cohn’s examples, several good tips from Roman Pichler, Alec Cowan’s thesis on Your Best Agile User Story, and Bill Wake’s classic INVEST principals.   There are also a good number of agile books either dedicated to story writing or cover it as part of the overall agile practice.

My list below is both strategic and tactical. The strategic part aims to get team participants, business stakeholders, and others an easy to consume a list of developments – a level of communication and engagement aimed at improving IT culture. The tactical part aims to get all team members – not just the developers but also QA, Ops, and other participants to have a shared understanding of what’s being asked for by the product owner and important for the success of the program.

Principles of Good Agile Stories

• • Key stakeholders must achieve a shared understanding of the deliverable – Stakeholders here start with the Product Owner and the Technical Lead but should also extend out to members of the team when they review the story.

• • Stories should convey the opportunity, issue, need or value that it will deliver – It should convey the what, why, for whom and for what benefit? It should have less detail on the how.

• • The Story Title should be short and convey the deliverable without reading the details – Many agile practices require sharing a list of stories with a larger audience, so being able to skim through the titles and understand the intent is very important when working with stakeholders, facilitating demos, or efficiently grooming the backlog.

• • Good stories deliver an atomic increment in business value – This essentially separates a “story” from a “task”; a task is a technical step and completed in isolation, may not deliver value. A product owner should be one step closer to the goal (vision) by having the story completed. Why atomic? This is a discipline to keep stories small and more often than not, a story that delivers more than an atomic unit of value should be broken down into multiple stories.

• • Stories need to be completed in a Sprint – Which is another reason they need to be small.

• • Good stories have sufficient acceptance criteria. These criteria are like a short contract and should establish a shared understanding of the requirements with the product owner and define “done”. They are often written as pass or fail criteria to ensure there is little or no ambiguity. Good stories should also reference technical standards covering security, performance, naming conventions, quality and other nonfunctional requirements that define technical acceptance criteria.

• The team should be able to estimate the story – If the criteria is clear, the team should be able to either provide an estimate for its delivery or acknowledge that it requires some research and document one or more time-boxed spikes (usually these are separate research/development stories that enable the team to experiment with one or more technical solutions) to flush out unknowns.

Why Principles?

My principles deviate from some common practices and emphasize some key principles. I don’t like stories that begin with “As a user, I would like to… ” because it adds to the length of the story title making it more difficult for participants to skim in a list. I like the word “atomic” vs. independent because it orients the team toward small wins and simple products. I also think that stories should reinforce architectural standards and open a dialog with the product owner on value versus estimate or where research is required.

Above all else, remember that stories are a communications tool. Keep it simple.