Don’t claim partial credit for your unfinished PBI’s when the Sprint ends
Imagine you own a house. You’ve asked a painter to redo your living room. It’s a simple job, four walls to paint, the ceiling doesn’t have to be done.
“Fine", he says. “It will take me one day and the price is €100.”
“Alright", you say. “I will pay you in full when the whole job is finished as agreed.
Fast forward one day, and the painter is three quarters finished. And mind you, he’s not done three of the four walls. He’s done the first three quarters of your four walls.
The painter comes up to you and says “alright, one day has passed. I’ve done three quarters of your walls, so please pay me €75 now and then I’ll finish the rest.”
What do you say?
Of course you tell the painter to stop being ridiculous. Three quarters done means the job isn’t finished. The agreement was payment in full when the whole job is finished, so he’ll get his full €100 when all walls are fully painted.
This seems logical, though what the painter does is what Scrum Teams do when they split a PBI into Done and Remaining work at the end of a sprint.
They claim some of the effort and split out the rest to another PBI.
When I’ve seen this, velocity seems to be the main driver. The team argues “but we’ve done work in Sprint x. If we don’t split the PBI it will look like we did nothing". Splitting PBI’s for this reason is a bad idea for two reasons:
- You reduce transparency about your velocity. If you do 20 points in all even sprints, but 40 in the odd ones, that’s a clear sign that something needs attention. Splitting PBI’s to claim partial effort evens out this effect, making it look like there’s a steady velocity when it’s actually not.
- If you use velocity for release planning, you use the average velocity anyway. It doesn’t matter if you do 20 in x and 40 in y, your long-term average is 30.
But there is a more important reason. This anti-pattern goes against a key element of Scrum, The Definition of Done.
The Definition of Done is a formal description of the state of the Increment when it meets the quality measures required for the product.
The moment a Product Backlog item meets the Definition of Done, an Increment is born.
The Definition of Done creates transparency by providing everyone a shared understanding of what work was completed as part of the Increment. 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. — Scrum Guide
The Definition of Done (DoD) contains an agreement on when a team calls the PBI Done. It often contains things like acceptance criteria fulfilled, unit test coverage %, integration test green, peer reviewed, necessary documentation in place, released to production etc.
When a Scrum team decides to split a PBI at the end of a Sprint, a lot of things in the DoD will not be checked. The now-called-Done PBI is probably not satisfying any acceptance criteria, it’s not up to quality standards, there’s no documentation, there’s no code released.
Hence, like the painter saying he’s three-quarters Done with your walls: it’s not fully Done. And not fully Done = not Done.
Stacking anti-patterns
Ok, the team accepts that it can only count fully finished PBI’s for their velocity. But they can’t seem to finish their PBI’s in one sprint.
So what do they do? They pull out another anti-pattern, and start splitting their user stories into analysis, develop, test, release.
Again, not a good idea. Aside from the fact that this way of splitting also doesn’t satisfy the DoD, the goal of Scrum is to learn fast.
There’s not much to learn from something that’s only analyzed or developed. There’s no valuable addition to the existing software, and the developed work only exists in a fantasy environment (i.e. everything that’s not production).
What to do?
So how to improve this?
First of all, get your DoD in order. Having a good DoD will make it clear that the other patterns can no longer take place. It enforces that you slice work in a way that is releasable, has good quality, and brings value to a customer.
Splitting work out at the end of the Sprint doesn’t satisfy the DoD, the same goes for splitting work into analysis, dev, test and release.
If you have unfinished PBI’s on your Sprint Backlog at the end of the Sprint, which will always happen, you move the whole thing. And you continue working on it until the functionality intended has been delivered.
If you’re struggling to finish PBI’s in one sprint. Experiment with different splitting patterns to make the work smaller. Use for example the flowchart by Humanizing Work.
Inspect why you’re having trouble releasing. Common causes might be a heavyweight release process, or lots of manual testing work. Invest in automating these processes and making them more lightweight.
Or, if there’s really no other option, increase your Sprint length until it makes sense to make it shorter again. But realize that what you might want to do is make the Sprint length shorter in order to enforce different behaviour.
Closing words
This article outlines why you shouldn’t claim partial credit for work at the end of a Sprint. The downsides are simply too big. I’ve also tried to offer suitable alternative strategies to try when work is left unfinished at the end of a Sprint.
In any case, don’t be that painter.
