The most difficult part of discovering and analyzing requirements on agile teams is determining how much detail is needed and when we should discuss the details. Early advocates of agile approaches, like SCRUM, emphasized a high level product vision at the beginning of development and then quick, lightweight user stories to support the vision detailed before each sprint. They suggested that we don’t need to get into any details until sprint planning. But as more and more teams are attempting to use agile approaches, the challenges of this requirements approach are exposed.
Sometimes we need to get into details early to make sure we really understand where we are going. Developing requirements for an agile team is an elegant dance integrating broad product feature descriptions with as-needed detailed agreements about usability and technical interfaces.
The Dance of the Details
There are many reasons that our discussions about requirements need to get into details earlier than many would like, but here are 4 that come to mind:
1. Most people can’t visualize a new product before “seeing” how it will work. Recognition of this is an Agile strength. Broad product value statements created using techniques like a Product Box don’t help the Product Owner and other users get a concrete mental picture of what we are building.
2. Each individual human being learns differently. Neuroscience has shown that we need to add new knowledge to our “repository” by attaching it to something we already know. If you listen carefully to people talking about a new product idea, they will often compare the new idea to something they already know. “It could be like Amazon” or “it could be like the Uber app”.
3. To make sure that our product vision will work with other products and systems we need to talk about how interfaces will be built. This discussion may have both a business aspect and technical aspect. Do the products share data? Do they define it the same way? How will the data be transferred, validated, and secured?
4. And most importantly, business rules and business data elements must be identified and confirmed before we get too far down the release planning and prioritization paths. We need to make sure we understand the complexity needed to support the users and talk about which detailed features are more important or valuable than others. If we don’t have a strong business model as a foundation, we won’t build a product that is valuable and maintainable.
If you mapped the level of requirements detail discussions across time during the duration of product development you would expect to see a line going from less details during visioning to more details during iteration (or sprint) planning.
But if you really tracked the discussions and their level of detail the graph would look like this:
Notice how we start at a high level but as we discuss product features and values, we alternate between less and more detail. (See why I call it a dance?) During visioning the discussion will take quick dips into the detail. These dips are needed to clarify understanding, flesh out an idea, or get agreement on the product direction. A strong facilitator watches as the discussion gets into increasing levels of details and periodically asks the group if this detail is critical now or can be discussed later.
The conclusions: Everyone on the team must be aware that discussions about requirements will “dance” between high level and details, and you need a strong facilitator for agile requirements discussions to make the dance easier.
RMC offers an Effective Agile Requirements class which demonstrates the “dance of the details” using a case study project with complex requirements analysis. Contact us to learn more, info@rmcls.com.
- Satisfying Stakeholders with Agile Requirements - January 25, 2023
- Business Analysis: The Best Way to Start a Project - March 2, 2022
- Three Proven Ways Analysis Prevents Scope Creep - December 29, 2021
