Loading ...
Sorry, an error occurred while loading the content.

20811RE: [scrumdevelopment] Cracking the budget conundrum

Expand Messages
  • Paul Lear
    Mar 31, 2007
    • 0 Attachment
      I 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.

      From: scrumdevelopment@yahoogroups.com [mailto:scrumdevelopment@yahoogroups.com] On Behalf Of bazil_arden
      Sent: March 30, 2007 10:14 AM
      To: scrumdevelopment@yahoogroups.com
      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
      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
      www.AgileChange. com

      PS: I've looked through ScrumDevelopment - but cannot find specific
      answers to this


    • Show all 4 messages in this topic