Agile Zone is brought to you in partnership with:

Martin has worked with many customers in government, finance, manufacturing, health and technology to help them improve their processes and deliver more. He provides management and technical consulting that intends to expose processes and practices to gain transparency, uncover impediments to value delivery and reduce cycle-time as part of an organisations path to agility. Martin is a Professional Scrum Trainer as well as a Visual Studio ALM MVP and Visual Studio ALM Ranger. He writes regularly on, and speaks often on Scrum, good practices and Visual Studio ALM. You can get in touch with Martin through naked ALM. Martin is a DZone MVB and is not an employee of DZone and has posted 64 posts at DZone. You can read more from them at their website. View Full User Profile

The Fallacy of the Rejected Backlog Item

  • submit to reddit

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.


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.

Published at DZone with permission of Martin Hinshelwood, author and DZone MVB. (source)

(Note: Opinions expressed in this article and its replies are the opinions of their respective authors and not those of DZone, Inc.)


Ian Mitchell replied on Wed, 2013/08/28 - 7:51am

Hi  Martin

It's been said that in a truly agile way of working, each backlog item will be subject to continuous deployment into production. Systemic improvements can then be delivered (released) to the customer on demand. Lean Startup and DevOps broadly follow this model.

The "fallacy of the rejected backlog item" can therefore be seen as an anti-pattern, in that it is symptomatic of a misunderstanding about this responsibility. The fallacy supposes that the Product Owner is served by developers who offer tasty morsels every so often on a silver platter, and which are his to accept or reject. 

In fact, the PO should be exerting pull by evaluating work on an ongoing basis...not making decisions about the rejection of work, and thereby whether or not to incur waste. The responsible decision is whether or not the system is in an appropriate state for release into live.

Martin Hinshelwood replied on Wed, 2013/08/28 - 10:41am in response to: Ian Mitchell

Ian - Thanks for your awesome response and I totally agree with you.

The fallacy is a response to the reality of poorly trained PO's and the common occurrence of organisations that fail to understand the fundamentals of agility.

This article is not aimed at those who are already agile, but those who have PO's or organisations that demand the ability to reject a single item. To be frank, as with most of my posts, it is a direct responce to curcomstances encountered :)

They thus have not understood the reality... they are living the anti-pattern...



Comment viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.