User stories are a great way to capture product functionality and create cross-team clarity. But, how do you know if your user stories are well-defined or detailed enough? And, the answer, of course, is that it depends. Which probably doesn't help you much. So – what does it depend on?
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 evaluate each component of the story carefully.
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:
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 a 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 needed 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 that 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 a high priority should be broken down into usable stories before 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 download 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. To explore further A fantastic book that describes many of these concepts is Mike Cohn's "User Stories Explained – For Agile Development".
Posted by Shane Hastie.
Your details have been submitted and we will be in touch.