Re: estimation enquiry

Okaski Miller asked:

"is it possible for him to be given a cost estimate or a fixed cost of what
he should be expecting as what he will pay?"

Well, here are some assumptions followed by some options.

Assumptions:

A) The requirements are 'squiffy' and amibiguous; they will be eloborated
on as the software is developed.
B) The situation will change, such that even if you could do Big
Requirements Up Front (BRUF), those would be out of date before the project
is completed.
C) The customer will change their mind during development, often inspired
by seeing the software as it is developed and understanding "I know I asked
for this, but now that I see it being developed I realize what I actually
need."

Assuming those are true, here are some options:

1) Ask for the budget. Divide by cost per sprint. Congrats, the project is
X sprints. BOOM. Deliver working software each sprint, when the time runs
out, either get an extension or move on to something else.

2) Look at (Accurate) historical data for similar projects. "Well, this
project is in size roughly somewhere between Projects A and B, project A
was 20 person months with a team of 5 and project B was 24 with a team of
5. The technology and teams haven't changed, so I think the same team 5
will take about 5 months."

----> The empirical research i have seen is that option 2, done well, is
roughly as accurate as a full functional decomposition (break down into
small chunks, estimate them, and add them up), only it costs a tiny
fraction.

Option 3:

3) Break the work down into similar-sized stories, count stories, use Troy
Magennis's predicition algorithmn plus historical data to forecast duration:

https://github.com/FocusedObjective/FocusedObjective.Resources/blob/master/Spreadsheets/Throughput%20Forecaster.xls

----> Option 3 requires historical data.

4) Get a sprint to build a proof of concept that drives all the way through
the architecture. Once you've tried to do the hard stuff (and actually done
it, "tracer bullet" style), then you should have enough to do options 2 or
3, or have a good idea if option 1 is going to work.

No books required, but talking to people who've done it and reading a few
blogs will help. :-)

regards,

--
Matthew Heusser,
Managing Director, Excelon Development
http://www.xndev.com

<http://goog_1863044068>


Save The Scrum! http://www.leanpub.com/SaveOurScrum