What is the best time (Product backlog refinement or Sprint planning) to estimates our work item?

Let’s step back for a moment. What do you believe to be the purpose of estimation?

I do not see where in the Scrum Guide it says that estimation has to occur at any specific time, event or activity.  All the references to estimates are in relation to it being used as a piece of information to define a Product Backlog Item and a tool for the Development Team to manage their time. Also keep in mind that an estimate is an educated guess and not an absolute. They make up a data point to illustrate understanding of Product Backlog Items.  So I encourage that an estimate be applied at the point in which it provides the most value as determined by the Development Team since the Scrum Guide states that 

The Development Team is responsible for all estimates. The Product Owner may influence the Development Team by helping it understand and select trade-offs, but the people who will perform the work make the final estimate.

You really need to be able to answer @Ian Mitchell's question before you can understand how to answer your own.  And by answering it here, you may be able to get some better advice from others as it will add context from which we can offer opinions. 

What do you believe to be the purpose of estimation?

@Ian Mitchell I think Estimation is the key concept to plan the work for a particular time or sprint. Estimation is the time duration (Best optimal time that we think a particular work item needs to meet the DOD) which we give before executing the work.

By estimating a development can identify - 

• How many work items can they pull in the sprint backlog?
• How much bandwidth the team has for some unexpected work.

And I think the best time to estimate the work item is the sprint planning because during sprint planning we have a clear picture of a particular work item.

If we estimate a work item in PB refinement or other time then it will not be the best estimate as the work item may have some dependency on some other task. Because of this, the estimate may vary at the time of sprint planning.

Suppose that the purpose of estimation is to help a Development Team get its arms around how much work it can take on.

Might ongoing refinement be a good way to estimate, so the chances of the team being surprised during Sprint Planning are reduced?

Hi Ian Mitchell,

I wish you and everyone here a very happy new year 2020!

My question is very specific about estimation during the PB Refinement meeting.

Might ongoing refinement be a good way to estimate, so the chances of the team being surprised during Sprint Planning are reduced?

As per me - Being a member of the development team for the last 6 years I think we always discuss work items during PB Refinement to change its priority and order.

Also, Discussing a work item and estimating that work items are two separate tasks. During the estimate, one has to think from multiple perspectives. Hence estimation is time taking process. And since the team has already discussed each work item during PB Refinement there should not be any surprise during sprint planning.

Why are we using "Might" or "Chance". We must make this framework optimal from every angle. We must be very clear that estimating the same work item twice (PB Refinement & Sprint planning) is just the repetition or I would say a waste of time. I can say this with my experience that We always have to estimate the work item in sprint planning.

Can we simply agree on - 

During PB refinement meeting the team must discuss about product backlog and estimation should be done during sprint planning.

Kindly guide me on this :)

Why are we using "Might" or "Chance". We must make this framework optimal from every angle. We must be very clear that estimating the same work item twice (PB Refinement & Sprint planning) is just the repetition or I would say a waste of time. I can say this with my experience that We always have to estimate the work item in sprint planning.

In your experience, is there no need to handle uncertainty and emergence?

Of course, there are uncertainty and emergencies and we must handle them. To handle this type of situation we already keep approx 10% of bandwidth.

But the question is not about handling uncertainty, it is about duplication of time (because of estimate in PB refinement and sprint planning meeting.)

Also, If we assume that there will always be uncertainty and emergency in every sprint then this is not an emergency.

My advice is to rethink emergence, how it differs from emergency, and how critical it is to refinement, estimation, and other activities in Scrum.

Gonna jump in here...

So if you've already gone through backlog items in Refinement, you've got them to a state that they can be completed in a single sprint; why not estimate then? Sure there are times where you estimate something in refinement and have to estimate again in Sprint Planning; but that shouldn't happen as often as you're making it seem. My teams have estimated in backlog refinement and when that item is pulled into a sprint, we simply verify if the estimate is still valid. If there is any new information then we re-estimate, if not we simply say "is a 5 still good for this?" "Yes/No" etc. 

I'm not saying that estimating in Sprint Planning is a bad idea by any means. I will say that in Refinement, the story is fresh in the team's minds because they had just been working through it to break it down. Waiting for Sprint Planning can cause further delay because they'd have to refresh their minds on the story. 

Ultimately, it doesn't matter when you estimate, that is up for the team to decide. What does matter is WHY you estimate. If you've got backlog items in a small state that can be completed in a sprint; what difference does it make whether it has 5 or 21 story points? I'm not against estimating or calculating velocity but it can so easily be weaponized and/or used incorrectly so rather than being a helpful tool for the teams, it is a yard stick used to measure performance. 

Can we simply agree on - 

During PB refinement meeting the team must discuss about product backlog and estimation should be done during sprint planning.

I choose to agree and disagree because the real answer depends on what works best for the team that is undertaking this activity.  For your current team, that statement might be correct.  But for the next team you work it could be a disaster. 

As @Ian Mitchell points out, there is a big difference between emergence and emergency.  As @Curtis Slough points out it isn't about when you do the estimates but why you do them. Estimates are only guesses based on what you know at the time you make the estimate. And any estimate has a point at which it becomes invalid.  If you ask a carpenter for an estimate to build you a shed, they will usually give you one with a disclaimer of "this estimate is valid for the next 30 days". Why?  Because in that time period, the price of materials could change, their availability could change or something unforeseen could change.  @Curtis Slough points out a practice that many of the teams I have worked with use of asking "is this still valid" at the time of planning to include an item into a Sprint.  It usually takes about 30 seconds but it has on occasion lead to a larger discussion because new information has come to light.

You mention that you are a developer.  I have worked with teams as a developer, QA, Product Manager and Scrum Master.  No team has done things the exact same way but all of them have used the practice of estimation in some form.   @Ian Mitchell is alluding, at least in my interpretation of his comments, "when" is not important. "Why" is the most important aspect.  Don't focus on the "when" so much instead focus on the "why" and ensure that the "how" works best for the people involved.  

We must be very clear that estimating the same work item twice (PB Refinement & Sprint planning) is just the repetition or I would say a waste of time. 

To echo much of the feedback already provided in this thread, I would question your assertion that multiple estimations for the same item is a waste of time.   Surely, an estimate made at one time (i.e. - PB refinement) may no longer be accurate at a future point (i.e. - Sprint Planning) due to unforeseen conditions or events, or learnings made by the Development Team since the original estimate?   Why then would you want to not adjust such estimates based on the new information?

In practice, I advise my teams to estimate items as frequently as possible, provided that it aids them in planning future sprints.   And as Dan mentioned previously, estimates are simply best guesses based on he information on hand, even when they are finalized in Sprint Planning.

I love this discussion. And I think I got my answer.

But just for knowledge, Daniel Wilhite Can you please give me any live situation example for this statement? 

But for the next team you work it could be a disaster. 

What kind of problems can we face because of this style of work?

A big thank you to everyone for sharing your excellent thoughts. 

Every estimate is wrong, except when it accidentally turns out to be correct. Any attempt at precise estimation is as likely to succeed as gambling on red or black based at roulette. If you analyse trends on when and how often the result was red or black, you may think you can predict better when it will be red or black. But in reality it is still a gamble.

That being said, I see two different purposes of having an idea of how much something will cost.

1. Prioritizing the product backlog. The PO is the value maximiser and makes choices which features to add (if any) first. To be able to do that, the PO needs to have an idea how much value a feature may roughly offer and how much it will roughly cost. This type of rough estimation is done during the backlog refinement, quite possibly on epic level. Think along the lines of "small", "very large", "average" or something like that.

A feature that has the highest marketing potential of the product backlog but that will cost months to develop may not necessarily be the best investment right now.

2. Forecasting a sprint. The development team needs to be able to provide some kind of forecast of the current sprint and what can or can't be done to meet the sprint goal. This type of estimation is typically done at or shortly before the sprint planning.

This type of estimation should continue during the sprint. Not in hours and minutes, but more along the lines of "this is a lot bigger or smaller than I thought, we may not meet the sprint goal". This is done while inspecting and adapting the current sprint backlog, which takes place at (but is not limited to) the daily scrum. 

Every estimate is wrong, except when it accidentally turns out to be correct. Any attempt at precise estimation is as likely to succeed as gambling on red or black based at roulette. If you analyse trends on when and how often the result was red or black, you may think you can predict better when it will be red or black. But in reality it is still a gamble.

First, an estimate by definition is a guess. There is no such thing as a "precise estimate", that is a major oxymoron. Secondly, comparing estimation in Scrum to Roulette is not the strongest analogy because in Scrum the estimates are done based off empirical data; roulette is completely a game of chance. A better analogy would be a basketball player estimating the PPG (points per game), 3 Pt Shots, Rebounds, etc. This is because as the player continues to practice and improve, he/she can look back at the previous game statistics and estimate the number of points, rebounds, etc that they'd earn in a game. Say a player has averaged 28 points per game, 5 rebounds, and made 80% of free throws over the last 5 games played. It's VERY reasonable to estimate that in the next game, this player would score 28 points, 5 rebounds, and make 80% of free throws based on the empirical data.  Will it always be accurate? No, it's an estimate and best guess. Roulette is entirely out of a player's control, trends don't mean anything and cannot be used for estimating because the Roulette player has absolutely no control over what is happening. Scrum teams have control over what happens, they are writing the code, they are building the increment just like a basketball player is making the plays and shots in basketball.

@Nitish Kumar, you asked for an example. 

Consider the situation where a team is not doing enough refinement.  They discuss a Product Backlog Item (PBI) once for 20 minutes.  The next time it is addressed is 2 weeks later when the team decides to pull it into a Sprint and an estimate is given. In my past experience, that PBI is not well understood and since it has been some period of time since it was discussed whatever common understanding that had been accomplished is probably lost at the time of Sprint Planning.  Teams that do this typically have difficulty satisfying items in their Sprint Backlog and soon start to experience a sense of failure. So how would multiple estimations of the same PBI help? 

Typically teams will hesitate to pull PBIs that are above a certain estimate into a Sprint.  So if the team decides to estimate a PBI during refinement and it is above the acceptable limit, they will know that more attention is needed.  That PBI could be broken into smaller chunks.  It could be determined that additional investigation is needed, possibly even a spike to experiment with options. This method helps the team to become more in line with what is considered "enough refinement" or "ready for a Sprint". It also helps the team align on how they estimate. But if you wait until Sprint Planning to do your one and only estimation you are potentially introducing unnecessary risk. 

But consider the opposite where a team is very diligent with refinement.  They have a common understanding of what is considered ready to be pulled into a Sprint and will discuss PBIs until that "ready" state has been reached.  Would it be bad for them to do their estimates during Sprint Planning?  Probably not but the same could be said for doing the estimates when they all agree that it has reached that level of "ready" during refinement.

Quite often teams start out as the first example and over time will move to the second example. As a Scrum Master it is my job to help them on that journey by coaching them on how to improve their estimation.  This is just one situatonal example.  There are so many other ways, reasons, techniques and each uniquely qualified. The skill comes in helping to identify the problem you are hoping to solve and then guide the team in experimenting until you find the right soluton for that team.

Hope this helps. 

Thanks Daniel Wilhite for this great example. Things are clear to me now.

Also, Today I cleared PSM I in the first attempt 🙂 . 

I love this forum!