The fallacy of the rejected backlog item

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 can’t be held accountable for meeting forecast. It was, after all, a forecast. There are only two states that the product increment can be in at the end of the sprint:

  • 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 (Transparency of the Future) 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.

If it is DONE, then 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 first time, it’s about transparency, inspecting, and adapting.

The fallacy of the rejected backlog item

At the end of the Sprint, the Product Owner can deny that the Development Team met DONE. This would mean that the Development Team failed their accountability to meet the minimum quality bar as set down and agreed in the Definition of Done.

At the end of the Sprint, the Product Owner can deny that the work represents a significant enough return on investment to warrant shipping it to production. This likely means that either the Goal was not useful, or that the Development Team did not understand the Backlog Item enough. This would mean that the Product Owner failed in their accountability to maximise value delivery.

At the end of the Sprint, based on either of these two outcomes, the Product Owner can choose to reject the entire Sprint and loose all of the work for that Sprint.

My point is that it is neither physically nor technically possible to remove a single Backlog Item 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 and only works together in its entirety, the whole increment. The Sprint Goal provides the Scrum Team with purpose and focus, and selecting items that go towards this Goal means that many of the selected backlog items, the forecast, are related. This related set of ideas created an interconnected network of interdependent code that realises on the existence of each other. If we then decide to rip one of those interconnected items 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 as the Scum Team. 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

If you are considering rejecting backlog items last the Sprint Review then it is likely that you are missing the point of the Review in the first place. 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’s about inspecting the last 2 weeks and making sure that we still have transparency of the future reflected in the Product Backlog. Did the market, our competitors, our business, or our ideas just change based on the latest Increment of the product?

Since the only constant is change, it is absolutely possible that the Scrum Team created something that meets Done, meets the Acceptance Criteria, and still does not meet the needs of the business. Is this the Development Teams fault? Of course not… it is a learning point, and inspect and adaption of understanding between the Scrum Team and the Stakeholders. This is intensely valuable learning for the Scrum Team as a whole.

There are only three actions open to the Scrum Team 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

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 they need, into each increment, to make it possible for them to turn a new feature off and still deploy. This will not only make the Scrum team 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 were 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, give the Scrum Team as much feedback as possible.

Hi, my name is Martin Hinshelwood and I and the owner at naked Agility with Martin Hinshelwood. I’m a Professional Scrum Trainer with Scrum.org, Microsoft MVP and I have been delivering software for 20 years and working with organizational change for over 10 years.

Please feel free to ask any questions in the comments and I will hopefully have time to answer them. Failing that, you can ask me at anything on Linkedin and you can find many videos of mine on naked Agility TV.

Upcoming Training Opportunities

These are the next five classes we have, and you can check out our full public schedule of classes.

Timezone:
Immersive Professional Scrum Product Owner with Russell Miller over 8 weeks starting 11th October 2023
Virtual Immersive
11 Oct-13 Oct, 2023
09:00-13:00 EDT
8 weekly half-days
Immersive Applying Professional Scrum with Simon Bourk over 10 weeks from18th October 2023
Virtual Immersive
18 Oct-20 Oct, 2023
09:00-13:00 EDT
10 weekly half-days
Immersive Professional Agile Leadership Essentials with Joanna Płaskonka Ph.D. over 7 weeks from 20th October 2023
Virtual Immersive
20 Oct-1 Oct, 2023
09:00-13:00 BST
7 weekly half-days
Live Virtual Product Backlog Management Skills with Joanna on 2nd November 2023
Virtual Traditional
2 Nov, 2023
09:00-17:00 GMT
1 full-days

We can deliver any of our courses as private in-house training over Microsoft Teams & Mural. We also recommend training based on your accountabilities or role, you can go directly to recommended courses for Scrum MastersProduct OwnersDevelopers and Agile Leaders.

Create a conversation around this article

Share on Facebook
Share on Twitter
Share on Linkdin

Related Courses

No items found

Read more

Martin Hinshelwood NKDAgility.com
Software Development is not just a systematic process but a dynamic interplay of critical work that shapes the progress of your product. A Scrum team’s work can be classified into Sprint work and Refinement. To steer your Scrum Team towards success, it’s essential to understand, manage, and balance these two …
Martin Hinshelwood NKDAgility.com
🚀 Navigating the intricacies of the Sprint Goal in Scrum? 🎯 Discover the essence of crafting a goal that drives real value! 📈 Dive deep into the tactical steps, avoid common pitfalls, and ensure your team is on the right track. 🛤️ Let’s demystify the Sprint Goal together! 🤝 #Scrum …
Daryn Basson NKDAgility.com
https://youtu.be/rPxverzgPz0 Would you recommend the APS course to a newbie scrum team, and Why? Why the APS Course is a Must for Newbie Scrum Teams In this article, I’d like to share some thoughts on the Agile Practitioner Series (APS) course and its relevance to newbie Scrum teams. But first, …
Martin Hinshelwood NKDAgility.com
🚀 Navigating the nuances between the Definition of Done and Acceptance Criteria? 🤔 Dive into our latest article that explores the sanctity of a working, usable product without compromising value. 💡 Let’s ensure quality and value go hand in hand! 🤝

OUR TEAM

We believe that every company deserves high quality software delivered on a regular cadence that meets its customers needs. Our goal is to help you reduce your cycle time, improve your time to market, and minimise any organisational friction in achieving your goals.

naked Agility Limited is a professional company that offers training, coaching, mentoring, and facilitation to help people and teams evolve, integrate, and continuously improve.

We recognise the positive impact that a happy AND motivated workforce, that has purpose, has on client experience. We help change mindsets towards a people-first culture where everyone encourages others to learn and grow. The resulting divergent thinking leads to many different ideas and opportunities for the success of the organisation.