Comments on: Estimation in consulting

By: Joshua Barker

Joshua Barker — Fri, 20 Jan 2012 15:31:00 +0000

What is the difference from modeling and design?

By: Aluminium Kozijnen

Aluminium Kozijnen — Tue, 24 May 2011 12:35:00 +0000

Yeah that is correct.. Our customers don’t write checks in points. They write checks in dollars..

By: Bob Cravens

Bob Cravens — Wed, 18 May 2011 19:04:00 +0000

I personally like the pull-based paradigm also. With your pull-based flow, do you have metrics for lead time? For example, a cumulative flow diagram plotting story points versus time for the stories started / finished can provide lead time per story point. This can be used to convert story points to time in this flow-based paradigm.

I am glad that you have found something that works. I am curious still about the need to perform the detailed analysis (break down into tasks and provide hour estimates). It still seems a bit excessive to get to the 10-50% estimate.

By: Anonymous

Anonymous — Wed, 18 May 2011 18:36:00 +0000

We don’t do sprints. It’s all pull-based flow and lead time calculations.

Group estimation was a big waste. Sprint planning meetings were a waste. In fact, by the end of the scrum project, we weren’t doing scrum, we found a faster way to deliver without timeboxed sprints.

The ceremony around sprints were a waste, so we eventually ditched all of the activities. All those group sessions are really, really expensive and we found better usages of our time.

By: Bob Cravens

Bob Cravens — Wed, 18 May 2011 18:14:00 +0000

I don’t understand. You are breaking your estimate down into time (hours) to get to the the final cost. I propose that you can get the same estimate for time from story points and velocity. Then perform the same math to convert the time to cost.

v = your team’s average velocity in story points per spring
t = length of sprint in hours
sp = total story points for work

hours = sp / (v * t)

cost = hours * billing factor

The second equation we both end up using. I contend that calculating your hours from story points / velocity takes less time and provides an equivalent accuracy.

Not being a PITA, just curious as to if you are calculating velocity? If so, what issues were you having using it for your estimates?

By: Anonymous

Anonymous — Wed, 18 May 2011 17:38:00 +0000

Our customers don’t sign checks with points or lead time estimates. That’s not to say that what you lined out isn’t important or valuable, but that ultimately cost is what counts in a lot of cases. “How much will this cost” is a different question than “when can I have it”.

By: Bob Cravens

Bob Cravens — Wed, 18 May 2011 15:45:00 +0000

I am not suggesting you don’t or can’t supply an estimate. You certainly can and should. I am suggesting the following:

1. Collect user stories that define the work to be done.
2. Estimate these using story points (much faster than breaking down into tasks and estimating hours)
3. Use your team’s velocity to convert the story points into the lead time for the work.
If a team has reached gone through the forming/storming/norming/performing phases, then their velocity should be known enough to provide the estimates within the certainty discussed in the article (10-50%).

My question to Jimmy (or others) is using the velocity as a conversion flawed? If so, how?

By: Andrew

Andrew — Wed, 18 May 2011 15:33:00 +0000

Bob, the difference here is that a Client is asking for an estimate to determine if the new work is going to enter the pipeline. It’s a bit different when dealing with external clients. You can’t expect to tell a client that you can’t do an estimate until you are about to do the work, because a client will tell you that they don’t want you to do the work until they have an estimate. It’s a nasty chicken/egg scenario.

It’s one of the costs of doing business.

By: Andrew

Andrew — Wed, 18 May 2011 15:31:00 +0000

What bothers me about Agile is all the ceremony about “complexity isn’t effort” or “effort isn’t hours”. When asked about how complicated something was, if you answered “Well, that’d take me about a day” you’d get slapped down because you are associated hours with story points. But really, as much as we all try and abstract it, it all boils back down to hours. For Jimmy, he just takes one additional step and converts hours into money that a client spends.

That’s why I like this approach, it eliminates unnecessary frustration by saying “Feature X will cost you $5,000″. That way a client can make a good, educated decision about it. Is adding this feature to my website worth 5k?

Any well written contract will have contingency baked in (Jimmy’s risk factor), so it’s unlikely that you’ll get screwed if there are unknowns that alter the time lines. If the client changes their requirements, you rip up the estimate and start again.

You also have to remember that if you get decent at estimating, you should be under budget sometimes as well, so even if you do have to eat a little margin because your estimate was 5% off on an individual feature, you potentially will make it up on the next. Of course, if you are always underestimating, then you need to adjust your factors a bit, but that’s a different issue.

By: Bob Cravens

Bob Cravens — Wed, 18 May 2011 14:44:00 +0000

Because story points provide a relative measure of complexity, they are easier to determine than providing hour estimates. Breaking stories into tasks and estimating hours on each task is quite resource intensive. Typically we only do this for stories that are about to enter the production pipeline (sprint). Breaking down all the stories up front, represents a waste in terms of lean.

Yes you owe it to your client to convert story points to hours. Typically, the conversion factor from story points to hours estimate is your team’s velocity. Are you calculating team velocity? If yes, then where do you feel the lack of accuracy in velocity is coming from?