Why I Love Using User Stories
By: Johnathon Wright on: July 14, 2009
A few days ago, someone on the business side of our project created a task in the system with a single sentence: Add Flash to front page.
This requirement is, in many ways, the exact opposite of useful. Here are some concerns:
- What is the business value?
- What is the audience?
- What will it do?
- There is no predefined "done."
- How big is this?
This got me thinking about the way I generally write requirements -- user stories. A user story is a single sentence that describes how a user should be able to use the system. I have been using user stories for almost two years now. I can honestly say that they have changed the way I write software, and for the better; but I hadn't really taken the time to put my finger on why this way is better.
One thing that is important to me as a developer is to be creating software that users will love to use. Obviously, a technically-cool table structure doesn't make for happy users. Software can not be considered a success from the end-user perspective if it doesn't solve their problems. That's where user stories come in to the picture -- their goal is to describe how a user will be working with the system and how it will solve their problems.
User stories are great because they keep the user, their concerns, motivations and experiences, in the foreground.* Keep each requirement discreet and small-ish. * If we can't justify the business value of a requirement, we shouldn't do it. * If we can't create acceptance criteria, then we don't really understand what we want done. This is a bad time to start doing it.