This post originated from an RSS feed registered with Agile Buzz
by Dave Churchville.
Original Post: Writing Good User Stories
Feed Title: Agile Project Planning
Feed URL: http://feeds2.feedburner.com/AgileProjectPlanning
Feed Description: Thoughts on agile project planning, Extreme programming, and other software development topics
One question I get asked a lot when discussing agile project management is this:
How do I write a good user story?
I talked about Mike Cohn's book on this blog previously, and it is an excellent source of information.
However, for those of you who don't have time to read a book, I'll offer a few of my own tips:
1. Make them customer-focused. The easiest way to do this is to have the customer write them. If this isn't practical, then you'll have to role-play. An example of a developer-focused story is "Add clustered index to the Orders table." This doesn't mean much to most customers, and a real customer (unless they are a DBA), would probably never write this. Instead, something like "Improve Order reporting performance", captures the same information, but is understandable to everyone on the team.
2. Make them elevator-friendly. A good story should be something you could explain on an elevator in 30 seconds or so to a team member. Don't write a novel. Remember, this is just a placeholder for more detailed conversations, not a specification or requirements document.
3. Make them the right size. Not too big, and not too small, just like Goldilocks said when she visited a tough bear hangout. For me, the right size is usually under 40 ideal hours (1 ideal week) of estimated effort. Small stories aren't usually a problem, but if they get to be under an hour or so, you probably want to batch them up. Defects are usually good candidates for batching into a single story, as long as they are small and easy to implement.
4. Make them testable. An untestable story might be something like "Make the order screen easy to use." It sounds nice, but no one really knows what this means, or how to objectively verify it. A better wording choice might be: "A novice user be able to load, enter information, and submit an order within 5 minutes." Hmmm...still seems a little questionable, but I can probably write a test like "Given a sample group of 10, 8 of these users should be able to complete an order for a book in 5 minutes."
This is just scratching the surface of the topic, but I hope these tips give you a little direction when starting to write stories.
Previous Topic
