What happens to the UNDONE work in a Sprint?

Even a well-set team with clear objectives may fail to finish everything when the sprint ends.

When the sprint is planned, the team might have thought about successfully tackling 6 Product Backlog Items (PBIs). But in reality, they might only address 4 or 5 PBIs. The rest of the items remain undone.

How shall we address the issue of UNDONE items?

DEFINITION OF DONE

To discuss what should be done with UNDONE PBIs, let us focus on the Definition of Done, as stated by SCRUM.

The Definition of DONE expresses the situation when an ‘Increment’ matches the quality parameters of the product.

An ‘Increment’ comes into existence when a PBI matches the Definition of Done.

The definition, in this case, creates transparency for the team. Each team member has a shared understanding of the completed work, a segment of the ‘Increment’.

When a PBI does not comply with the definition, it is a mistake to release it. It can’t be even presented during the Sprint Review. Instead, it is regarded as a future consideration.

But the question remains — how to estimate the unfinished PBIs? Is it possible to re-estimate them, and is it valid? Shall the team calculate the velocity for the tasks they have already completed? Let us dig deeper, starting with the concept of Partial Credit.

Should a team calculate the velocity for the Partially DONE work — YES or NO?

It should be clear initially — there is practically nothing as partially done.

When a team completes a segment of a PBI, the members receive partial credit or points, accounting for the velocity.

For example, if the team finishes half of the five-point PBI, the count is approximately 3, accounting for their velocity.

As far as I see it, the idea is not good. The velocity should be calculated only in cases of completed PBIs, which comply with the Definition of Done. It fulfils two objectives:

1. The velocity for the team becomes more relevant (not just a cosmetic parameter).
2. There is no cutting of corners. The UNDONE work again enters the PBIs and is re-estimated.

A prevalent question from the Management that a team has to address is reporting on the percentage of work yet to be done.

It isn’t easy to calculate the exact percentage. But, in most cases, there is an overestimation.

It happens because teams generally have a wrong notion that they are ahead of schedule. As a result, they over-estimate while calculating the velocity. One reason is the false expectation from the Management. I addressed this myth Velocity is Productivity.

An inflated value of velocity is good only momentarily. It provides a false pride of achievement. But, it is not useful practically. It sends wrong signals about dealing with PBIs shortly.

Re-Estimation of the Unfinished Work

When there exists an undone PBI after iteration, the standard query of the team is whether it is right to re-estimate it. It is independent of any objective to get partial points.

The team members usually reason that a part of the work has been completed, and it might impact the estimation of the work left to be done.

Keep in mind that the overall size of the PBIs might increase. So, the estimation of the items remaining to be completed could rise, obviously higher than the estimate at the initial stage.

Thus, my recommendation is to shift focus from “velocity-driven” to “value-driven” planning.

But again, shall a team consider re-estimation?

Should the UNDONE work be re-estimated?

There are distinctly three valid reasons that support the re-estimation idea:

1. First, after completing the work, the team members can estimate better.
2. It is a priority to plan and design the next sprint.
3. Finally, it is essential to know when the work will be completed or DONE.

It is difficult to argue with pointer one above. So, I will accept it. My main focus is on the remaining two pointers.

The second pointer is about planning and executing the next sprint.

Team members will generally be confused about the amount of work they should bring into a planned sprint when the PBIs have outdated estimation parameters due to incompletion.

They could say they would need more work to complete due to the backlog. Also, they could sound that they would resume from the beginning, complying with the current sprint goal.

Now, let us revert to the original query — should it be re-estimated?

My short answer is — YES. There are two reasons I want to put forward.

1. There might be a change in the complexity of the Product Backlog Item (PBI).
2. We generally don’t know whether the same team member will work on the Product Backlog Item.

Conclusive thoughts

It is the responsibility of every SCRUM Master to focus on helping a team define their definition of DONE, especially in cases when the team has not defined it.

The Definition of DONE undoubtedly creates more transparency. In addition, it provides shared understanding to each team member regarding the work segment completed as a component of Increment.

When a PBI doesn’t comply with the Definition of Done, the team should not release it or present it at the Sprint Review. Instead, the PBI returns to the set of backlogs to be considered shortly.

About Author

Venkatesh Rajamani has several years of experience delivering working software in short, feedback-driven cycles. He has helped many organizations adopt agile software delivery practices, including large banking, payments, telecom, and product organizations. He started his career as a Software Engineer and spent several years as a hard-core Programmer. He has worked for or with large software delivery organizations, including HP, IBM, Logica, Paypal, Ericsson, RBS and HID. He founded tryScrum.com in 2018 to execute his mission of Humanizing Organizations. Venkatesh is fluent in 4 languages. He is based in Chennai, India and sets the overall direction for tryScrum. He is the world’s first person to hold PKT, CAL-Educator, PST, CEC & CTC together. He loves reading books, travelling and public speaking.