Who consumes estimates?

Question

Consider a company that:

• works on an own product(not a contractor),
• the product has already been released(but is expected to need years of further active development),
• the product is a consumer app(not safety critical, not government).

Most place I have worked for can be described so. To my astonishment, most of them allocate a significant portion(1-3) of the weekly 40 hours for estimation tasks. Example practices include planning poker, sprint planning, game plan development.

Thus estimates are a development artifact, just like features, tests and bugfixes. So for them to exist a stakeholder outside the team must need them. Who?

Answer 1

Estimates are a tool that supports planning. Anyone that needs to make decisions and build plans about the future can use estimates as a tool to make predictions and figure stuff out (without knowing for sure, you can only estimate; but having an estimate - any estimate - is sometimes better than not knowing at all).

So for example:

• upper management can use estimates for strategic planning. Say you are a video game company that builds video games and there is this annual gaming conference where everyone in the industry presents their latest. Say also that someone gets a brilliant idea about a new video game. There are 6 months until the conference. Can you build it? The team builds an estimation and they think it will take between 8 to 10 months. Now you can make more realistic plans about what you could deliver in those 6 months, instead of jumping in and start building the game assuming you will make it in time for the conference.
• a product owner might make decisions about what to build. Say there are three ways to build a certain feature. How can the Product Owner chose between them? Well maybe they ask the team about the effort for each and they come up with 30, 120, and 75 story points. Now the Product Owner can take a better informed decision and go with the solution that can be put in front of the users faster (the 30 SP). Without this information maybe they would have chosen the second approach which takes four times the effort.
• as @nvogel pointed out in another answer, the team can use estimates too. They can use planning poker to discuss stories and understand them, and figure out how to do things, and as a byproduct of this exercise also attribute a SP estimate to them. Then they can use the SPs to plan how many stories they can fit inside the sprint, or they can use velocity to later figure out how much they might need to burn through other similar features amounting for some number of SPs. There are some teams that count stories instead of using SPs; the end result is still the same assuming you can split all the stories to about the same size so you can simply count them.
• etc.

Again, estimates are a tool that supports planning and decision making. As long as everyone understands their limitations, and estimates are not misused or abused, then they can be a valuable tool in figuring out if your goals are achievable. If you want some goal reached in "6 months" and the estimate comes back as "at least 9 months" then that's an indication that maybe your goal is to ambitious and you need to figure out some other plan to reach it.

Unfortunately, estimates are misunderstood, misused, and abused and when the estimate comes back as "at least 9 months" and not "6 months", then obviously the estimate is wrong, right? But this is a story for another time.

Answer 2

Since you mention sprint planning I will assume your team are using fixed-length iterations. Estimates are for the team. The team should include the senior stakeholder or the person who is accountable to stakeholders of course (e.g. the Product Owner), but the main purpose of estimation is to allow the team to decide what can go into a given sprint. The estimates therefore are not very important to stakeholders outside the team because the forecast date for each product increment is always the end of the sprint regardless of what the estimate was.

What stakeholders should be most concerned with is the prioritised product backlog and any associated release plan indicating which backlog items will get into which sprint. In Scrum terms, estimates are normally understood to be a component of the product backlog artifact.

7% of time spent on backlog refinement and sprint planning is not exceptional - in my experience it seems a little bit light - but so much depends on the type of work and the size of the team that it's difficult to give a general guideline. The Scrum Guide used to suggest that up to 10% of the team's time was spent on backlog refinement but the latest version of the Guide no longer recommends how much time to spend on refinement.

Answer 3

Just another perspective... In the organization where I am currently employed no one "consumes" the estimates, and everyone knows that. Yet, we are still pointing stories/tasks. The goal of the exercise, for this organization, is not the points, rather it is the discussion to create a shared understanding about the work items, and it is the discovery that items should be broken up further.

For the actual implementation of an item, we don't accept 8, 13, or higher points. If an item ends up with those, we consider them not fully groomed yet. Once we are done grooming (after possibly breaking up some items further), we end up with 1, 2 or 3 points (5 points is exceptional) – it doesn't really matter much to us anymore at that point (since, again, no one "consumes" the estimates, and we know it's understood and broken down). From there, it's actually a running joke with this team that "everything is a 2".

Answer 4

All stakeholders involved should be consuming estimates. Without estimates, there is no way to arrive at planning values. Without planning values, there is no way to make a cogent decision because there is no way to evaluate investments, divestments, progress, benefits, costs, and risks. All of those things require estimating. And every stakeholder has some play in some of those areas, including the lowest ranked doer on the team.

No matter whether is it formal and results in a work product, people engage in estimating all the time, starting with how long it will take to drive to work. So make it formal so you can measure.

Answer 5

Estimations are a means for a goal. The goal, in this sense, is predictability.

Who needs predictability? Pretty much everyone involved in the process, for different reasons.

Example practices include planning poker, sprint planning, game plan development.

In the above statement you're assuming all the above activities (amongst others) have the same importance. That's far from reality. nvogel mentions that a considerable amount of time is suggested to be dedicated on backlog refinement. That's on spot. However, worth to notice that the effort dedicated during backlog refinement on story estimation should be minimal.

Estimating a piece of work, specially in a changing and dynamic context, is a wasteful activity (that's one of the arguments in favour of #noestimates). It's important to observe that there are different "categories" of wastefulness, and worth looking at it, but it's not the focus on this question.

Bottomline: Teams should invest their efforts on minimise time on estimating (planning poker or any other activity around estimates) but still finding the right amount of efforts on estimation so that the team can offer a reliable predictability to its stakeholders.

Answer 6

And, here's a "sly" way of looking at it: when you're tasked with making an estimate, and if you actually try to do it, then it means that you're looking at things like "potential work breakdowns" and "dependencies." Maybe the actual number that you come up with is accurate, and maybe it isn't, but the process by which you tried to come up with a defensible figure is important. In order to successfully accomplish anything at all you must be very-formally "looking ahead" at all times. Otherwise, "the blind is leading the blind," and, "that's no way to build a house ... not even an outhouse."

Perhaps Unimportant: "I think it will take 46 hours."

Very Important: "Why, exactly, do you think so?"

Answer 7

Note that even for an internal product (= only consumed within the company) the development cost is typically not just paid by 'the company', but by various internal stakeholders, that have different requirements, priorities, - and budgets. In other words, whoever asks for a widget, pays for it. To make that even possible, you need to have some idea what the specific widget costs.

Also, to allow a useful prioritization of different wishes, the relative sizes need to be known. Department A might be willing / able to wait three days and let department B's widget get done first, but they might not be willing / able to wait for three months.

Finally, the 'need' for a feature often depends on the duration / cost - if an idea takes a day to implement (and saves a week of manual work), they'll go for it, but if it takes a month to implement, they'd rather put a manual effort of a week in.