Getting requirements from customers is key! Let's talk about this topic today.
As usual, don't forget to answer the questions at the end of the article to get the chance to win prizes.
See participation rules and event schedule.
Getting Requirements From Your Customers
Before the arrival of Agile methods, requirements were often gathered in a waterfall phase before development started. Sometimes before the development team had even been hired. This approach led to many cost overruns and project failures.
In response, lightweight methodologies began to emerge, which, with the publishing of the Agile Manifesto in 2001, were given the collective name “Agile.”
User stories
Several Agile methods use user stories to capture high-level functionality that users of the system might need, but defer detailed requirements analysis until the functionality described by the story is about to be developed. Hence, the early description of a user story as a “placeholder for a conversation.”
User stories should not be thought of as requirements. Instead, they should be treated as descriptions of pieces of functionality that can be prioritised for delivery, which act as reminders of which requirements need to be discussed in detail next.
Many Agile teams treat a user story as immutable during these discussions, but it is far more likely that the story will need to be updated (in response to insights gathered during discussions), or split into several/many smaller stories (to facilitate incremental delivery of multiple stories within each iteration).
Deliberate discovery
The conversations that result in detailed requirements are best conducted by small cross-functional groups. Traditionally, each group should contain at least one representative for the customer, the development team, and the test team – this led to the meeting being called “The Three Amigos.”
A more accurate name is “deliberate discovery,” because the goal is to deliberately explore the story to uncover any ignorance we may have and discover the detailed requirements.
To ensure that the maximum amount of knowledge is discovered (and captured), a technique called Example Mapping has been developed. In short workshops, the group explores their understanding of the story by creating concrete examples of how the finished functionality should behave. The goal is to identify the rules (requirements) that govern the system’s behaviour, and associated examples that clarify any ambiguities and edge cases.
Living documentation
Some teams go further, formulating the concrete examples using business terminology, then automating them using tools like Cucumber or SpecFlow. The resulting business-readable specification enables all stakeholders to participate in the evolution of the product. Automation of the specification guides development, and contributes automated acceptance tests that deliver value for the lifetime of the product. Additionally, the automation effectively makes the specification self-validating, meaning that the team (and any future team) has trustworthy documentation describing the delivered functionality.
Traceability
To manage risk, organisations need to know what functionality has been requested, what functionality has been delivered, and whether it works as expected. Whether tracked through heavyweight=requirement management tools (such as DOORS), or on an ad-hoc basis using spreadsheets, this sort of traceability has always been necessary.
User stories are neither necessary nor sufficient to deliver traceability. The living documentation comprising of rules (business requirements), automated examples (acceptance tests), and results give comprehensive traceability from requirement to successful delivery. Even better, this traceability is as accessible to the customer as it is to the compliance professional.
Getting the true value from Agile
Customers know the business outcomes that they want, but turning this into detailed requirements is a challenge.
Waterfall approaches don’t work well in fast moving, innovative marketplaces, which has led to the prevalence of Agile methods. Many organisations, however, haven’t successfully integrated requirements analysis into their Agile approach – either by treating user stories as requirement surrogates, or by writing detailed requirements in isolation.
We need customer involvement throughout the delivery process and, to do this, we have to work in a collaborative way using inclusive techniques. Deliberate discovery using example mapping is one such approach. By capturing the examples as business-readable specifications, the customer can remain involved.
By automating the specifications, the customer can watch functionality get delivered – and can be confident that when the product needs enhancements there will be reliable documentation available. And there will be traceability from requirement to acceptance test result as a side effect.
Further reading
- https://cucumber.io/blog/bdd/user-stories-are-not-the-same-as-features/
- https://cucumber.io/blog/bdd/better-requirements-by-harnessing-the-power-of-exa/
- https://cucumber.io/blog/bdd/how-does-bdd-affect-traceability/
What do you think? Comment below!
We'd love to hear about your experience of getting requirements from your customer:
- Is your customer involved in conversations with the delivery team? Should they be? Do they want to be?
- Do you use user stories as requirements? What challenges, if any, have you experienced?
- What effort do you have to make to ensure compliance with internal quality processes or external regulators? Is traceability something that your team cares about?
