Skip to main content

Due to the Russian invasion of Ukraine, we have paused all purchases and training in and from Russia.

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

Last post 10:45 am October 27, 2022 by Thomas Owens
7 replies
10:27 am October 25, 2022

There continues to be a lot of debate on what to do with PBIs that are not finished at the end of the Sprint. Should we re-estimate / re-size or leave our initial estimate / size.

I propose that we are not actually re-sizing or re-estimating and that this language and perspective may be getting in our way.

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.

When we are refining Product Backlog Items, we add details such as size. There are times when that size changes based on further defining Product Backlog Items into smaller precise items, or when we learn new information, or due to the evolution of the product. This seems to be an accepted thing. Generally we seem to be ok with changing size prior to pulling a PBI into Sprint.

Why does this all change when we pull PBIs into a Sprint? Why is this the point in which we lock onto our estimation of size?

If a Product Backlog item does not meet the Definition of Done, it cannot be released or even presented at the Sprint Review. Instead, it returns to the Product Backlog for future consideration.

Un-finished PBIs go back into the Product Backlog for future consideration. They are Product Backlog Items, just like other Product Backlog Items. Future consideration means that they may or may not be pulled into the next Sprint. To make that decision we need to inspect. To inspect, we need transparency. Transparency comes from refining, or at least discussing those PBIs to share learnings, to consider what else has changed in the product, to discuss what challenges we encountered that prevented us from completing the PBI in the first place. Why would we remove sizing from this activity?

Instead of saying "re-estimating" or "re-sizing" we could simply say sizing and not treat it any different than other refinement activities.

What do you think?


11:23 am October 25, 2022

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.


11:24 am October 25, 2022

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.


12:21 pm October 25, 2022

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.


12:29 pm October 25, 2022

@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?


02:45 pm October 25, 2022

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. 


03:47 pm October 26, 2022

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.


10:45 am October 27, 2022

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.


By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your Scrum.org member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. Scrum.org does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use

Scrum.org may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Scrum.org Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by Scrum.org may have their access revoked at any time, without warning. Scrum.org may, but is not obliged to, monitor submissions.