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 and the misguided belief that this backlog item can just be left out of this delivery. That backlog item that was chosen by the Development Team at the Sprint Planning event to help them achieve the Sprint Goal. The Sprint Goal that created focus and has the entire Development Team working in the same area of the codebase.
The fallacy is that without this single Backlog Item, one of many, the code will still function as intended.
TL;DR;
Since the Development Team is held accountable for quality, but not quantity, and they sure cant be held accountable for meeting expectation.
- DONE – If in the pursuit of the Sprint Goal the output of the Sprint is a DONE Increment of working software then the Development Team did everything they were required to do. Any gap between what was delivered and expectation is merely a learning opportunity. At the Sprint Review, the Scrum Team investigates this gap and updates the Product Backlog to reflect what is now needed next.
-
NOT DONE – If the Development Team is not “Done” at the end of the Sprint then there are some consequences:
- An increase in Technical Debt that is going to make future work slower
- Removing the option for the Product Owner to release the product if they so choose.
- With undone work, you have to fix it next Sprint and thus interfere with the next SPrint Goal and the Product Owners delivery expectations.
- Remove any chance of predictability for future sprints until the undone work is under control.
But if its DONE. There is no rejection of the Backlog Item there is only feedback. There is just a learning opportunity that can be used to reduce the expectations gap for future Sprints. Reflect on that during the Sprint Review, engage with Stakeholders to better understand both their intent and their expectations.
Empirical process control is not about doing everything correctly, it’s about transparency, inspecting, and adapting.
The fallacy of the rejected backlog item
Oh, the Product Owner can deny the assertion of the Development Team that they have completed it and had them re-estimate it and stick it back on the backlog. They can decide to postpone deployment until the next Sprint. They can even choose 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.
A Sprint Review is held at the end of the Sprint to inspect the Increment and adapt the Product Backlog if needed. During the Sprint Review, the Scrum Team and stakeholders collaborate about what was done in the Sprint. Based on that and any changes to the Product Backlog during the Sprint, attendees collaborate on the next things that could be done to optimize value.
–Scrum Guide – Sprint Review
The Scrum Guide 2017 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 inter-related. These inter-related 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… because Professional Scrum Teams build software that works.
Rejecting a Backlog Item is 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, the Development Team, and Stakeholders. It is one of the keys inspect and adapts 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, the Development Team need to work with the Product Owner to update the backlog with the changes that now need to make it that which 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 Teams fault? Of course not… it is a learning point, and inspect and adaption of understanding between the Product Owner and the Development Team. The Product Owner learned how the Development Team interprets their words and the Development Team learned something about the Product Owners 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:
- Update the Product Backlog to reflect what we now need to do to achieve the vision
- Choose to ship the current increment or not
- Choose to end the project or continue
Making it easier with feature flags or toggles
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 off and 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 PBI’s are all following the INVEST [Independent | Negotiable | Valuable | Estimable | Sized appropriately | Testable] model. If you follow this guide, then you can minimise any misunderstanding between the Product Owner and the Development Team.
- Feature Flippers/toggles/flags – 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 to each pass delivering PBI’s. You may think of each PBI’s 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.
The post The fallacy of the rejected backlog item appeared first on Martin Hinshelwood - naked Agility Ltd.
Oldest comments (2)
Feature Flippers/toggles/flags are not a panacea and they quickly become rotten and dangerous. Plus its really tricky to implement right and not have ugly if statements all over the place.
Agreed, a professional Scrum Team will hide only the work they are doing now behind a flag. Once that feature is "released" I would expect work to be done to refactor and remove that flag.
Leaving all the flags in a Product would be a disaster of the first order.