In an ideal Agile world, the Scrum team is always completing all the selected user stories at the end of the sprint. In the real world however, there might be some product backlog items that don’t have a “done” status, but are only partially finished. Should you split them for the next sprint? In this article, Daniel Zacharias gives you four reasons why it is a bad idea to split unfinished product backlog items.
Author: Daniel Zacharias, Hexacta, http://www.hexacta.com/
In the Agile world of Scrum, there are two types of product backlog items (PBIs) at the end of a sprint: those that are done – that comply with the Definition of Done or DoD – and those that are not. If we want to be faithful to the methodology, those unfinished PBIs, regardless of their degree of progress, should be returned to the product backlog. (see also: 5 keys you can’t skip on your agile process).
Once the unfinished PBI is put back into the product backlog, the product owner must prioritize it again and include it (or not) into the next sprint to finish it. When re-assigned back to a sprint, the amount of story points assigned to this PBI should not change, since the effort to implement it, as a whole, remains the same.
However, many of us who work with Scrum have lived through the situation where a sprint has finished and one of its PBIs is incomplete. It’s tempting to split it into two and leave the part that’s been done in the iteration that has already ended so it does not look like we had such a bad Sprint with a low velocity.
But why is doing this a bad idea? Why shouldn’t the Product Backlog Item be divided into two to represent the work that remains pending and the one that has already been done? Here are 4 important reasons:
1. It goes against the Scrum philosophy
Trying to apply a band-aid to the fact that something was not finished and giving the impression that things are better than they really are is a compelling reason to not make this mistake. It goes against the philosophy and nature of Scrum to give visibility and encourage communication (within the team and to the client), both the good and the bad.
2. The commitment is compromised and the quality is jeopardized
When the team perceives that leaving things “halfway done” has no consequences, it jeopardizes the commitment of the team members to the development of the product and its quality. A team that is aware that doing its best to comply with the forecasted deadlines and (self-defined) processes is synonymous with quality, commits their work to excellence.
3. Estimates lose value
Following the line of thought that “if we do not end the PBI now, we’ll finish it on the next sprint” means that we are devalue the estimate. This messes up the velocity (which should only consider finished items for its calculation) and makes it difficult to use it in order to have a medium-term vision.
4. A situation that, in the end, affects the process
If the failure to finish a product backlog item has no consequences, and no changes are made, it ends up naturalizing a situation that puts the results at risk. Not finalizing a PBI in the forecasted time should be treated as a problem to be discussed in the Retrospective meeting in order to find a way to prevent it in future sprints.
Bonus track!
Watch out! Before finishing the sprint, don’t make the mistake of removing tasks from the sprint backlog before the sprint ends. When doing so, you will generate the illusion of having completed all the tasks in the sprint, when in fact you have not. It is important that at the end of the sprint the burndown chart is analyzed and the team understands what mistakes were made and how to correct them.
Some Frequently Asked Questions
Considering that the temptation to divide a PBI is very present when working with Agile methodologies, we want to answer some common concerns in order to avoid easily falling into this error.
How do I forecast the sprint estimated capacity if it includes a partially developed PBI?
The capacity of a sprint when you’re carrying out the planning meeting should be calculated in hours and not in story points. Story points are a measure used for the medium/long term, so this situation should not be a problem for calculating capacity. However, the sprint velocity is probably going to be higher (more value was delivered in less hours) than the average velocity you’ve been having, given that you would have completed a PBI with fewer hours per user story point.
What should I do with the tasks that I did finish? Should I move them to the new sprint Backlog or leave them there?
The tasks, if they are in final state (developed and reviewed), should be left associated to the sprint (sprint backlog) in which they were implemented. Moving them to the next sprint backlog will not reflect what really happened, nor will it bring any benefit; on the contrary, it will give the impression that many more hours were burned during the next sprint than what was actually burned.
And what do I do if I finished half the PBI, and the other half remains? Can I break it into two and deliver the part that’s finished?
The only way to do this is if the portion of the product backlog item that is completed is a vertical feature that complies with the DoD, that is, that it has been developed, reviewed, tested (without bugs), documented, and adds value to the product. This is unlikely to happen, since for instance it is probable that testing won’t start until development is completed. But in case all these conditions are met and you are able to split it, consider that you should have divided the PBI before the Sprint started.
What is the moral of all this? Divide and conquer. Try to split the product backlog items into small, independent units (I.N.V.E.S.T) that can be completed within a sprint. Keep in mind that the larger the PBI is, the greater the risk that it will not be completed by the end of the sprint.
One more thing… Definition of Done
“Definition of Done” or DoD is a set of criteria that allows us to determine when a PBI is done (really done). Who defines it? The team and the product owner. It’s an evolving consensus.
It is essential that everyone on the team and the client understand what it means and have the same concept of that state. These criteria apply to all PBIs, and it is important to not confuse them with the acceptance criteria or conditions of satisfaction (the set of affirmations specific to this PBI that will be true when it is complete).
For instance, a PBI is considered done when the following are met:
✓ Coding is completed and peer-reviewed.
✓ Build passes.
✓ Unit tests are written and all pass.
✓ Deployed to testing environment and all tests pass without bugs.
✓ Documented.
The DoD must be able to be fulfilled within a single sprint. In addition, it can (and should) evolve as the team and the project mature, something that is usually done in retrospective meetings. It is important that it is documented and known by all.
Conclusion
Splitting an unfinished product backlog item just seeks to apply a band-aid to a problem that is being manifested. It is better to accept it, work on it, and improve it for future Sprints.
Scrum and the Agile philosophy in general seeks to be transparent and show everything as it really is, like a big mirror. In order to improve the process, it is necessary to be able to identify and accept the symptoms (Scrum provides different mechanisms for this, like retrospective meeting, burndown charts, etc.), accept the fact that things are going wrong, and assume this as an opportunity to evolve and mature our processes.
About the Author
Daniel Zacharias has been doing custom software development for over 14 years (11 of them at Hexacta, and 10 of them using Scrum). Open minded, he seeks to incorporate the Agile spirit into his work, using empirical methods to improve both the products and the work process of the teams in which he participates. This article was originally published on http://www.hexacta.com/2017/04/04/why-splitting-an-unfinished-product-backlog-item-is-a-bad-idea/ and is reproduced with permission from Hexacta.