AGILE, User Stories & Requirements

Challenges with User Story

“Deliver Value to Customer faster, minimize bureaucracy”

Dr Alistair Cockburn

What a great definition of Agile from Dr Alistair Cockburn! The highest priority for any company should be to satisfy customers through early and continuous delivery of valuable product. So, why are so many companies struggling with this?

Based on our experience, there are many reasons: development testing, company culture, hierarchical organization, requirements…

Let’s focus on requirements!

What is the problem with requirements?
  • Requirements do change and often – Different surveys show that more than 35% of all requirements change during a typical project.
  • Very often the client doesn’t know what he/she exactly wants (which is ok, because, as they say in product management, the client owns the problem, we own the solution) – Even if a client knows what is needed, he/she may struggle to articulate or define requirements. And even if the client defines the requirements very well, we may have completely misunderstood the client and implement something completely wrong.


…the problem with requirements is a communication problem

What should we do?

User Story is an Agile requirement technique which can help with this challenge. User Story is a great technique for representing requirements.

However, many teams have difficulties in using User Stories.

Challenges with User Story

User Stories are too big (Epics)

These stories can’t get done, and they are “travelling” from sprint to sprint. It is very demotivating for the team, impede flow, velocity; it slows down team learning. Epic should be split in smaller User Stories before taken into a sprint. When we have small User Stories that are well understood, actionable and valuable, then they are ready to get done.

User Story is unclear to development team or Product Owner

Typically, there are no clear acceptance criteria and team is struggling to understand scope of the story, how this story fits with the overall goal of the product, or how to specify the tests. Team members need to understand certain things about User Story to implement it well. Unclear User Story causes lots of waste during a sprint, and again stories are traveling from sprint to sprint.

Lack of conversation about User Story

User Stories are placeholder for further conversation: they’re complemented with conversation that takes place between Product Manager/Product Owner and team. Lots of companies apply User Stories without additional conversation: to account for missing conversation, Product Owner tries to write detail-rich and precise User Stories, which isn’t what User Stories are for. Make sure that an effective conversation does take place (for instance, by having regular onsite workshops or using videoconferences to discuss and adjust the stories with the team). Alternatively, use different description techniques for requirements, such as Use Cases (Use Cases offer more structure and make it easier to precisely describe a requirement, for instance, by using pre-conditions and exception scenarios).

Wrong purpose

User Stories describe end-user requirements, they aren’t designed to capture technical requirements. If teams heavily rely on technical requirements, then this may indicate that teams are component teams (teams that are organized around architecture building blocks, such as components, services, and layers). Typical example of wrong use of User Story for technical requirements is “As a developer I want …” Unless developer is end-user of product, this is wrong way of defining a requirement. An effective way to reduce the need for technical requirements is to reorganize the teams by forming feature teams (teams that implement User Stories end-to-end in form of a vertical slice).

* There are teams working on products that require component teams. In situation like this, User Stories are not the best way of formulating requirements, then, there are alternative, better suited techniques.

So, what can we conclude from all of this?

A User Story is not a specification, but a communication and collaboration tool.

A User Story shifts the focus from writing requirements to talking about requirementsEssence of a User Story is to discuss the User Story with the userA User Story tells a story, it describes how a customer/user employs a product in a simple language. The Product Owner is responsible for Product Backlog and he/she represents customers. Therefore, the Product Owner should really put an effort in understanding customer’s needs, and User Stories can and will help. User Stories should never be handed off to a team. Instead, a Product Owner and a team should discuss User Stories together during a sprint typically during a sprint grooming, or at latest during a sprint planning. Team should allocate up to 10% of capacity during current sprint for sprint grooming to refine User Stories for the next sprint. Effective communication is the key for requirements, and a User Story is the common language to build understanding between user and team.

User Stories like these are one of the most challenging moments in Product Owner’s vocation, especially during a sprint planning. Agile Serbia besides all educational aspects, organizes Inhouse programs in order to help clients to cope with challenges like this. If you need help with this matter, you know where you can find us.