The Big Misconception in Scrum
“You keep using that word. I do not think it means what you think it means.”
The big misconception is the usage of one specific word: Requirement. Scrum guide uses it. I guess we all have used it, but let’s pause for a moment and reflect on the definition of Requirement.
The etymology of Requirement according to Merriam — Webster dictionary:
“Something stipulated as necessary to be done, made, or provided. A necessity, something essential.”
The Business Analysis Body of Knowledge (BABOK) states a Requirement is
1. A condition or capability needed by a stakeholder to solve a problem or achieve an objective.
2. A condition or capability that must be met or possessed by a solution or solution component to satisfy a contract, standard, specification, or other formally imposed documents.
3. A documented representation of a condition or capability as in (1) or (2)
Especially BABOK follows with detailed information on types and characteristics of requirements. And it gives us lots of ideas to guarantee we get “good” requirements.
The problem? In my 20+ yrs. experience in Software Development I have observed what Kent Beck called ”a connotation of absolutism and permanence” precluding us from having meaningful conversations. Conversations on problems, people and value. Or, as Jeff Patton writes in this amusing anecdote “Requirements actually mean ‘shut up’ (and do)”.
We’re talking about requirements, we are automatically cornered. We have separated problem space from solution space. The only thing left to do is execute.
The wrong questions
Scrum was done quite a disservice as Jeff Sutherlands (otherwise excellent) book suggests Scrum is about “twice the work in half the time”. No wonder many people, especially higher-level managers, think: “Great, finally we can deliver all those requirements that were lingering for half a decade. We have put so much effort and analysis into them and we KNOW that we need to do them.” At this point all we are talking about is “how can we do this” or even worse “when will we do this”.
As a side effect this notion often leads to overblown backlogs with many hundreds of entries. Is proper prioritization still possible with large backlogs? No. Incorporating customer feedback? Very rarely. But I have seen countless times it will lead to pressure on teams to deliver faster. Now let’s again pause for a moment and reflect.
What if all those requirements were not requirements at all? As Marty Cagan puts it:
Customers think they have “requirements” but they’re just a hypothesis on what might solve some probably unstated problem.
Stakeholders have “requirements” that are really just their personal theories or assumptions on what might solve again a probably unstated problem.
An assumption? A hypothesis?
Even when setting the HiPPO (Highest Paid Persons Opinion) problem aside, we all are very biased when it comes to our own views. Current state of research is very clear though. Our intuition is poor, 60–90% of ideas do not improve the metric(s) they’re designed to improve. This number seems high to you? Have a look at Ron Kohavi’s paper on Experiments, Section 5. Or QualPro, a company that tested 150,000 business improvement ideas over 22 years and reported that 75 percent of important business decisions and business improvement ideas either have no impact on performance or actually hurt performance.
On a side note, if you’re about to read only one book this decade, let it be Daniel Kahneman’s ‘Thinking, Fast And Slow’. His System 1/System 2 theory explains human bias and decision-making. The numbers above go well in line with his observations.
Making a difference
If we can acknowledge these facts all of a sudden we have a fundamentally different discussion:
- What are we willing to spend/what can we afford to lose on our hypothesis?
- How will we measure or test whether our assumption holds water?
- How can we (in-)validate our theory with the least possible cost?
- …
With these questions in mind the conversation moves over to “Why should we do this?” and “What else could we do with limited resources?”. And as a by-product you will have developed key metrics for success.
At this point someone usually brings up the regulatory issue. “We need to do this because it’s a legal requirement”. Could be. Then again, it is still a hypothesis that proposed solution X will solve that issue. Might be there is a different solution that will only cost half the money. In this case I would rather talk about “constraints”. To make sure we’re still having the right conversation. To keep the solution space as wide open as possible.
Conclusion
Language shapes reality, so forget about Requirements. Instead state the problem. Develop a hypothesis. Run experiments. Measure and repeat. Become a learning organization.
Do you want to write for Serious Scrum or seriously discuss Scrum?
