When I work with teams on writing User Stories, the question always comes up: “What are User Stories and how are they different from requirements?”
The User Story is a format to write work items in a Product Backlog and it is used to shift the dynamic between Product Owner and Developers. User Stories help a Scrum Team to become more collaborative, to foster innovation, and to deliver better solutions. But let’s see the difference in more detail.
Requirements
I always struggle with the word “requirements”. This is how specifications and functionalities are normally called when working on a project.
The word requirement, and its verb counterpart to require, in their essence define something that is “required”, “needed”, “expected”. The requirement becomes something that is compulsory, a necessary objective of the work. Requirements create a blanket of necessity and limit the empowerment of product managers to be effective at solving problems.
The requirements live in the “solution space”. They are to be built as specified. Product Owners spend time defining all the details in the requirements, and the developers expect to be told exactly what that functionality needs to do. When a detail is missing, developers may get frustrated with the uncertainty or lack of accuracy from their product counterpart. When the finished functionality does not deliver what was expected, the blame game kicks off, accusing the requirements of not being specific enough.
In addition, when we create a list of functionalities of a product and call them requirements, we are signaling that these functionalities are required, needed, expected. That is, we leave little room for interpretation, discovery, or possible alternative solutions.
The User Story format
This is where User Stories can help. They break the tyranny of perfection and instead introduce the possibility of discovery and flexibility. The User Story format is composed of three parts: the who, representing the user whose problem we are trying to solve; the what, representing the functionality that they would like to get; and the why, representing the benefit that the user gets from this work, if the functionality is delivered and solves the problem.
The Product Owner focuses on the user, on what they need, and why they need it. They employ the User Story format to create context for the Scrum Team and start a conversation.
Whereas requirements are written in detail and then passed on to the Developers for execution, User Stories shift that dynamic. User Stories do not specify the implementation details, and they are not passed on to the Developers. Instead, User Stories define context around the user, the need, and its importance, and then spark a conversation between the Product Owner and the Developers. The implementation details and the Acceptance Criteria may emerge from this conversation and the Developers can take ownership of the solution.
Notice that one piece is missing in User Stories. That is the how, the solution, how to do the work to deliver the benefit to the user. The User Story does not define the solution because this is the domain of the Developers on the Scrum Team.
If you are using User Stories to write requirements, then stop. Don’t bother. You are wasting time. Just write requirements if that is what you like to do. But if instead you like to employ User Stories, then use them to spark a conversation. The solution is not defined upfront. The solution may be left to the Developers (they are the experts after all) or it may emerge as part of the conversation between Product Owner and Developers.
Requirements
- Typically clearly defined in terms of expected solution
- A change often requires several layers of approvals and change control
- Feedback is rarely sought
- Define everything up front
- Built all at once, deliver at the end
- Follow instructions
- Business team writes them and hands over the documents to the
development team to implement as is
User Stories
- Who, what, and why are clearly defined
- Foster collaboration, communication, and understanding of context for the work
- Feedback loop is built in
- Deliver the highest value by focusing on small and immediate customer needs
- Foster innovation
- Reduce risk
- Collaborate and collectively develop
User Stories drive experiments
When we express functionality and – in general, work items – in User Story format we step away from requirements and instead enter the world of experiments. An experiment is such work that aims at proving a hypothesis. When we frame a work item as an experiment, we believe that to solve the customer’s problem we can build a piece of functionality and validate the hypothesis we made.
Work is no longer required, needed, expected. Work exists in a dimension of discovery where we build something and then validate if what we have built delivers the value we expected. We may very well start from an idea or a solution to solve the problem, but we keep the solution set open. While we build something, we validate if indeed the solution works, or if there are other possible solutions that work better.
Shifting the meaning of User Stories from requirements to experiments empowers both the Product Owner and the Developers to work together and find the best solution to the user’s problem. It enables the team to understand the “problem space” and drive better solutions. Work is no longer output-driven, and instead it is value-driven and drives innovation.
Want to master User Stories and learn advanced techniques to split Epics and Stories?
The Beyond User Stories workshop focuses on empowering you with the tools and mindset to make an effective use of User Stories, apply splitting techniques, and reframe how you use an Epics backlog in Jira.
To learn more about the Beyond User Stories workshop, contact us and apply. We can add you to our list and let you know of a future date for the workshop, or we can organize one for your team.
