In the “three amigos” band, the BA sets the tune. But it shouldn’t always be that way
During Requirements Discovery and Definition activities, products owners and business analysts lead the dance. The ideas they propose, the problems they present, and the solutions they suggest, set the tone for the requirements that are discovered and ultimately the solution that will be delivered. This can be good or bad. Done well, you can instil a deep shared understanding of, and empathy with, customer needs, and drive the team to find solutions that excel. But done badly, the way the requirements are initially articulated can set the team down a narrow path towards a solution that is not necessarily the best, and that, sometimes, doesn’t even match what the customer really needs.
In most organisations nowadays, it is common practice to review requirements (or “user stories”) before a sprint starts. Product owners and/or business analysts prepare these user stories and present them to the team during requirements discovery or sprint planning sessions, and the team evaluates how much work will be needed to deliver them.
Problems and solutions
The aim of requirements discovery is two-fold. Firstly, the team needs to understand what problem they are trying to solve. And secondly, they need to discover the best way to solve this problem. And although this seems simple enough, it is often a tricky mix to get right.
Product owners and business analysts will often present requirements in the form of detailed solutions, rather than problems to be solved. For example, a product owner will ask for a form or button to be added to a particular screen, rather than describing the business problem they need that form or button to solve. When a team is presented with a problem to solve, rather than with a solution to implement, they are much more likely to come up with more creative, more innovative solutions or more cost-efficient solutions.
Mature teams try to reason not in terms of solutions (the "what"), but in terms of value ("why") and of possible ways to deliver this value ("what-if").
The perils of anchoring
A more subtle problem comes from Anchoring. In Psychology, anchoring is a form of cognitive bias where we latch on to the first idea we hear, and give it much more importance than the ideas that follow. It subconsciously becomes our “gold standard”, the idea against which all other ideas are compared and judged. It’s a bit like when someone buys a used car. If they initially focus on the number of miles on the odometer, the milage will become the first thing the salesman talks about for every other car, even to the detriment of other potentially more important factors such as the state of the engine. If we are looking for a new house and the first house we visit is near a railway line, the surrounding noise will become a prominent factor when we evaluate every other house we visit. The same thing happens in finance, when investors are reluctant to sell an overvalued investment because they have seen that historically the price has been much higher.
In the context of Requirements Discovery, anchoring happens when a group focuses on, or spends undue time on, the first solution presented, even when this solution is not necessarily the best. When the conversation starts at the solution level (for example what button to add, and on what screen), it generally stays at this level, and superior solutions that might have been found with a broader, more high-level approach can easily be missed.
The problem becomes much worse when the proposed solution comes from the product owner or the business analyst; any teams find it difficult or unnatural to challenge ideas coming from an authority figure, even if they are wrong.
All of these issues are subtle and pervasive, and they are largely capable of sabotaging a team’s ability to deliver a high quality solution. But the first step towards avoiding these pitfalls is becoming aware that there is a problem.
RELATED EVENTS AND WORKSHOPS
Low Tech High Impact Sprint Planning
Set your team on the fast track to delivering high quality software that delights the customer with these simple, easy-to-learn sprint planning techniques!
BDD in Action: Mastering Agile Requirements
Focus on the features your customers value the most by building a shared understanding of the real business needs, and empower your teams to deliver more optimal and more reliable solutions sooner!
