Re-Estimating Story Points | Unfinished Story Points

Welcome to PremierAgile!

Recognized for 'Outstanding Leadership in Education and Learning' by the Education 2.0 Conference Dubai 2024

We are proudly recognized for Excellence in Agile Consulting and Transformation Services – 2023 by Economic Times and Times of India!

*Avail a Flat 10% Discount Across all our certification courses use coupon code AGILE10

*Avail Zero Interest EMI

We Offer World-class guidance to transform yourself as well as your organizations

Mega Offer! Access our Advanced courses for  just 21,999/- +Taxes

PremierAgile

With an objective to enable continuous learning and progression for our learners, PremierAgile curated several learning articles in the areas of Agile, Scrum, Product Ownership, Scaling, Agile Leadership, Tools & Frameworks, latest market trends, new innovations etc...

Re-estimating Unfinished/Incomplete Story Points

Re-estimating Unfinished/Incomplete Story Points

Teams always strive to complete all User Stories in a Sprint. How well-intentioned they may be and how hard they try, there would be situations when some User Stories will be left unfinished or in process. It is bothersome when you reach the end of a Sprint and find that there are still one or two User Stories to be completed. This is not an ideal situation. The team had forecast and committed to finishing a certain number of Story Points during Sprint Planning, and they have not done so. The reasons for Story Points remaining unfinished may be multifold. It could be an unintended error or an unforeseen event, like a team member having to leave midway because of sickness or some other reason. This affects the balance of the team, or the team may have forgotten some vital part of work, or some additional work came up during the Sprint, which was not anticipated. Whatever the reason, this will have a cascading effect as the team's velocity would be impacted, further affecting future planning. Moreover, unfinished Story Points are treated as work not started. At this juncture, a few questions arise. They are:

  • What should be done in such situations?
  • Incomplete Story Points may not be counted, but can they be re-estimated?
  • If yes, should the incomplete Story Points be re-estimated?
  • And lastly, should a team get partial credit for partially completed work?

Let's delve into these questions.

What should be done in such situations? We start with should a team get partial credit for partially completed work. Teams are often provided some credit for a partially completed User Story. Maybe half credit for half work done and likewise. But the point is, should it be so? It is not precisely correct and is not a good idea. The team should earn its credit on completed work only. Only credit should be given when the work meets the Definition of Done. If the teams are given credit for the work not completed, they may be happy for a short time, but eventually, they will rue it. If the team gets partial credit, it tends to overestimate its completed work. It is unable to see the full scope of the Product Backlog item. And this prompts the team to increase the velocity because the members feel they are ahead of where they are. So, it is always advisable that teams get no credit for the partially completed work, nor should teams ask for it. If this stand is taken, it has a two-fold benefit. The first is that if the teams do not get partial credit, they will be more aware and take smaller backlog items to work on in the future. And the second is that the team members will always try more vigorously to complete the items in the Sprint, so there will be fewer unfinished items at the end of the Sprint. And that would be great news for the Scrum Master. But that question will remain. What to do with those unfinished User Stories? Should they be re-estimated? Let's examine it.

Is re-estimating unfinished/incomplete Story Points a good idea?

Once the question of granting no credit for partially completed work has been settled, the teams may want to re-estimate the unfinished work and ask Scrum Master for it. The team would like to know if the work left unfinished at the end of a Sprint can be re-estimated. The team members have their reasons. For them, at least some work has been done. Although they may not ask for partial credit, they may feel justified in requesting a re-estimation of the remaining work in the backlog item as its estimate may have changed. Since most of the work has already been done, the team members will have a more precise idea of the estimate of the remaining work in that backlog item. So, this justifies re-estimating Story Points that are incomplete. But care has to be taken to ensure that when the incomplete Story Point is being re-estimated, and the team takes it to the next Sprint, it should fit into that Sprint. So, an unfinished item should be added to the next Sprint only if it fits nicely into that Sprint. If a Sprint has space for five points, how will an eight-point story fit into it? 

Once a decision has been taken to re-estimate the incomplete Story Points, the next thing is how the unfinished Story Points will be re-estimated. We describe some methods usually used to re-estimate the incomplete user points.

Re-estimating Story Points

Re-estimating only the remaining work - Only that part of the work is re-estimated and left unfinished. Suppose the effort required to deliver a Product Backlog item is 8 points and has not been completed in a Sprint, then the team checks how much work is remaining to deliver the desired value and finds it is 4 or 5 points. So, the team only re-evaluates the incomplete portion to fit the remaining work into another Product Backlog item. Knowing how much work is remaining and how much effort is needed makes it easier for the Scrum Team doing the Sprint Planning to fit the remaining effort into a Product Backlog item that requires less effort and delivers maximum value.

Re-estimating to accommodate both the work done and unfinished work

We can also re-estimate the complete backlog item, including the completed and the incomplete work. The Product Owner has to do some work here. If only 5 points are remaining, they may not consider it and instead look at the total points when trying to compare the value being delivered by this item to other items in the Product Backlog. Or they may think that since only 5 points are remaining, it would be better to get some value out of it. The team velocity may keep changing, but the unfinished Story Points are carried over to the next Sprint if the Product Manager feels that this Product Backlog item and hence some value should be delivered.

Breaking the item into two parts - and separately re-estimating the unfinished work

Here, only part of the work is considered Done, which is releasable. The unreleasable part is considered incomplete. So, the lowest part is identified and completed, and a new Product Backlog is created. Once the Sprint ends, the remaining part can be taken up for re-estimation. This is done so that the remaining part may be converted into a value-delivering item.

Re-estimating Story Points are not so uncommon. The thing to be kept in mind is that you take the right approach and stick to it. When you take up unfinished user points in your Sprint, you must ask yourself why. Sometimes, in taking up unfinished stories in the Sprint, teams take less work than their capacity, and then they find they have unused capacity. In that case, they must ask the Scrum Master what more work can be done. They must consider the potential value of the incomplete Story Points before re-estimating them and including them in the next Sprint.

References
  1. https://turboscrum.com/inaccurately-forecast-Sprint/
  2. https://www.advanceagility.com/post/re-estimation-and-unfinished-work
  3. https://sjoerdly.com/the-art-of-re-estimating-undone-work-in-scrum/

Author

Paula

Is a passionate learner and blogger on Agile, Scrum and Scaling areas. She has been following and practicing these areas for several years and now converting those experiences into useful articles for your continuous learning.