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

Why not make people happy by coaching them the benefits of relative sizing? Also, if team setup is consistent, client should be able to derive an estimate of cost and/or time after your first sprint. If they need it, let them get it themselves and don't bother the team with it. These are requests which let you paint yourself in the corner if you are not careful

Why not make people happy by coaching them the benefits of relative sizing? Also, if team setup is consistent, client should be able to derive an estimate of cost and/or time after your first sprint. If they need it, let them get it themselves and don't bother the team with it. These are requests which let you paint yourself in the corner if you are not careful





Client don't want to be educated in relative sizing, that's the thing Xander.

IMHO That is no matter of the client wants or not education. It is not changing tires in the car, most of the time software development is more complex than that and can't be exactly calculated in time consumption needed. You should not be afraid of estimating in the finite time, as long as you educate the client about what is the estimation (and why it can not be absolute, regardless of used units), what kind of risks there is, the likelihood of being close to the truth, etc. Explain to him how do you plan to work closely with him day by day to address problems, mitigate the risk and deliver him not set of features, but a usable valuable product in the budget that he has available.



If you simply throw into him estimates (abstract or not), and leave it like that, then he will "normalize" it on their own into understandable for most people finite time units.

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

What does the Product Owner think about this matter of "approval"? Doesn't he or she agree a Sprint Goal on behalf of these stakeholders, and trust the team to forecast and organize their work so the Goal is met?

What does the Product Owner think about this matter of "approval"? Doesn't he or she agree a Sprint Goal on behalf of these stakeholders, and trust the team to forecast and organize their work so the Goal is met?



This is the team that works mostly in Kanban-way since this is the support team, with less new implementations of features and more migrations to production fixes and production standalone fixes. Therefore, Sprint Goal becomes obsolete most of the time. Because of that, we shifted (planning to) all the way to Kanban way of doing things. 



 

If you simply throw into him estimates (abstract or not), and leave it like that, then he will "normalize" it on their own into understandable for most people finite time units.



I agree, of course. In time, I hope that we will be able to communicate to client why when we do relative estimations this is more valuable than the absolute ones. And that we are tracking and collecting data to make estimations more valuable to them and to the team. 

As you mentioned that you using Kanban, then what is the point of estimating single tasks? Where are your Kanban metrics, Leading and Lagging Indicators, SLE(s), the definition of workflow, policies, etc.?  If you maintain them well, that should be enough to make decisions if the task is "ok" to put into the flow or not.



Or maybe you say "Kanban" but to be honest, it is rather simple to-do list without metrics, without WIP Limits etc.?

@Piotr,



No, we are trying to follow the Kanban guidelines, by using all you mentioned above. However, at the moment, the client wants to know how much effort will be LOGGED for particular work. That's why we need to estimate single tasks. 

So if you have some metrics, you can tell the client that this type of work is usually done for example in min time X, max time Y, and the SLE for that type is i.e 85% in Z days (or less), however, there always remains a risk that actual time will be greater (or lower). That may depend on what are you measure, but if you have this measured, then you can share the same metrics with the distinction to "worked" time, and "queued" time.



But in the end, he will know with 100% confidence how much is logged when the task is done, every estimate (or calculation) given before that happens may be wrong, so, at least in my opinion, it is better to eventually agree on a max timebox that he is willing to pay for in what that issue may be resolved, and if not he will get a lot better and more accurate estimation to decide if he wants to drop it, or keep working to reach the done state.



If not, then still remains a question, will he pay for the time spent on analysis / refining to give him estimate that he will not be happy with? What if that estimate happens to be too big and therefore he decides not to proceed, but in reality, it may be the opposite and maybe the team could do that item faster, which if we know that upfront, may result in different clients' decisions.

@Piotr



If not, then still remains a question, will he pay for the time spent on analysis / refining to give him estimate that he will not be happy with? What if that estimate happens to be too big and therefore he decides not to proceed, but in reality, it may be the opposite and maybe the team could do that item faster, which if we know that upfront, may result in different clients' decisions.



I can't agree more with this. :) Yes, this is real-case-situation all the way but that's the risk and opportunity for the client to change this approach. 



 you can tell the client that this type of work is usually done for example in min time X, max time Y, and the SLE for that type is i.e 85% in Z days (or less), however, there always remains a risk that actual time will be greater (or lower). 



That's the idea. To track our data, to check different types of work and to extract min/max time and that to communicate with the client.