User stories: Why is it Important to Agile?

What I like about Agile the most is its use of the User Story to determine requirements and add a very human factor to the software development project. Instead of an impersonal document that says the client needs this and that, you get a launching point through a few sentences of requirement description and a series of conversations about the desired functionality.

What these conversations produce is a launching point for the team and client to develop solutions that aren’t strictly adhering to tools and processes but to adaptation since it’s understood that these requirements may change over time. Essentially, talking about requirements instead of handing them over is going to produce a more responsive software design.

According to Mountain Goat Software,

User stories are short, simple description of a feature told from the perspective of the person who desires the new capability, usually a user or customer of the system. They typically follow a simple template:

As a <type of user>, I want <some goal> so that <some reason>.

Depending on how your office is set up, you can put these user stories on sticky notes, index cards or even stationery and arrange them on walls or tables during planning and discussion. What’s important are the discussions that these features bring up instead of what’s written on the cards. If you notice, it’s more about achieving the function instead of worrying how.

Sometimes, the stories are broken down into smaller stories that should add details to the requirements and stimulate more discussion. You can also add conditions of satisfaction that can be used on the working prototype of the project and then refined at the end or at a later stage.

They’re called user stories because everyone who has a stake in the software development project is going to write one at some point. At the beginning, the client or product owner writes most of the stories and even keeps an agile record of the cards. As the project continues, you’ll see that every team is going to write at least one because they’re constantly collaborating and asking requirements of their fellow developers and team mates. The writing of the user story is less important than the discussions that happen because of it.

While it’s expected that writing user stories happens at the beginning, the fact that this is an Agile project development tool means that you’re going to be writing stories as the project progresses. Essentially, the user stories make up the product backlog that describes the functionality and incremental changes that are to be added over the course of the project.

This is why it’s important that these stories are discussed because some of them (especially the ones from the product owner or client) are going to be epic. These stories need to be broken down to smaller, working samples instead of the large, overarching function.

Keep in mind that anyone can add another user story at any time—what’s important is that the story is discussed and added to the backlog.

Does this mean that user stories replace a requirements document? I think the better way to think about this is that user stories are simply better documents. While some teams need a requirements document in addition to the stories, it’s important to note that the stories and the documents are nothing if they aren’t discussed.