I have heard many project managers say "Scrum doesn't work with fixed cost projects!" when discussing approaches to software delivery.
I have pondered this and found that it is a difficult issue to solve.
My current thinking, is that the statement is kind of true.
But before you all jump up and down and protest... I think that the statement is true (in a way), but perhaps the "fixed cost" bit is actually what is wrong. Not Scrum.
Why do projects have to have a fixed cost? In order to "fix" cost, you have to estimate the project down to the finest detail up front. Trouble is, such estimates are always wrong. So you will end up either running over budget, or working late for free, or reducing functionality, or even quality.
So why insist on a fixed price? Why not get a clear set of high level goals, with an approximate release plan, with milestones as guides.
Get a rough cost, and release funding in small chunks, re-assessing at every milestone. You can react to changes in scope & requirements with out storing it all up and fighting the fire at the end of the project.
Am I being too simplistic?
1 comment:
Too simplistic? Not at all.
Surely it depends though on what burns money on the project? If, like most places I have ever worked at, the costs are almost entirely related to how many people work on the project for what length of time.
If you estimate the stories in your backlog, work out how many sprints you need to complete the work, factor in gaps between sprints at release boundaries and you have not only a projected end-date but also a projected cost (people * daily rate * project duration). With contingency built into the low priority stories, Scrum should work fine.
Post a Comment