20811RE: [scrumdevelopment] Cracking the budget conundrum
- Mar 31, 2007I don't know the 'right' answer, but I can tell you what worked for me. I'm a recovering PMP, so I have no problem presenting in terms that corporate capital committees understand. Start with your initial product backlog, prioritised and estimated. Then develop sequence of sprints and group into a release roadmap. I use this to develop a scope and implementation plan for a project charter. Calculate the burn rate (people costs x months) to get your budget. The level of certainty in the estimates is used to determine the contingency budget (e.g., +/- 25%). If they think your uncertainty is too high, propose a few sprints (fixed price, based on team size x rate x time) to refine the estimates. Then you'll have a good velocity to work with, and maybe a few spikes to better size your stories. So, you have scope, budget, release plan. What else do they need? Resource plan, risk plan, ...? Pretty easy to pull together. Format that into their standard PowerPoint deck, and you're ready to go.Now, as your product owner reprioritises the product backlog and the team decides on the actual work for each sprint, take half an hour and fill out the 'Change Control Form' to record any change in scope, timeline or budget. To satisfy the powers-that-be, every month I would drop the major stories on to a PowerPoint slide that looked like a Gantt chart, based on the order of the backlog. Put nice green check marks next to the completed stories, and everyone is happy.Paul Lear
From: email@example.com [mailto:firstname.lastname@example.org] On Behalf Of bazil_arden
Sent: March 30, 2007 10:14 AM
Subject: [scrumdevelopment] Cracking the budget conundrum
Please help me with some convincing arguments for organisations that
have a requisition process and need to sign-off a fixed amount of
money for a pre-defined solution (often months in advance)
Agilists would say;
- you can stop paying when you have what you want (which could be less
than your original cost estimate)
- get the highest value features early and deploy them when you want
- benefit from productivity gains and a better overall solution
- don't pay for the 64% of features that go unused
- lower maintenance costs - from refactored, simpler code (i.e.
budgets should reflect the life of the solution - not just its creation)
- reduce risk (of project diverging from the business)
But none of this fits their existing method for buying custom software.
Budgets (& contracts) give the purchaser a *sense* of certainty and
therefore managed risk - when in fact for various reasons (see
Standish report and numerous examples in this forum alone) this is not
I am working with medium sized new media companies and their most
common concern is "our client has a budget, and we need to say what we
are going to deliver for that money"
PS: I've looked through ScrumDevelopment - but cannot find specific
answers to this.
- << Previous post in topic Next post in topic >>