Understanding what the business users are trying to achieve can significantly help you focus the project on things that really matter. In this excerpt from Gojko Adzic's book Specification by Example, the author offers some tips for effectively collaborating on the project scope when you don’t have high-level control of the project.
For most teams I work with, especially those in big companies, scope is something passed to them from a higher instance. Many teams think that it is impossible to argue about business goals when they maintain only a piece of a large system. Even in such situations, understanding what the business users are trying to achieve can significantly help you focus the project on things that really matter.
Here are some tips for effectively collaborating on the project scope when you don’t have a high-level control of the project.
Ask How Something Would Be Useful
Stuart Ervine worked on a back-office application for a large bank that allowed business users to manage their counter-party relationships in a tree-like hierarchy. That is a perfect example of a small piece of a large system. But even then, they were able to push back on tasks and get to the real requirements.
His team got the task to improve the performance of the hierarchy, which sounds like a genuine business requirement with a clear benefit. But the team could not replicate any performance issues so any serious improvements would require infrastructural changes.
They asked the users to tell them how improved performance would be useful. It turned out that the business users were performing a complex calculation manually by going through the hierarchy and adding account balances. They had to open and close tree branches in the user interface for a large number of counterparties and add account balances for this calculation, which was a slow and error-prone process.
Instead of improving the performance of the hierarchy, the team automated that calculation for the business users. This made the calculation almost instant and significantly reduced the possibility of errors. This solution delivered better results cheaper than the one originally requested.
Instead of a technical feature specification, we should ask for a high-level example of how a feature would be useful. This will point us toward the real problem that needs to be solved.
I advise asking why and repeating the question until we reach the money. I now think that asking for an example of how a feature will be useful is a much better way to get to the same result. Asking why something is needed can sound like a challenge and might put the other person in a defensive position, especially in larger organizations. Asking how something would be useful opens up a discussion without challenging anyone’s authority.
Ask for an Alternative Solution
In addition to asking for an example of how something would be useful, Christian Hassa advises discussing an alternative solution to get to the real business goals. Hassa explains:
Sometimes people still struggle with explaining what the value of a given feature would be (even when asking them for an example). As a further step, I ask them to give an example and say what they would need to do differently (work around) if the system would not provide this feature. Usually this helps them then to express the value of a given feature.
Asking for an alternative solution is a good strategy to discover additional options from a business perspective.
Asking for alternative solutions can make whoever is asking for a feature think twice about whether the proposed solution is really the best one. It should also open up a discussion on alternatives that the delivery team might suggest.