User Stories in Agile Development

Author profile picture

@fmrigueiroFilipe Rigueiro

Product Analyst for Digital development and CEO of Uni Data.

One of the biggest challenges in software development is the nearly impossible task of gathering clear requirements and then getting those requirements to remain unchanged during code development. In the waterfall approach to software development — despite efforts to define, document, and approve every possible contingency before development begins — the delivered product is rarely what the customer wants.

What are User Stories?

User stories are simple, yet extremely powerful constructs: they describe pieces of functionality from a user’s point of view, expressed in a solid, compact way. They reflect what a particular class of user needs and the value to be gained. The format is very simple and easy to use.
“As a <particular class of user>, I want to <be able to perform/do something> so that <I get some form of value or benefit>
All agile user stories include a sentence or two and, more importantly, a series of conversations about the desired functionality.
User stories are simple short descriptions of a feature told from the perspective of the person who desires the new capability of the product, usually a user or consumer of the system.
Stories are not just a replacement for requirements but they are a way to communicate and manage user requirements

Why are user stories so powerful?

Photo by Thomas Kelley on Unsplash
User stories are very powerful due to the simple and focused way they are written, they ensure the user is always considered while describing the why and the what of the feature.
They encourage conversation between team members and can be estimated and prioritised to deliver the most important stories to the user.
User stories provide an excellent way to define your product with clarity. A set of well-defined, prioritised user stories can help you articulate the functionality of your product using ‘plain English’ — with no technicalities and implementation details.
The ‘user story’ approach empowers meaningful product discussions, both within the product development team and with external stakeholders.
Properly written user stories provide a solid basis for communication and collaboration — focusing on what matters most to the user.
Compared to other means of capturing and documenting user requirements and product specification, they have at least the following advantages:
User stories help achieve cross-team clarity on what to build, for whom, why and when. They can become the standard way to communicate and summarise the functional requirements of the product, due to the easy way they can be defined, revised and discussed.
They can be used in scope discussions or even as a technical discussion starting point.
User stories encourage participation by all team members and not only technical members of the team. Software development projects are complex and involve a wide range of expertise, acronyms, technology, and implementations. In many cases, the terminology or technical language is not commonly understood, creating confusion within the team. User stories remove this by using ‘plain language’ so any team member can participate simply by thinking ‘as a user’. The team can effectively collaborate in defining, challenging or prioritising user stories.
User stories can help define the entire product as a set of strong and prioritised stories. As product developers think big and define a super-set of user stories that are prioritised, depending on user value, complexity and business value, the product takes shape in the form of user value.
You don’t have to define stories are out of scope, just assign a lower priority, even the “crazy” ideas that come out of brainstorming sessions, these are still valuable even if its way down the line. Move up the core features that you believe users want and start working on those first. You can define a line in the sand where the scope for this current iteration, phase or release, but make sure that all included are well defined.

What makes a good user story?

Photo by Daniel Fazio on Unsplash
Every time you create a user story you should INVEST some time and think into crafting those.
INVEST criteria is coined by Bill Wake who re-purposed the acronym SMART for a set of criteria to assess the quality of the user story, we can go over the acronym that will help you create good user stories.
INDEPENDENT — dependencies on other stories or other teams can cause delays and bottlenecks. SO craft your stories in ways that are independent of each other. This sometimes is hard in complex projects, but if you have enough independent stories with high value to work with you can prioritise to unblock more.
NEGOTIABLE — a story is not a contract but rather an invitation for conversation. You will find that sometimes requirements might be specified in such a way that it will be either hard or awkward to implement. The story captures the essence of what is desired and the implementation is the result of collaborative negotiation between the customer (like PO) and the team. The goal is to meet customer needs and not to develop something strictly to requirements even if adds little value.
VALUABLE — If a story does not have any discernable value it should not be done. Hopefully, the exercise of prioritising the backlog is carried out and all the stories are valuable either to the user or to the business. Sometimes the value is not only to the end-user but as an internal feature that allows the business to provide further value to the end-user down the line. This can be done by creating a persona that will use those features.
ESTIMATE — do the development team know enough about the tickets to be able to estimate them? A story has to be able to be estimated so it can be prioritized. A piece of work of high value but extremely lengthy development time might not be the highest priority if you cannot finish it. What is the story that cannot be estimated? Then the story needs to be split into smaller chunks that can be estimated if more information is needed to estimate you can have time-boxed spikes to gather more information about what work needs to be done and then properly estimate the story.
SIZE APPROPRIATE — As stated before the stories should be small enough to be estimable. Having big stories on the backlog might increase the risk of delivering value at the end of the sprint, also big stories are harder to estimate and might have unknown unknowns that will affect development.
TESTABLE — Every story needs to be testable to be DONE. Adding acceptance criteria to the story is a great way to encourage collaboration, and speed, as the development team, can build the feature to pass all acceptance criteria, check story bellow for more.
Behaviour Driven Development in Acceptance Criteria

User stories are vertical layers

What do I mean by vertical layers? Software development is complex and involves many specialised areas, backend, front end, data layer, etc. All these layers connected to deliver some value to the user, and every story should have pieces of each layer, as horizontal slices do not result in working, demonstrable, software.
User stories should be a cross-section of all the layers but focussing only a small slice of functionality while delivering business value.


User stories are a powerful way to define requirements, they keep the user in the center of all features required and focus the team in delivering value. They are easy to work with and promote conversation and discussion as well as making the life of the product owner easier when prioritising.
In a later feature, I will describe the best strategies to break user stories into small chunks of work.
Previously published at


The Noonification banner

Subscribe to get your daily round-up of top tech stories!