Martin Hinshelwood

Guest Post: The fallacy of the rejected backlog item

About the Author: 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.

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.

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.

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 exception, but it will take time to remove no matter how good the teams 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 need 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 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 interpret their Stories 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

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 PBI’s 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 PBI’s are all follow 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 – The single most valuable thing in your developers 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 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 iteration 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 Owners 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.

, , , , , , ,

11 Responses to Guest Post: The fallacy of the rejected backlog item

  1. David V Corbin October 22, 2013 at 1:42 pm #

    dmichel76 I have to agree completely with Martin. Consider the following (presume feature switches are NOT implemented)
    1) The team believes all PBI’s to be done.
    2) The code has all been commited to the repository
    To reject a single PBI means that there must ALREADY be a revision in source control that meets all of the other PBI’s but completely excludes the one where rejection is desired. ANY other condition means additional work, and a state that is NOT done.
    Now this may be possible with the last PBI worked on, but is almost certainly not possible with any other PBI.
    Therefore the PO accepts and ships the results of the Sprint or does NOT [tried to make this into a Yoda’ism, but failed miserably]

  2. MrHinsh August 20, 2013 at 6:11 am #

    a0flj0 MrHinsh frede And the PO is welcome to cancel the Sprint if he feels that market need is worth it. Your Sprint length should match your organisations effective planning horizon while not being more than 30 days. Under Scrum the PO is not allowed to interfere with, and commits to uphold, the Sprint boundary. The negative for cancelling the Sprint and starting a new Sprint Planning immediately to change direction is the thing that demonstrated the cost of change to the PO. So he can indeed change what the team is working on at any time as long as he is willing to cancel the Sprint…

  3. a0flj0 August 20, 2013 at 12:27 am #

    MrHinshfredeIt helps to keep sprints short. The chance of the PO changing his mind about stories included in the current sprint decreases if the sprint is short. Longer sprints may feel more comfortable for devs, but shortening the sprint might help if the PO frequently changes his mind mid-spring.
    Also, you should be aware that the  PO doesn’t change his mind mid-sprint on his own. Most often, the PO doesn’t actually own the product, he’s just the dev team’s interface to the informal set of stakeholders that drive product development, from sales and marketing to end users. The PO most often tries to not interfere with current stories, but that’s often not possible – especially with longer sprints.

  4. frede August 6, 2013 at 1:47 pm #

    Good post. To me the scenario you describe indicates iterative waterfall like.
    1. Plan items during the sprint planning.
    2. Team work alone on items during sprint
    3. PO accept/rejects item during sprint review
    I don’t agree with “…continued interfering in the Development Team by the Product Owner will make it harder to deliver what was estimated”. I don’t see how PO and dev team working closely together equals interfering. Is it better to build what was expected even if that is the wrong thing, because the dev. team miunderstood some things? It does not matter how fast you go if you are going in the wrong direction. This creates quicker feedback loops. Otherwise you risk wasting a sprint by building the wrong thing. Items should not be approved/rejected at the sprint review but the dev. team and PO must work together during the sprint as much as needed. There should be no surprises for the PO at the sprint review, like “oh, is this what you built? that’s not what I want”.

    • MrHinsh August 7, 2013 at 6:49 pm #

      frede I am not suggesting not even implying above that the Development Team when confronted by uncertaintly should just blindly deliver something. Of course they should seek clarity from the PO. It is however not licence, as I see in team after team, for the PO to interrupt the team and change the PBI’s at any time. The Development Team should be respected and trusted to deliver what was asked and if the PO wants to change things around mid sprint they are welcome to either update the backlog for future sprints or cancel the current sprint and loose all progress. 
      The Sprint is the container for planning not the Story. The PO needs to learn, as part of the inspection and adaption cycle at the end of the sprint, how to express themselves so that the Development Team do understand them and do produce the right thing. 
      There is a big difference between a continuous flow model (like Kanban) and the batched flow model (like Scrum) and it sounds from your comment that you are in the continuous flow model. That’s fine when things are only complicated but when things get complex and are in danger of chaos one needs to put a box (Sprint) around that chaos to gain focus and bring it down to merely complex. Yes there is risk in the Sprint, but if things have gotten chaotic you need that box or you are risking everything and may deliver nothing….

      • frede August 9, 2013 at 1:32 am #

        I don’t see uncertainty about exactly what to build as the same thing as the PO changing his mind mid-sprint. Once the sprint backlog is set, the dev. team owns it and it cannot be changed by the PO at will. I agree that the dev. team must know what to build and how to build it. This is part of refinement/sprint planning and e.g. acceptance criterias for stories will help greatly in achieving this.

        • MrHinsh August 9, 2013 at 8:19 am #

          frede exactly what I was getting at :)

  5. dmichel76 August 2, 2013 at 12:45 am #

    Love this kind of discussion! :-)
    I agree with you there – vertical slicing and good development practices in general will help with keeping things decoupled, but only help. Like I said, it will “reduce the problem”, but not solve it entirely.
    You said “If we made the change in A and that is the one that is rejected then B will cease to function properly and we will need to do work to repair it. We no longer then have a done increment with no further work required.”
    While I agree with the dependency and the need for rework, I disagree with the fact that we do not have a done increment. The team followed the DoD and the software (hopefully) was running. The fact that the PO rejects one (or more) item is only in light of *future* work to be done in the next sprint. That current sprint is over… forget it! the fact that is wasn’t exactly what the PO intended does not compromise it in anyway (its purpose of getting feedback etc. was still successful) – this is not failure but learning for both the team and the PO.
    Again, I agree with you here – what the PO wanted and what the team understood and implemented may not match – I see that all the time too of course. Yes, this will hopefully improve over time. But for me, this constitutes only 1 level of feedback loop that the inspect&adapt model can bring to the table (the team is learning about what exactly it is the PO wants). But there is a 2nd loop of learning here that is often forgotten about: learning what the *right* product should be, not from the team’s point of view, but from the PO’s point of view. His vision may not be correct up front, and so we need something that allows this vision to adapt.
    From the team’s point of view, it’s someone else’s job (the ‘PO’ in Scrum, the ‘XP customer’ in XP to find out this vision, what the right product is… the team then cares about building this product right.
    This is what Chris Argyris describes as “double loop learning”, a concept taken on board by people like Dan North, Gojko Adzic, and Gabrielle Benefield to describe how we also need to care about what the *right* product is rather than only focusing on how to build it *right*, and thus avoid having so-called hyper-productive teams that deliver the wrong product.
    The 1st loop does not need the ability to reject a PBI, the 2nd loop does though.

  6. MrHinsh August 1, 2013 at 6:54 pm #

    I really appreciate your comments and I wanted to reply with a counter for
    each of your points:
    #1 – Vertical Slicing
    While true vertical slicing is possible on the first pass what happens when you
    are iterating over a feature sprint on sprint to slowly bring the features into
    focus. If we deliver two changes in a single sprint on a feature then we may
    have needed to make alterations that each other are dependent on. If we made
    the change in A and that is the one that is rejected then B will cease to
    function properly and we will need to do work to repair it. We no longer then have
    a done increment with no further work required.
    Good engineering practices and vertical slicing can help mitigate things and
    give your Product Owner more flexibility but while this adds value it is not
    required for an agile delivery of software. One only requires the ability to
    ‘reject’ the entire increment not an individual PBI.
    #2 – Correct PBI
    I would say that I am describing a situation where the opposite is true. I
    assume and accept that the result of the Development Teams efforts will
    rarely match the picture in the PO’s head (the Development Team of course can’t
    see that picture) and that the PO will need to inspect the increment and adapt
    the backlog each and every Sprint to get what they want. 
    Yes the Development Team and the Product Owner will get better at working
    together over time. Indeed the Development Team will increase the DoD as
    they discover opportunities to improve. This however does not require the
    ability to ‘reject’ a PBI.

  7. dmichel76 August 1, 2013 at 2:57 pm #

    First off, a well written and easy to read post!
    I disagree with you on 2 points though – I’ll try to explain my points below:
    1) You wrote “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.”
    What about vertical slicing? Working in thing vertical slices will reduce this problem greatly, making it easier to reduce bits of functionality if need be.
    Now don’t get me wrong, this is hard to achieve… and  takes a great deal of care and attention given to the way the PB is sliced in the first place. A lot of people see the PB as a simple ordered list of “stuff to do”, but this leads to horizontal slicing approaches and the problem you describe.
    2) The rejection of a PB item even though it met the team’s definition of done is not just a matter of misinterpretation or miscommunication between the team and the PO as you describe it in the 2nd section of this article. If it was only about this, then one should expect it to improve it over time, where well oiled team would never see this happening. I would argue the opposite – and in my experience, teams new to Scrum don’t reject PB items often at all.. they just go through the process and usually don’t use the power of inspection to its full potential… Very good teams on the other hand, I found, are much “harsher” on themselves and will reject things more easily.
    Not being able to reject any PB items (even when Done) would assume that the PB is “correct” up front, that we know what product to build at the start. In most cases, it is not clear what to build… and a great advantage of Scrum is that the PO is allowed to change his mind, adapting to the evolving definition of what it is we need to build to achieve the business goal.
    My 2 cents


  1. The fallacy of the rejected backlog item - August 21, 2013

    […] Originally posted as a guest post on Scrumology (source) […]

%d bloggers like this: