[SCRUMDEVELOPMENT] estimation enquiry

[Osaki Miller Thom-Manuel [e-mail] [SCRUMDEVELOPMENT]]

Greetings,
I have never  executed any software project using agile. But there is one thing that is certain in every implement of software system and that is estimation. 
Supposing, as a team of agile developers working in a software developing firm , a client comes up with the need for automating a particular process. Certainly it is normal for him to be told what it will cost him after he must have given the description of what we wants.
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?
 if yes, pls how is done ? if no, what is to be done?
thanks

[Alan Dayley [e-mail] [SCRUMDEVELOPMENT]]

Osaki,

You will not get full answers to your questions via email. Why? Because it
would take a book to answer.

So, start with this one:
https://smile.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415

Alan

Post by Osaki Miller Thom-Manuel ***@yahoo.com [SCRUMDEVELOPMENT]
Greetings,
I have never executed any software project using agile. But there is one
thing that is certain in every implement of software system and that is
estimation.
Supposing, as a team of agile developers working in a software developing
firm , a client comes up with the need for automating a particular process.
Certainly it is normal for him to be told what it will cost him after he
must have given the description of what we wants.
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?
if yes, pls how is done ? if no, what is to be done?
thanks

[Silvana Wasitova [e-mail] [SCRUMDEVELOPMENT]]

In addition to Alan's recommendation, to answer the other question, yes, it is possible, and it is frequently done. It is not the optimal arrangement, but it can work, and agile often gives better results than the traditional ways.

Scrambled on my iPad

Post by Alan Dayley ***@dayleyagile.com [SCRUMDEVELOPMENT]
Osaki,
You will not get full answers to your questions via email. Why? Because it would take a book to answer.
So, start with this one: https://smile.amazon.com/Agile-Estimating-Planning-Mike-Cohn/dp/0131479415
Alan

Post by Osaki Miller Thom-Manuel ***@yahoo.com [SCRUMDEVELOPMENT]
Greetings,
I have never executed any software project using agile. But there is one thing that is certain in every implement of software system and that is estimation.
Supposing, as a team of agile developers working in a software developing firm , a client comes up with the need for automating a particular process. Certainly it is normal for him to be told what it will cost him after he must have given the description of what we wants.
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?
if yes, pls how is done ? if no, what is to be done?
thanks

[Matt Heusser [e-mail] [SCRUMDEVELOPMENT]]

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

[Jim Schiel [e-mail] [SCRUMDEVELOPMENT]]

Amen.

Sent from my iPhone

"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.
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."
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.
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