There's a grand myth about requirements: If you write them down, users will get exactly what they want.
That's not true. Even with the best set of project requirements in place, users will get exactly what was written down, which may or may not be anything like what they really want.
That's one of the reasons agile project management frameworks, like Scrum, forego a lengthy, upfront requirements phase and the resulting product specification in favor of a dynamic product backlog, often written in the form of user stories.
Product Backlog vs Requirements
Product backlogs don't eliminate project requirements or the need to work with stakeholders and customers to gather requirements They do, however, help to account for three truths:
- Teams can never know every requirement upfront
- Conversations are the most effective way to share information
- Risks are less risky when they are uncovered early
Three Types of Requirements
In discussing agile and requirements management, it’s important to realize there are really three different types of requirements: known, overlooked, and emergent.
1. Known Requirements
First are the known requirements. Known requirements are ones users tell us about. Business analysts and product managers have honed good requirements gathering techniques for agile projects: interviews, story-writing workshops, open-ended questions, and more.
2. Overlooked Requirements
Overlooked requirements are what we call the requirements that we missed during our talks with users.We’re fallible. We don’t always ask good questions or the right type of questions. Users seldom think of everything. Maybe a user interview was cut short, or a user was absent from a story-writing workshop
Overlooked requirements are just as important as the known requirements, but we somehow missed them, didn’t hear them, or the stakeholders never mentioned them.
3. Emergent Requirements
There's one more type of requirement that no requirements gathering technique can uncover. It isn't something we overlook or something known. Emergent requirements are ones that surface through the act of building the product.
The team demonstrates what has been developed so far, and users say, “What would really make this great is…”Emergent requirements develop as we learn more about what we're creating.
Emergent requirements are not things the team should have uncovered during a story-writing workshop or from interviews. They are not things the development team could have identified if they’d just thought harder or longer when asked about what they need.
Examples of the 3 Different Requirements Types
Suppose you’re at a grocery store, doing your shopping for the week. Items on your shopping list represent your known requirements. You knew they were needed, so you added each to the list.
As you walk the aisles, you see orange juice and realize you’d forgotten to put that on the list. Orange juice is an overlooked requirement.
Then, you round the corner and put something in your cart that you didn’t even know you needed? It wasn’t on your list (a known requirement) and it wasn’t something you’d merely overlooked. Instead, you found something you didn’t even know you wanted until you saw it. It was an emergent requirement.
This happened to me about two years ago. I noticed something that looked like a huge, pimpled orange. It was called a Sumo.
A store employee offered me a sample. It was delicious. And I immediately put four Sumos in my cart.
Before I saw them and tasted one, I had no idea I wanted one. I didn’t even know Sumos existed. On that shopping trip, Sumos represented the third type of requirement: an emergent requirement.
The same thing happens on projects. Having seen a partial implementation, users identify new things the product should do. New business requirements, solution requirements, and stakeholder requirements come to light that could never have been anticipated.
Risk & Planning for the Unknown
Emergent requirements often cause projects to be delivered late. Since emergent requirements cannot be eliminated, the best strategy is to seek them out as early in the development process as possible.
This means that product owners should consider parts of the system that are most likely to include emergent requirements alongside the most desirable features when prioritizing their product backlogs. That way, teams can put working product in the hands of their users and surface any emergent requirements.
The Universe of Requirements
The universe of requirements can be conceptualized using the following figure. On the left are the known requirements that come out of our discussions with users and other stakeholders. On the right are the overlooked and emergent requirements, which collectively make up a project’s unknown requirements.
Every project—well, maybe not a rewrite of Minesweeper—has emergent requirements. No matter how adept team members are at asking questions or how thoroughly users have thought about their own needs, not everything can be identified upfront.
Teams can often do better at reducing the number and significance of overlooked requirements. We can ask better questions, listen more actively, spend adequate time with users, and so on. But a truly emergent requirement is one that a team cannot rightfully be expected to have uncovered until users start seeing early versions of the product.
How Have You Handled Emergent Requirements?
Emergent requirements often cause projects to be delivered late. Since the needs haven’t been discovered yet, teams often fail to consider them when planning. Has a project you worked on been affected this way by emergent requirements? How have you handled them?
Please share your thoughts in the comments section below.
