6/11/2012
Today we had a meeting at a potential client and during our meeting the they asked the Million $ question. It went something like:Question, Using this agile thing how can we tell for our project when we will be done?
You Can’t
Which reminded me a story I heard about 20 years ago which went something like:A tourist arrives to the old city to see the sites, during the day he see this ragtag kid sitting and playing with his friend, he approaches this kid and ask “tell me, how long will it take me to get to the old market?”, the kids look a moment at the tourist and then turns back to his friends without saying a word. the tourist politely asks again which yield no better result. and even after nudging the kid he still gets no answer. Frustrated the tourist starts to walk away figuring the kid doesn’t speak his language and before he get very far he hears the kids shouting “about 15 minutes”. The tourist surprised walks back and ask the kid “why didn’t you answer me the first time” and the kids answer “How could I tell before I saw how fast you were walking?”
Estimate Effort Derive Duration
The sad reality of project management that we can never tell for certain when things will be done. the actual finish date depends on just too many variables which we have no control over. It can depends on the quality of our team members, on the mood they are in, on their health, on external events which are not related to our company at all, and that’s before I talk about the planned/unplanned changes to the product and requirements.When using an agile approach we acknowledge this reality and try to work around this. we do this by estimating the effort involved in developing the given features the best we can and by measuring the speed in which the team work through these features. Even done right it only helps us to claim the following:
Given that no changes will happen from now till the end of the project, based on past experience, most likely we work through the remaining features in X iteration/time and we can tell this with a probability of Y%. Naturally as X get smaller we expect that Y will become bigger.
Any other claim can be considered irresponsible.
Posted in: 
Posts
5 comments:
What is past experience, how do you measure that ?
I would advise the client, "You're done when you're satisfied with the product."
A development team can deliver a demo product every iteration for evaluation. At iteration end, the client has a simple decision -- stop or proceed.
Specifically, I would advise the client that at the end of each iteration, it's his option to (1) pull the plug, (2) correct course & proceed, or, (3) continue improving the product.
"Done" is when the product vision is met.
@Efi,
"Past Experience" in this context refer to the features/stories the team already finished to develop.
If you're using iterations you can measure it using "Velocity".another way is to use "lead time" or you can just track actual hours spent on a feature.
@Bob, yes. That's a very good way to define what is done.
But just to make things clear (which now I see was not). The client was asking how to tell the amount of time it will take to reach the "done" state.
Hi there, awesome site. I thought the topics you posted on were very interesting. I tried to add your RSS to my feed reader and it a few. take a look at it, hopefully I can add you and follow.
Function Point Estimation Training
Post a Comment