Teams do relative estimations, business wants absolute estimations. How to make everyone satisfied?

Question

This is the case:

• Clients want to know how much time will be needed to finish a particular task (not the group of tasks). They are asking for man/days absolute estimation and only when they get it, they decide whether to approve or not.
• Teams are trying to avoid giving absolute estimations and to focus on relative estimations (t-shirt sizes for example)

The attempt:

• Use t-shirt sizes and agree with the team that sizes have ranges (XS-1 day or less, S-1 to 2 days etc...). Communicate to client highest or lowest number in that range. Track cycle time for sizes and then figure out what is the cycle time for XS, S, M, L...If you succeed in this, then communicate to client this cycle time?

Any thoughts?

Answer 1

I'm curious why you bother to do estimations at all if you don't have a way to eventually boil it down to approximate actual time. The only reason I can think of is to be able to say "that's too big" and break it down further.

Anyway, the most common way to convert your estimates is to measure your actual performance over the last several months. If you historically average 7 work days to fix a Large in the past, then odds are, you will average 7 work days in the future.

You can also get fancy and make a confidence graph like the evidence based scheduling graphs. That lets you give estimates like, "We average 7 work days on similar tasks, but there's a 15% chance it will take 2 weeks, and a 1% chance it will take a month."

Answer 2

The ultimate goal with any estimation approach is to be able to translate the estimates into 'real' terms. Otherwise, what would be the point? What use do t-shirt size estimates have if you can't translate them into real timelines?

The reason that relative estimation techniques are used is that people are absolutely terrible at estimating in absolute terms. On the other hand, people are pretty good at providing relative estimates e.g. comparing one task to another and saying which will take longer.

The part that it seems like almost everyone misses is that you are supposed to take the results from your previous efforts and build statistical models from them. You could just calculate the average days it takes to complete a task in each of the t-shirt bins and maybe the standard deviation as a simple start. It might not be up to the standards of a statistician but you could use it to produce a 90% estimate for completion for your customer.

The key is that you are basing these off of the real performance of the team. If you tell them small is 1-2 days, you are really going back to the absolute estimate with a little lipstick on the pig. Obviously this requires having some history to go on. If you are starting with a new team, you will probably need a different strategy, at least at first.

Answer 3

Either way, one side is going to be frustrated. And assuming "Client is always right" it is going to be developers. Really, only way to solve this is to play politics and either explain to clients that absolute estimation doesn't make sense (as there is always chance that something goes wrong). Or somehow "motivate" developers to give exact estimates.

Neither of those are satisfactory. And considering this is technical forum, there really isn't a technical solution.

Answer 4

You estimate with some leeway. You need to understand that clients have constraints. They usually want to know an estimation of time because they have a deadline or, they want an estimation of effort because they have a budget. Sometimes they will have both. It is never about how fast you'll do it, or how much money you'll save, but working with what resources they have available. If you are able to match something comfortable for them, you are good to go.

Working with shirt sizes is practical because it will account for some leeway. Just give it some equivalence in days/hours and you'll be able to give them a rough estimate.

Another approach is using Planning Poker (https://en.wikipedia.org/wiki/Planning_poker). The idea here is not to give an accurate estimation but to be consistent in what effort means for the team. If you divide work in sprints, the estimations that come out of the planning poker should be enhanced with every iteration, eventually getting to a point where similar tasks are estimated with similar values. The numbers here have the meaning the team wants them to have (so 1 could be a day's work or a couple of hours). And similar to the t-shirt approach, you can roughly translate those into man-days when you give the information to the client or business team.

Answer 5

In this situation, your client wants to decide - quite reasonably - whether they want a feature or not, depending on your best estimate of the cost, which is based on the time it takes to complete the feature.

You can refuse to give an estimate in man days. They will come back asking again, and will find you more and more annoying, and eventually might replace you with someone willing to give that estimate.

So what you should do: Forget your principles, and give the best answer you can. Before you do that, check whether the guys understand what an estimate is: With a good estimate, your chances are fifty/fifty that the actual time taken will be more or less than your estimate. If they understand this, give your best estimate. Not a number that's too low to please someone. They want an accurate number to make a decision based on it. If you work for people who think an estimate is a promise or a deadline, then you give a number where you are 90% sure at least you can give the results in this time.

If you are not able to support the business which needs to make decisions then you put yourself into a bad business.

OP: You are not capable to give me a number of weeks where you are 90% sure it will be done in that time? So if your best estimate is two weeks, you are incapable of saying “four weeks”? Really? And you can’t read a simple English sentence that didn’t ask about accuracy at all? You’re sure you shouldn’t switch to building tires?

Answer 6

From my experience estimates such as t-shirt sizes or story points should not directly be linked to concrete times because this mitigates their purpose. Typically their purpose is to focus on complexity of a task which can be estimates with relative to effort to provide a cost-efficient means to estimatation.

You could ask yourself what is the reason the team gives estimates in t-shirt sizes rather than man hours in your situation. Would you gain the same benefits when directly giving an estimate as a range of hours? If this is the case, then just do this and do not bother to map these to t-shirt sizes. If this is not the case, you should just stick to t-shirt sizes and perform any additional considerations on top of that.

If the team gives estimates in t-shirt sizes, it is still possible to derive estimates on required effort or time to completion. However, this should be a process separate from the estimation of complexity, as this burden cannot be put upon the team without mitigating the advantages of the estimation process. It should rather be seen as a forecasting process that takes into account certain empirical values such as the average time tasks estimated with certain t-shirt sizes took to complete in the past and provides a forecast based on this data.

The main point is to provide an environment in which the team gives estimates based solely on their true understanding of relative sizes rather than being influenced by project-management considerations.

If separated in this way, neither the estimates nor the forecast can be really wrong. Of course the team might be wrong on their estimate of relative sizes but this is to be expected due to the limited knowledge at the time of estimation which lies in the very nature of all estimation activities. The actually required effort or time to complete a task might also differ from the forecast, but, again, this lies in the nature of forecasting ans its probabilistic nature. The best you can aim for is reach a high likelihood rather than a low one.

What you can tell the customer is that based on your past experience with tasks whose complexity has been estimated similarly, that it will take a certain amount of effort, or more precisely you should provide a likelihood that it will fall into a certain range of effort. Here, you can use a wide range of estimation techniques and statistical methods.

From my experience, it can be worthwile to go through the difficulty of trying to clearly communicate the nature of estimation of complexity and forecasting effort to set up realistic expectations. The message should be that you have a common interest in forecasting requires effort so that the customer can take informed decisions. A situation in which effort estimates are negotiated between to opposing parties should be avoided.

Answer 7

As I read through the already existing answers, I missed one point, or at least it was not in the focus.

There is one reason why developers usually cannot give any real time estimates. This is the complexity of software development itself. You can always step into nasty details which you could not see before you really start developing it.

This problem is quite old, as you can read in the famous book "The mythical man month" of F. Brooks.

As a solution of this problem agile methods like SCRUM were developed. All these methods are using relative estimations, based on the complexity, like story points or t-shirt sizes. Giving relative estimates is not the problem, but the solution!

The only way coming around here is to improve the communication with the customer. For example in SCRUM you can give fast feedback after each sprint.

You can also try to measure the velocity (story points per time). But to my experience, this does not help very much, as the differences between the tasks are too high.