Why user stories are important for Agile development

We often cover the importance of lean startup approach and Agile methodology that we use here at RubyGarage. One of the key aspects of agile methods are user stories, which represent an effective way to define the product functions and manage its requirements.

The Wikipedia article turns out to be pretty comprehensive when explaining the basic idea behind user stories, so today we're going to focus on the importance of user stories in our project workflow.

Prior to Agile methods we often looked at the products from our, developers' point of view. We thought that since we know how to code and design the product, we should know what it should look and function like. User stories help teams to shift to the user's' perspective. Users are often not as advanced as us, have no time to dig into details and consider the quality by some other parameters than us.

Using stories as functional descriptions eventually changed the way we look at the product and the way we make it. Being intended to plan the future functionality and keep in mind its purpose, they also brought a few other noticeable advantages that we're going to talk about further.

I.N.V.E.S.T.

The user stories first were described as a part of Extreme Programming (XP). It's author, Bill Wake suggested to use the INVEST acronym to underline the key aspects of user stories and at the same time its main advantages:

• Independent: a user story independent from other stories is easier to prioritize, to process and to implement.
• Negotiable: a user story does not explain details, but becomes the reason and direction to clarify and discuss them later
• Valuable: user stories focus on bringing values to the users, not simply solving someone’s problems or implementing functions
• Estimable: a good user story allows to estimate how much time is needed to implement it
• Small: a user story should capture user requirements; leave the details for use cases
• Testable:a user story implies that when implemented you can easily check if it's done correctly (for more details read our Clear Acceptance Criteria And Why It’s Important blogpost).

It's All About Priorities

To have a feeling of the product, a team can quickly generate a dozen of user stories, because they are short and concise. Having written them on the post-it notes, the team can then decide which user stories are most critical and which user stories require more details and should be postponed. Not only that is a simple and fun process, but it also makes you focused on the users' primary needs and not the product owner desires.

Backlogging the product

Here in RubyGarage the work on the web/mobile applications never ends, because such products constantly evolve and adapt to the user requirements. And it is related to all its aspects: the designers team can come up with new user stories on the improved UX, the developers can find a better way to solve user problems and so on.

So there's no such thing as a 'final product', and having new user stories constantly generated and discussed is a great way to keep the product backlog and know how you can further improve it in the next iteration.

In the end, here in RubyGarage we often see how our clients, who are usually the product owners, start to better understand and see the final product when they are introduced to user stories. And it’s no wonder, since imagining the behavior of real people using your product will always be the most effective way to make it successful.