Agile Development Blog

There are several problems with traditional requirements formats

• They cost a lot of money to produce and yet you can’t sell them to your customers (waste)
• They can be monolithic (90 page use cases) and so they’re hard to manage when different pieces have different importance.  The desire to make them comprehensive loads extra work onto the development team. (strain)
• They take a long time to produce, holding up the development process and delaying the feedback that comes when users get to see working software (wait time)
• The more detailed they are, the more the team thinks they’re complete and the less critical thinking gets applied to them, leading to more defects (waste)

User stories are designed to address these issues.  A user story represents a small piece of business value that a software team can deliver within an iteration.  Here’s one:

As a customer, I want to check my order status online so that I can know when to expect my package.

There’s actually a lot in that little line – we know who the user is, what’s the activity they want to do, and what’s the underlying goal.

Ron Jeffries has said that there are actually three parts of a user story:

1. Card - the part we wrote in italics above.  It’s just a placeholder – a project management mechanism that we’ll use to remind us that at some point we probably should get around to building an order status thingy.  This part should be short enough to write on one side of an index card with a sharpie marker.  You could even word it “Order Status Checker Thingy” to emphasize that it’s a placeholder, not a requirement.
2. Conversation - When this card comes up in the stack as the top priority, the team will talk during iteration planning about the acceptance criteria that will need to be met to satisfy the customer or Product Owner that they built the right kind of “Order Status Checker Thingy”.  Sometimes the criteria are noted on the back of an index card or in an agile tracking tool.
3. Confirmation – The detailed acceptance tests that the team writes during the iteration to define exactly how an “Order Status Checker Thingy” should work, in excruciating detail

A user story is unlike regular requirements because the requirements aren’t specified in detail until the tests are written, around the same time as implementation.  Benefits of this approach:

• No inherent waste.  We’re only writing down as much as we need to document our conversations and make sure we’re all on the same page
• Encourages discussion. Your developers and testers know a lot about what they’re building.  They’re capable of thinking of important details and preventing defects and other bigger mistakes, if the process encourages them
• Easy to manage.  If you’re used to use cases, break down your scenarios and steps into stories.  You can do the important parts early and postpone the less important parts later.
• Easy to manage scope creep.  If you think of new things to do, create new stories and add them to your list in priority order.  Since you’re always doing the most important things first, you’ll end up naturally managing scope in a way you can’t when you’re working off of requirements documents.

(This is a draft – please add comments or edit the pattern itself)