Notes on Agile Requirements
This article contains my key learnings from watching the Agile Requirements course on Construx Online.
People tell you what they want NOT what they need.
It is our job to help people to discover what they really need.
Product owners answer the question:
- What problem/opportunity should we solve?
The development team answer the question:
- How do we solve that problem/opportunity?
What is a requirement?
There are many definitions of requirements at a different level of formality.
However, most definitions are not very useful in practice.
This course introduces probably the most pragmatic and practical definition I have ever seen.
A requirement is a decision that we impose on the implementation.
There are different kind of decisions at different scopes.
There are high-level decisions at the product and project level and there are low-level decisions at the feature and work-item level.
A complete requirement is a combination of a function and one or more non-functions.
A function defines what the product must do:
- Actions to take
- Information to remember
- Rules/policies to enforce.
We can delivery the function but still provide no value!
This is why non-functions are also essential to form a complete requirement.
There are non-functions at the problem space and at the solution space:
- Effectiveness, efficiency, freedom from risk, context coverage, satisfaction (problem space)
- Functional suitability, performance, compatibility, usability, reliability, security, maintainability, portability (solution space)
How to elicit requirements?
One of the difficult problems in eliciting requirements is how to do it systematically and how to know when you are done.
Given something you have been asked to solve/decide (solution space) follow this hierarchical approach:
- Identify all adjacent areas (problem spaces).
- Identify the decisions this area impose on the solution (functional requirements)
- Identify non-functions this area impose on the solution (non-functional requirements)
- Identify non-functions in the solution space
There is usually a mapping between the problem/opportunity space and the solution space.
Don’t confuse elements of the solution space as requirements. Those are solutions.
Watch out for trying to solve the problem when interviewing customers or stakeholders!
Focus on trying to reduce ambiguity in the problem space as much as possible.
What about user stories?
User stories capture needs, not implementation.
User stories are simple placeholders for requirements.
A common model used to create user stories is the INVEST Model.
Make sure your stories are independent, negotiable, valuable, estimable, sized correctly, testable.
User story mapping is a technique to arrange stories into a useful model for understanding system functionality.
It can help to identify the minimum marketable feature.
The most used UML diagrams for mapping requirements are:
- Use case model, Context diagram, Activity model
- Domain model, Use cases, State diagrams, Decision tables
Identify the few changes that can impact the perception of quality the most.
What about prioritization?
Agile is about fixing the schedule and adjusting the scope to deliver what our customers need in priority order as fast as possible.
The Kano Model is a useful approach for prioritization.
For each piece of work, ask the following questions:
- How happy would the customer be if it was there?
- How upset/angry would the customer be if it was missing?
…and then map the answers on a graph.
T-Shirt prioritization is also a very common practice.
Use imprecise natural language estimate (t-shirt sizes) to get a rough order to a group of requirements.
It’s similar to the Kano Model but use business value vs development cost as a metric to decide what to work on.
Conclusion
Thinking about requirements as decisions imposed on your implementation is an extremely useful way to understand and define systematically the requirements of a software system.
Focus on listening to reduce ambiguity in the problem space and understand what your customers really need.
Tools like the Kano Model and T-Shirt sizes helps to prioritize the work to be done to deliver quickly and maximize value.
