Re: Re: estimation enquiry

Amen. 

Sent from my iPhone

> On Dec 7, 2016, at 2:52 AM, Matt Heusser [email protected] [SCRUMDEVELOPMENT] <[email protected]> wrote:
> 
> 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
> 
> 
> 
> Save The Scrum! http://www.leanpub.com/SaveOurScrum
>