What makes a “good” story

04 Aug

This morning I received an email that asked how a team will know their stories are good enough?

This question is one that frequently comes up in classes, and the right answer (of course) is “it depends”, which probably doesn’t help you much 🙂

So – what does it depend on?  Here are my thoughts . . .

The most common structure for a user story is

  • As a <role> I want <feature> so that <benefit can be achieved>

It’s important to carefully evaluate each component of the story –

  • Role – Who needs this feature from the system,
  • Feature – A succinct statement of the need
  • Benefit – The business benefit that this feature will deliver, this must be traceable to the project goals and objectives

It is important to remember that a user story is not intended to be the detailed requirement – it is a “placeholder for a conversation”.  A story has three C’s associated with it

  • Card – the statement of the business need
  • Conversation – the elaboration discussion that happens shortly before the story is ready to be implemented, this conversation will flesh out the detail and allow the team to build the third part the
  • Confirmation – the elaborated details that form the basis of the test cases and confirm that the story has been delivered

The “Card” is the one-line statement of the feature to be delivered, often in the “As a … I want … so that” format.

The “Conversation” component of the story is how the detailed requirements get identified – the conversation happens shortly before the team is ready to build that piece of the product.

The “Confirmation” component makes up the acceptance criteria that will show if the story has been implemented correctly.  The test design criteria that are agreed to when the conversation happens.  Defining the confirmation criteria is how the detailed requirements are expressed – this could include screen mockups, technical design details, quality guidelines (performance, security, usability …) and any other details that will help the team build and test the feature into the product.  The minimum confirmation criteria that should be included are a set of test designs, often expressed in the Behavior Driven Design format of “given … when … then”.  I’ll examine this in more detail in a later entry…

A good story is one that identifies the piece of functionality or quality to be delivered at a level that the business representatives on the team can prioritise and the technical team members can estimate.  It should be small enough to be understandable and convey the business benefit without needing detailed explanation.

How small is small – a rough guideline is four days or less of team effort to deliver the story on its own.  Not taking into account any “plumbing” or architectural work that needs to be done to enable the functionality.   Team effort means all the work that needs to be undertaken to deliver the story to the “done” state – whatever analysis, design, development, unit & system testing  and user acceptance testing is needed.

Here are a few example stories, and some ideas about them

As a book reader I want to buy my ebooks online so I can read them whenever I want

Large stories such as this are often referred to as Epics – an epic explains a large business goal, but is way too large to estimate effectively, and very difficult to prioritise.  Epics are OK in a story list, as long as they are not high priority items – an epic that is high priority should be broken down into usable stories before so they can be estimated and prioritised.  Low priority epics remain in the story list until shortly before the team is ready to work on them, then they need to be expanded into usable stories.

As a book owner I want to see a list of the books in my online library sorted in alphabetical order by author or title or date purchased and be able to dowload them in a zip file so I can read them on my iPad

This story is complex and imposes unnecessary constraints on the way books are sorted and downloaded.

As a book purchaser I want to store my reading preferences so I can receive recommendations about books I might enjoy

As the company accountant I want purchasers to pay for books using PayPal so that we don’t need to set up credit card facilities

As a book owner I want to select the download file format so that I can read my books on multiple devices

These stories are about the right size and structure.

What advice can you offer to teams working with stories?

Needless to say, these concepts are not original thought – Mike Cohn, Ron Jeffries, Kent Beck and many others have written extensively on these topics, and I’ve been fortunate to be influenced and informed by their work.   A fantastic book that describes many of these concepts is Mike Cohn’s  “User Stories Explained – For Agile Development”.

Posted by Shane Hastie


Posted by on August 4, 2010 in Agile



5 responses to “What makes a “good” story

  1. Johanna Rothman

    August 6, 2010 at 1:41 am

    Shane, I prefer even smaller stories, stories that can be done by a team in a day. For example, “As a book owner I want to select the download file format so that I can read my books on multiple devices”, I would count the *selection and implementation of that selection* as one story. So if it’s pdf, that’s one story. Mobi is one story. Some other format is another story. That way you can get feedback from the beginning, before you’ve implemented 4 options for download and reading.

  2. Jeff Smathers

    August 19, 2010 at 8:21 am

    I am confused by your guidelines for how to settle on the right size for a user story. If as you suggest, the estimate of team effort should include everything the team needs to do in order to deliver the story in a “done” state, shouldn’t the estimate include “…account any “plumbing” or architectural work that needs to be done to enable the functionality.”? Perhaps I am reading your statement wrong but it seems that you are suggesting that “plumbing” and architectural work should not be included in the estimate but everything else should be. Am I understanding you correctly?

  3. Adam Fitzgerald

    August 19, 2010 at 1:08 pm

    Our stories generally represent a task that can not be broken down any further, so a simple story is approx half a day.

  4. Nikki Appleby

    November 15, 2010 at 1:50 pm

    Well, it’s always easier to pick holes in other people’s stories, so I will! But only because I care, not for finger pointing.

    I would agree with Johanna that the different formats story should be broken down into pdf, Mobi etc. The main reason for this is because at some point some of the formats will be descoped as the project runs out of time, so you are prepared.

    Generally, break down your stories as you see fit and then measure the success. If the smell is that the BAs and QAs are struggling to define the tests for Done-ness, then the stories are too big. If the IM and the BAs are struggling to keep the wall up to date with the Dev progress, then the stories are too small. Just as long as stuff gets done, don’t stress too much and you will develop your own breakdown strategies as you do more elaborations. JFDI!


Leave a Reply

Fill in your details below or click an icon to log in: Logo

You are commenting using your account. Log Out /  Change )

Google photo

You are commenting using your Google account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )

Connecting to %s

%d bloggers like this: