Agile Business Case
Working Page for the Engagement Model Working Group – All Materials are DRAFT.
According to the DSDM Agile Project Framework an outline of an Agile Business Case might include a statement of:
- The business vision of success
- The scope and objectives of the proposed project
- High-level assumptions, dependencies and risk that may impact project viability
- Any alternatives that were considered and rejected
- The major deliverables of the proposed project
- High-level costs and benefits of the project
What differs an agile business case from any other business case? It might be that within agile, a business case is an evolutionary product.
Business valuation is an important skill within the capabilities of the Iasa ITABoK. As mentioned above, a high-level idea of the costs and benefits outcome of the project is expected to be a part of a business case statement. And that might be expressed through business valuation techniques. And business valuation might be a tool to validate a business case as well.
A rather new technique has grown within agile development for prioritization called weighted shortest job first (WSJF). WSJF has also been adopted as a core practice in the Scaled Agile Framework (SAFe). WSJF is based upon a concept called cost of delay, which is a way to coomunicate the impact of time on our expected business outcome. Hence it becomes a risk management tool, or actually rather a tool to hedge risk.
What are the elements and how do you calculate WSJF? Below is a small example:
|Feature||Business Value||Time Criticality||Risk Reduction||Job Size||WSJF|
Cost of delay is defined of business value + time criticality + risk reduction, and WSJF is calculated by dividing cost of delay with job size. Hence the calculated WSJF value of Feature #1 is higher and could be prioritized.
But where do the values come from? Since we within agile and lean work in a continous flow and WSJF main purpose is prioritization, we might as well use relative numbers and sizing. A technique called planning poker has been used for cost estimation (ie job size element above) within the agile community since quite long. Actually you could use that technique for any business value element as well.
But the use of fictitious numbers and up-front estimation has also been critized within the agile community lately. The reason for that is that there’s to much guessing involved and estimates are taken for granted as the actual truth. In fact, a whole movement has grown in the name of a Twitter hashtag called #NoEstimates. But rather than saying that estimates are useless, the idea is to track velocity over time and base estimates, or rather forecasts, on actual numbers.
And what if we could put actual numbers in the WSJF table above? Actually we should strive for actual numbers in our business valuations as far as we can. Business values doesn’t necessarily have to be expressed in monetary terms. And as a matter of fact, we can as architects do a lot more better within our own toolbox. As architects we’re the one and only advocates of the quality attributes. Those should be managed and monitored, for instance collecting metrics such as performance counters, audit logs etc, as a basis for business valuation.
You could use the WSJF prioritization technique at any abstraction level. Prioritize user stories in your product backlog at the team level, features and capabilities at the program level, as well as your product portfolio at the corporate level.
Related Topics and Resources
DSDM Agile Project Framework Products – Agile Business Consortium
Business Valuation – Iasa ITABoK Capability Guidebook
Investment Prioritization and Planning – Iasa ITABoK Capability Guidebook
Weighted Shortest Job First in SAFe – Scaled Agile Framework
Cost of Delay – Wikipedia
Probabilistic Forecasting – Troy Magennis
The #NoEstimates Movement – Barry Overeem
Risk Management – Iasa ITABoK Capability Guidebook
What Is Planning Poker? – Mike Cohn
Quality Attributes – Iasa ITABoK Capability Guidebook