RE: [scrumdevelopment] Cracking the budget conundrum
- Looks pragmatic, atleast for some of the situations
I've been in.
--- Paul Lear <paul.lear@...> wrote:
> I don't know the 'right' answer, but I can tell you<http://geo.yahoo.com/serv?s=97359714/grpId=1569064/grpspId=1707209021/msgId
> 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
> To: email@example.com
> Subject: [scrumdevelopment] Cracking the budget
> 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
> 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
> 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
> the case.
> 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"
> Any thoughts?
> Bazil Arden
> PS: I've looked through ScrumDevelopment - but
> cannot find specific
> answers to this
Yahoo! India Answers: Share what you know. Learn something new