Top Tips for writing Agile stories

Especially when you’re just beginning, getting the flavour and skill of story-writing can be hard.

Here are a few tips on how to do it properly.

  1. Always use the standard story template – it will give your stories the optimum shape for Agile development.
    • “As a… [who: role]
    • I want [what: function, action, info, capability, etc.]
    • so that [why: benefit, purpose]”.
  2. Start with the purpose the user will have in mind when they sit down at your system.
    • Be very clear about the ‘As a’ phrase – lose sight of who the system is for and you will lose your grip on exactly what the user is trying to achieve. It will make your stories more specific, and that will make them easier to implement.
    • They will also be more likely to add real, clearly definable value.
  3. Aim to have your stories express a clear task or unit of end-to-end functionality, and so a definable benefit and verifiable value. No verifiable value, no story.
  4. Conversely, don’t let fanciful ideas like ‘Well, we might want to do it one day’ clutter the user’s current need. If you’re not highly confident it’s needed, it shouldn’t be in the story.
  5. Stories are meant to be disposable – a placeholder for the eventual conversation between user and developer, where the details will be fleshed out. At any given moment a story only needs to be as detailed as the user and the developer need to feel comfortable that both have understood what the user needs.
  6. If possible, identify objectively testable outcomes or targets for each story. Be as clear and exact as possible. Define tests like this:
    • Given [starting point, system state or trigger],
    • when [user action/system input, etc.],
    • then [verifiable effect or output].
  7. Size the story to the release.
    • If the story looks like it will absorb a whole iteration on its own, it’s an epic.
    • Watch out for grand, all-embracing verbs such as ‘manage’ with multiple underlying tasks and functions: they’re a sign that you are looking at an epic, not a single story.
    • Break it down. If you can’t, maybe the user hasn’t thought enough about their underlying needs.
  8. Don’t make the mistake of solutioneering. The ‘I want’ phrase should describe an operational or functional need, not how the user thinks the developer should build it.
  9. The user is the sole author. They own the story. Even if a developer writes or even shapes the words, they must use the user’s own words and confirm with the user that the words say what the user means.
  10. Expect the story to change. If the user doesn’t want to do something different – something better – when they see your solution, maybe you aren’t being creative enough!
  11. Some things just aren’t stories. They’re often facts or expectations that need to be taken into account when evaluating stories or developing the system, and they should be carefully recorded and analysed for their impact. But they aren’t stories. For example:
    • If what you are trying to accomplish doesn’t fit the story format (e.g., highly technical items or regulatory requirements), use a different method. Agile won’t mind.
    • ‘Must support peak load of 15,000 concurrent users’ or ‘98% availability’ are constraints, not stories.
    • Being asked to clone an existing system isn’t a story either, though if you’re asked to replicate an existing function or capability you should be clear on what the story is that the copied item is supposed to support: exact copies rarely make much sense!
By |2018-04-24T12:15:19+00:00Thursday, August 13 2015|Categories: Agile, All, Process and method, Quality, Stories|0 Comments

About the Author:

Chief Architect, Agile201.com.

Leave A Comment

This site uses Akismet to reduce spam. Learn how your comment data is processed.

Want to do more than just build systems?             
error: Agile201 is wholly copyright and copy-protected.