User Stories are not requirements

I always struggle with the word “requirements”. This is how specifications and functionalities are normally called when working on a project. Requirements create a blanket of necessity and limit the empowerment of product managers to be effective at solving problems.

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.

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.

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, judgment.

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.

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.

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

Just for fun I spent some time Googling the word “require” and looking at its etymology. The English word derived from the Latin word requiro. Requiro has a broader meaning than “require” as it includes “to seek” and “to ask for”. That is, at the origin, requirements included an element of discovery and learning.


Want to master User Stories and learn advanced techniques to split Epics and Stories?

The CPIA – Beyond User Stories training and certification is a 1-day workshop focused 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 CPIA program, visit:

User Stories are not requirements