There are eight key differences that I’ve picked up in writing a business case for an Agile project. This post discusses those 8 differences and what you need to consider when creating your business case using this method.
1. Cost estimates – Iterations and Time boxing
Cost estimates calculated with a “Good enough to get started” approach are the flavour. This basically means that you look at and cost what it means to fund the initial investigation into the product and one or two iterations.
I have also seen mention that you “don’t estimate further than you can see”. This approach is about establishing the list of features and the expected outcome i.e. what the business owner is wanting delivered and you only cost the iterations or the ‘time-box’ i.e. how long it will take to deliver that.
2. Benefit setting
Benefits can’t all be listed up front. As work progresses and iterations delivered, more features added to the base product, benefits will become visible. Benefits in the business case should therefore be reviewed during the life of the project. Report updated benefits as they become apparent.
3. Minimised Risks associated with delivery
Risks are minimal initially as delivery is continuously aligned with desired business needs. As the project evolves this might raise other risks that need to be called out. Be careful not to think that because you are using a less risky approach to delivery, other risk areas don’t need to be looked at.
4. Faster ROI
The ‘base product’ delivered to market using Agile is functional, quicker. ROI is available more quickly. It is important to note that with the product being iteratively developed the full benefits of the product may not be delivered until further into the project and so whilst an initial product may be available the full return may not materialise until later.
5. Business Case testing
With Agile, project failure is identifiable earlier. Projects will be cancelled earlier, decreasing total spend. Your business case is tested during the initial phase. Money is still spent, but overall it might mean less cost and less wastage.
6. Feasibility is measurable
Feasibility is more measurable. This is done by prioritising and choosing the features for delivery. Testing shows areas that won’t deliver. This doesn’t mean your business case need to be less rigorous. Business case validity is tested based on feasibility of delivery.
7. Budget vs Costing
The budget available from the Sponsor or Owner is key. This is different to what it will cost to produce the product required.
This will impact the time frame for delivery. This is of course different to costing an end to end large delivery.
8. Estimating is still key
Reasonable estimating is still critical. Set clear expectations up front about what will and won’t be delivered. Back to the analogy of the Rolls Royce version vs the VW version.