“Deliver Value to Customer faster, minimize bureaucracy”, what a great definition of Agile from Dr Alistair Cockburn! The highest priority for any software company should be to satisfy customers through early and continuous delivery of valuable software. So, why are so many software companies struggling with this? Based on my experience, there are many reasons: development testing, company culture, hierarchical organization, requirements.
Let’s focus on software requirements. What is the problem with software requirements?
- Requirements do change and often. Different surveys show that more than 35% of all requirements change during a typical software project.
- Very often the client doesn’t know what he/she exactly wants. 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.
So, the problem with software 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 are:
- 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 PO – typically, there no clear acceptance criteria and development 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. Developers 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 development 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. Two choices exist:
- 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 development 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 development teams heavily rely on technical requirements, then this may indicate that development 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).
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 requirements. Essence of a User Story is to discuss the User Story with the user. A 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 development team. Instead, a Product Owner and a development team should discuss User Stories together during a sprint typically during a sprint grooming, or at latest during a sprint planning. Development 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 software requirements, and a User Story is the common language to build understanding between user and development team.
User Stories like these are one of the most challenging moments in Product Owner’с vocation, especially during a sprint planning. Agile Serbia besides all educational aspects, organizes ONLINE Scrum Product Owner Course certified by Scrum Alliance.
Join our community and learn how to be the best!
