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

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?

• Read Joel on Evidence Based Scheduling. Feb 27, 2020 at 23:39
• Does the client want an estimate for the effort of the work (how many man-days of uninterrupted work under ideal conditions) or the throughput (effectively: on what date can I expect it, taking other priorities into account)? Feb 28, 2020 at 11:25
• the effort of the work (man-days) Feb 28, 2020 at 11:38
• Also recommended: leanpub.com/whenwillitbedone Apr 4, 2020 at 14:32

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

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.

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.

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.

• Good advice therefore voted up. OP apparently has a mental block preventing them from giving an estimate in days. Mar 4, 2020 at 12:41
• The problem is, it remains an estimate, not a promise. Estimates can be way off. It sounds like there is a culture in which that may (have) lead to repercussions. Apr 4, 2020 at 14:31

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?

• ''then you give a number where you are 90% sure at least you can give the results in this time'' I can give them by checking with the team the relative estimation range and maybe after some time, cycle time. I can't give the 90% percent of accuracy since we are building software, not tires. Feb 27, 2020 at 20:11
• ''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..." if you can be kind enough to read what I wrote in the question above, you would see this ---> 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?----< Regarding tires...I will let you know in a month or so ;) Feb 28, 2020 at 10:56
• Your client doesn’t understand “cycle time”. They have a number (£10,000) what the feature is worth, they need a number for the cost to see if they want the feature for that cost or not. They want a number, not an accurate number, and definitely no excuses or “cycle time” whatever that is. If we had this as a real discussion I would be thinking about replacing you by now. Feb 28, 2020 at 14:45
• And I will give the client the number from cycle time. If we had this as a real discussion, I would be thinking if you understand how the software works. Mar 4, 2020 at 13:43

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.

• You can negotiate effort estimates if you negotiate deliverables at the same. “We want x,y, and z”. “That takes eight weeks”. “We have only budget for four weeks”. “”In four weeks we can do x, and a small part of either y or z”. Mar 4, 2020 at 12:47
• But you are not negotiating a given estimate you are using estimates as input to negotiate the scope. Thanks for the hint. I may try to.make this more clear. Mar 4, 2020 at 14:23

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.

• The client needs an absolute cost to decide whether to do a project or not. If the team lead is unable to offer an estimate, then they can’t decide and the project is dropped. Then the next project is dropped, then OP is dropped. They’d like an accurate number which is hard to give, but they need a number. Mar 4, 2020 at 12:44
• Yes, I know this requirement. But experience shows that giving exact costs is not possible. At the end the customer gets estimations with large buffers. Mar 5, 2020 at 13:17