Though the Scrum teams are committed, sometimes it is really difficult to complete all the items selected into the Sprint Backlog by the end of a sprint. A team may have selected ten product backlog items (usually user stories), but they were able to finish seven or eight of them. The other items are often almost done, but because they are not meeting the definition of done 100%, they are not considered as done.
Now the below questions comes here:
– What about the estimates on those incomplete/partially done product backlog items?
– Should they be re-estimated?
– Should the team get partial credit for the work they did complete?
This article aims to answer the above questions with details.
When a team completes some part of a story, team members often expect and demand to get partial credit towards their velocity. For example, a team that claims to be half done with a 6 Story Point product backlog item may expect to get half of that, which is 3 Story points towards their velocity.
This in general is not a good idea. A team should get the credit only for the work that is 100% done. In this example, nothing meets the team’s definition of done by the end of the Sprint. The work is only done 50%. Taking credit for partially done work would be like serving a half-cooked biryani to the guests. It might taste good for now, but you will get stomach upset later J.
When a team claims credit for incomplete work, they usually overestimate the done portion. It is really difficult to estimate how much is “Actually done”. So a team that says they have completed 50% of an item, may actually do less than that. Clearly identifying the percentage of done work is usually hard and most of the times, teams overestimate how much is “actually done”
Because of the incorrect guess of “actually done” and the partial credit due that, the velocity will be inflated. An inflated velocity may seem to be good at the current moment, just like the half-cooked biryani and can tell its stakeholders a bigger velocity value. But that inflated velocity will not sound good if anyone ever uses that artificially high velocity to forecast the remaining work or for a new project.
Teams should take the stance of “No Partial Credit”
So, it is advised that the teams take a stance of no partial credit for partially done items . Irrespective of how close team members are to completing a product backlog item, they earn zero story points for that item, until the entire item is meeting the definition of done. This is very similar to getting a run in cricket only when both batsmen complete their running between wickets and reach the other side of the crease, just because they finish running 50% of the distance, they cannot claim half run.
Advantages of the No-Partial-Credit Stance
- The team members will try to decompose the items into smaller ones in the future so that they can complete 100% of those items due to their size. Even in this case if a small item is not 100% done, the team doesn’t really care if they do not get credit for that item.
- When the teams are not allowed to claim partial credit, they try harder to complete the items they pull into a sprint so that they will get the credit. So this improves the team’s commitment towards fully completing the selected items.
When a product backlog item is partially done by the end of the Sprint, the team usually wants to try to re-estimate that item, because some portion of that item is already done in the current Sprint. This is unrelated to the issue of claiming partial credit that is explained above. Sometimes, the size of the product backlog item may have increased so that the estimate of the remaining work may increase and it may be higher than the original estimate given for that item initially. For example, a team may consider that they have completed 3 Story points worth of progress for a 5 Story point item, but they also have observed that there is 5 more Story points worth of work still remaining. When re-estimating the partially completed work, it may be possible for the new estimate to go beyond the original estimate.
Possible reasons for re-estimating the partially done items:
There are two opinions that support the re-estimating:
- It will be more accurate since some portion of the work is completed
- It will be required to plan the next sprint in case this partially completed item is going to the next Sprint backlog
It is difficult to debate on the first point, so we may accept that point. However, the second point is where things get tricky. Team members may argue that they cannot decide how much work to pull into the next sprint when some of the backlog items have estimates out of which some work was partially completed.
For instance, imaging a team has capacity for 3 more Story points in a sprint. A 5 story point item will not fit as it will be bigger than the capacity available. But what if they think roughly half of the 5 story point item was completed in the earlier sprint? So in that case that item can easily fit into the next Sprint. So in this case should that 5 story point item be re-estimated at 2 or 3 story points to show that it will fit into the next Sprint?
It is recommended that “No, it is not required and it should not”. That means: leave the original estimate as it was and bring that item into the next sprint backlog if the team is confident that it fits into the next Sprint.
The resizing of the backlog item will come into picture when the team is doing the Sprint planning based on historical average velocity. In that approach a team will pull the items whose estimates sum to the team’s average velocity of the most recent few Sprints. For example, if a team has a historical average velocity of 40 Story points, they will pull 40 Story points worth of items into the current Sprint. If they have already pulled 35 Story points worth of items and the next item is partially completed in the previous Sprint, and if that item is estimated at 8 Story points, that item cannot fit into the current Sprint.
So instead of just relying on velocity based Sprint planning, it is recommended to go with capacity based Sprint planning. In capacity based Sprint planning, the team will select the items one by one and check if that item can fit into the sprint. If they can, they will pull it and select the next item until the sprint capacity is full.
Capacity-driven sprint planning uses velocity as a parameter but is not completely driven by that. A team doing capacity based sprint planning will take into consideration the finished portion of that 5 story point item when they decide whether that item will fit in their sprint or not. When a 5 Story point item that was partially done in previously done is pulled into the next Sprint, the next Sprint velocity will be jumped up, however when you consider the average velocity of 2 sprints will be more or less same, so there will be no issue. So consider the average velocity instead of individual Sprint velocity for planning purposes.
Usually, re-estimating partially finished product backlog items is unnecessary work and it is a waste of time. However, there is one scenario, in which it is recommended. When a team puts back a product backlog item that is partially done in the current Sprint, and when they realize that item may not be able to complete in the next one or two Sprints (this means the item is really big in size), they should consider re-estimation. In that case, it is advised to split that item, give the team some credit for the work done (if product accepts that partially done item), and return the item to the backlog with a revised estimate of the work remaining. The team may break that item into separate smaller product backlog items also in this case.
In all other cases, the Scrum teams will do good if they do not take partial credit and not bother about re-estimating, especially if the team is planning the Sprints using capacity based approach.
Recommendations to minimize partially done work:
– Splitting the Product Backlog Items into smaller so that they can be done faster
– Swarming on the items so that the item can be completed faster
– Clearly defined acceptance criteria so that the developers will have fair idea
– Clear and transparent Definition of Done
– Effective Daily Scrums
– Frequent product backlog refinement
– Using engineering practices like pair programming
– Identify and manage the dependencies clearly
Learnovative has trainers who are industry practitioners and they have real time experience in implementing Scrum in various products from different domains. They bring their experience into the training that makes our training more effective and closer to the real time scenarios.
If you want to know more about such practical scenarios, how the Sprint planning happens, the best practices and real time examples, join Learnovative’s Certified Scrum Master and Certified Scrum Product Owner training.
Though Scrum teams are committed, completing all items in the Sprint Backlog by the end of a sprint can be difficult. If some work is incomplete, questions arise about estimating partially done items. It’s recommended that teams avoid taking partial credit to prevent inflated velocity and to maintain accuracy. Instead, credit should only be given when work is 100% complete. This approach encourages teams to break down tasks into smaller, manageable pieces. To learn more about effective Scrum practices, join Learnovative’s CSM Scrum Master Online Training Institute in Hyderabad, Scrum Product Owner Online Training in Hyderabad, or ICP ACC Agile Course Online in Hyderabad.
