Should we stop using terms like “re-estimating” or “re-sizing”?

I don't quite follow why the terms "resizing" or "reestimating" are getting in the way. The "re" prefix means "back" or "again". The use of a term "resize" or "reestimate" means that the team has finished the process or activity of sizing or estimating once and is doing it a second (or third or fourth or...) time.

For most teams, I would expect that the activity of resizing or reestimating is the same process as the initial sizing or estimation. From an activity-naming perspective, it's all sizing or estimating. However, when talking among the team, it could be useful to make a distinction between work that has already been discussed and sized/estimated at least once and work that is being sized/estimated for the first time. However, I don't see a difference between work that is being resized/reestimated because it was not completed within a Sprint or work that is being resized/reestimated because the team thinks they have more information that will change the size/estimate.

Personally, I think the real conversation should be about if sizing or estimation makes sense in the complicated and complex domains where Scrum is best suited. I do not think that it is. Working to make the work smaller or thinner is a good activity, but not making the work so small that it doesn't represent a valuable product change. However, trying to describe that size is likely to be a wasteful process.

I'd suggest that regardless of whether you call it re-estimation or resizing, the Product Backlog must tell the truth at all times about the amount of work we currently believe to remain for the Product over its life. Our understanding of that remaining amount is emergent, and we should expect it to be continually revised and updated.

Thanks for your thoughts on this @Thomas. I want to dig into this a bit...

I don't quite follow why the terms "resizing" or "reestimating" are getting in the way. The "re" prefix means "back" or "again". The use of a term "resize" or "reestimate" means that the team has finished the process or activity of sizing or estimating once and is doing it a second (or third or fourth or...) time.

You mentioned that the team has "finished" the process or activity of sizing. Have they? Why would we be empirical in everything else, yet view sizing as "finished" at this point? If the work is not finished and returns to the Product Backlog, it seems that sizing may also not be finished.  Do we say re-refining because we refined a PBI and continued to refine it at another time or even during Sprint Planning?

"Back" or "again" implies there was some form of lock in or importance with our initial guess/estimate. It also suggests that sizing "again" means it could be wasteful this time vs. the first time it was done. If a team finds value in sizing, why wouldn't we continue to find value when discussing unfinished work? I wonder if it is our addition of "re" to size that contributes to this change in view for sizing.

@Ian. Completely agree with the Product Backlog telling the truth at all times. I am a proponent of sizing unfinished work for this reason as it provides the most transparency.

I have found a number of instances where Scrum Masters or teams disagree with this stance or are not open to even considering it. I have been trying to think of reasons why this may be a challenge, and one thought was the language we use when it comes to sizing unfinished work. People seem to be at odds with having to re-do something. To me the desired outcome of a PBI may not change with unfinished work, but so much else could have. Progress may have been made, learning gained, challenges could better understood etc. It is important to discuss those changes and there is a good chance that size would be impacted. 

If we don't think the language has any impact on this, what else could we explore?

As usual, I have a different viewpoint.  I have said many times that an estimate of size is only useful until you start working on the item. At that point it becomes irrelevant because you will constantly be learning new things. From the Scrum Guide:

 Product Backlog refinement is the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Attributes often vary with the domain of work.

A Sprint Backlog is just a subset of Product Backlog Items that have been chosen to focus on for a Sprint.  All the items in the Sprint Backlog remain in the Product Backlog.  When the Sprint timebox ends, the Sprint Backlog dissolves but the items that have not met the Definition of Done are still in the Product Backlog. (To be complete, so do all of the items that have reached "done" but that is for another conversation.)  As work is undertaken, there is a constant process of refinement as new information is obtained.  If the work needed to bring an item to meet the Definition of Done is not achieved by the end of the Sprint, the new "size" should be readily apparent and should be captured in some way.  That information would also come into play in the discussions on why it was not completed and whether to continue the work in the next Sprint or delay until a later date. 

I use the word "sizing" sparingly when I talk to my teams.  I use "estimate" more often as a way to remind them that they are constantly refining the work they are doing. 

So many great answers here. IMHO @Ryan, based on my experiences, when teams avoid re-sizing/re-estimating, that is rooted in some form of accountant/reporting required in their context. There is opposition to it when there is a perceived risk of "losing" points in such reports (i.e velocity track) by such re-doing. If the conversation within such context shifts from observing how "efficient" we are, to how we can be more effective with our forecasting, then maybe opposition to re-sizing will vanish 🤔

Usually, in such contexts, I see similar conversations during Sprint Planning:

• "Didn't we plan too much? There is a list of PBI for 100 points, while our velocity is around 30"
• "Nah, most of that stuff is almost done, it is not truly 100 points."

I use such situations to make it transparent that in fact, we re-estimate things, but it is hidden, not transparent, and here is a list of possible impacts on our effectiveness and ability to create value. Most of the time, so far, my teammates accepted the idea that if we estimate / size things, and find value in that, then we also should re-visit those estimates of not done stuff after the whole sprint of effort.

You mentioned that the team has "finished" the process or activity of sizing. Have they? Why would we be empirical in everything else, yet view sizing as "finished" at this point? If the work is not finished and returns to the Product Backlog, it seems that sizing may also not be finished.  Do we say re-refining because we refined a PBI and continued to refine it at another time or even during Sprint Planning?

I suppose it depends on how you define the activity. To me, the activity of estimation or sizing ends when the work has an estimate or size. But just because the activity has ended or is finished doesn't mean that you can't repeat the activity on the same unit of work again, perhaps because you've learned more or because so much time has elapsed since you completed the activity.

"Back" or "again" implies there was some form of lock in or importance with our initial guess/estimate. It also suggests that sizing "again" means it could be wasteful this time vs. the first time it was done. If a team finds value in sizing, why wouldn't we continue to find value when discussing unfinished work? I wonder if it is our addition of "re" to size that contributes to this change in view for sizing.

I don't think "back" or "again" implies a lock in. I do think there's an importance to say "this unit of work went through the process of estimation and we came up with a value". It may or may not be wasteful to do the process again. Personally, I think that estimation is always wasteful, but not all people or organizations agree with that. I think it would be wasteful to go through the process again immediately after completing it, but if you estimated something two weeks ago, it may not be wasteful to go through the process again based on things that you've learned in those two weeks. It's up to the team to make sure that if they are spending time doing a task that the task is adding value.