The Fallacy of the Rejected Backlog Item

To my understanding, there is a frustrating misunderstanding of reality when one thinks that the product owner can reject a single story at the sprint review. This is the fallacy of the rejected backlog item.

Oh, the product owner can reject the assertion of the development team that they have completed it and have them re-estimate it and stick it back on the backlog. They can decide to postpone deployment until the next sprint. They can even decide to reject the entire sprint and lose all of the work done in that sprint. My point is that it is neither physically nor technically possible to remove a single PBI from a sprint without incurring significant rework.

• Update 2013-08-24 – The Scrum Guide 2013 mentions nothing of rejecting anything at the sprint review. 

This is the reality of product development that gets in the way of the idea of the rejected backlog item. The software that we are producing is complex. If we are creating a sprint goal and selecting backlog items that help us achieve that sprint goal then they are probably interrelated. These interrelated items will likely build on and reference each other’s functionality. If we then decide to rip one of the nodes out of this complex web of classes and methods, then we are increasing risk and we are also unlikely to have working software at the end of the sprint. Oh, I am sure that there are exceptions, but it will take time to remove no matter how good the team's engineering practices.

Just to be clear, this is not about done. I expect every team to produce work that meets whatever definition of done that they have agreed with the product owner. If the development team calls done when they are not, then that is a wholly separate problem …

Missing the Point

Not only that, but you may be missing the whole point of the sprint review. It is not about acceptance or rejection of the increment by the product owner but instead it is about discovery and understanding between the product owner and the development team. It is one of the key inspect and adapt points for the product backlog. The product owner, being human, perhaps had a picture of what they wanted in their head that does not match what the development team has produced. In this case, they need to work with the product owner to update the backlog with the changes that are now needed to make it what the product owner envisaged. So it meets “done”, it meets the acceptance criteria and it is still not what the product owner wanted. Is this the development team's fault? Of course not … it is a learning point, and inspection and adaption of understanding between the product owner and the development team. The product owner learned how the development team interpret their stories and the development team learned something about the product owner's intent. This is intensely valuable learning for the Scrum team as a whole.

There are only three actions open to the product owner at the sprint review:

1. Update the product backlog to reflect what we now need to do to achieve the vision
2. Choose to ship the current increment or not
3. Choose to end the project or continue

Note: Although Ken suggests that the existing PBI that was not completed should be re-estimated and put back on the backlog this is not optimal for reporting. I recommend zeroing out the points (the team gets no points for incomplete items) and adding new PBIs to the backlog to reflect the undone work.

Making It Easier

All of that being said, it is the job of the development team to make things as flexible for the product owner as possible. They should implement what capabilities that they need into each increment to make it possible for them to turn a new feature or layer to an existing feature off an still ship. This will not only make the product owner happy, it will get the newly built features in front of the stakeholders as quickly as possible for feedback.

There are a few things that can make this as easy as possible:

• Communication – Good communication between the product owner and the development team can help alleviate these sorts of issues. However continued interfering in the development team by the product owner will make it harder to deliver what was estimated. The development team should deliver their understanding of what the product owner presented to them at the sprint planning meeting while collaborating where timely and appropriate.
• INVEST– Making sure that your PBIs are all following the INVEST (independent, negotiable, valuable, estimable, sized appropriately, testable) model. If you follow this guide, then you can minimize any misunderstandings between the product owner and the development team.
• Feature Flippers – The single most valuable thing in your developer's arsenal is the ability to turn the things that you are adding on and off at will. This should be applied both to a feature and the multiple layers of that feature that are added with each pass delivering PBIs. You may think of each PBIs as requiring a switch to be able to turn it on or off. It is usually not perfect, as there are some things that are iterations of the same feature. More advanced implementations may allow you to enable or disable features by account or user.

If you can do all of these things as they will all add value by making it easier to give the product owner flexibility.

Conclusion

Although the product owner can’t reject a single item of work they can reject the assertion of the development team that they have met “done”. If the development team is not “done” at the end of the sprint then this is technical debt that is going to interfere with your product owner's schedule for the next sprint and make them grumpy. If it is “done” but is still not quite what the product owner envisaged, then the product owner and the development team can then work together to update the product backlog to reflect what now needs to be done to implement the product vision. This is empirical inspection and adaption at its best and is one of the key values derived by the process.