Implementing feedback from the Sprint Review

Let’s put the matter of when, or even if, any new work is performed for the moment. How important do you think it is for the Product Owner to evaluate stakeholder feedback? If there is valuable new work that ought to be undertaken, shouldn’t he or she account for it on the Product Backlog irrespective of when it might be actioned?

How important do you think it is for the Product Owner to evaluate stakeholder feedback? If there is valuable new work that ought to be undertaken, shouldn’t he or she account for it on the Product Backlog irrespective of when it might be actioned?

@Ian Mitchell, In my opinion, it is important for the PO to evaluate stakeholder feedback. The work has to be accounted for in the Product Backlog, else it may affect transparency. However, if the item is accounted for in the Product Backlog, can it be immediately actioned or is the timebox of the Sprint considered expired as per the above scenario?

Hi Steve,

However, if the item is accounted for in the Product Backlog, can it be immediately actioned or is the timebox of the Sprint considered expired as per the above scenario?

In my opinion in the situation you described nothing is stopping the team from working on this right away. If sprint backlog is empty, the team in my opinion may work at new PBIs. However, this is a good practice to keep the time between Sprint Review and Sprint Planning short. The other question is to which sprint this work is counted. Actually this should not matter that much if the delay is short. I tend to think that whatever you complete before next Sprint Planning should still be counted to the previous sprint, but if someone is doing the opposite and it works for him, fine.

if the item is accounted for in the Product Backlog, can it be immediately actioned

Yes. The Product Owner could ask the Development Team to commence the work in whatever time remains, assuming team commitments including the Sprint Goal have already been met. They are under no obligation to action that work, nor should they be expected to complete it before the end of the Sprint unless they commit to doing so.

Bear in mind that sufficient time needs to be spent refining Product Backlog items so they are in a “ready” state.

I'm curious about in this situation is the timing of the Sprint Review, Sprint Retrospective, and Sprint Planning. The situation you describe of having any time to implement work between the Sprint Review and the next Sprint Planning is hard for me to understand based on how teams I've worked with typically schedule these events.

My concern is pretty much what Ian Mitchell brought up. I'm unconvinced that a stakeholder could raise feedback in the Sprint Review, the Product Owner can review it for consistency with the vision for the product, it can be clearly expressed, the Development Team can refine it and ask questions and ensure that there is sufficient detail to design and implement it, the Product Owner can order it in the Product Backlog, and assuming that it's at the top, the Development Team can complete the work to the Definition of Done without a feeling of being rushed before the Sprint Retrospective and the next Sprint Planning. That's really a lot of work in such a little time. In a scaled environment or a product or service used by multiple different stakeholders with differing needs, there are also other considerations that I didn't mention which would increase the complexity of taking feedback and getting it ready to work on by a Development Team.

At the end of the day, I'd fall back to two principles from the Manifesto for Agile Software Development: enhancing agility with continuous attention to technical excellence and good design and sustainable development at a constant pace. The situation that you describe seems to be trying to cram extra, unplanned work into a Sprint timebox. I'd be concerned with the ability to get the work done to a sufficient level of quality while maintaining a pace of work that is sustainable over long periods.

What are your thoughts? Any difference of opinion?

As per me , if there are any important feedback then should have brought in much earlier than Sprint review. I think you should think on the lines of integrating stakeholders more during the Sprint. PO should be getting regular feedback on the product and optimize the product backlog regularly. Review is the final stage for the product where the product is Re-Viewed and not demonstrated. 

I agree with everything everyone above has said.  And will point out that there are a lot of assumptions being made by everyone. And every response is centered around "what makes sense and is agreed to by the entire team."  (I paraphrased a bit).  

I have been faced with this situation.  To @Thomas Owens concern about timing, the teams I have faced this with have Sprint Review before lunch. Sprint Retrospective and Sprint Planning occur after lunch. Or they have Sprint Review and Sprint Retrospective at the end of a day, Sprint Planning is the start of the next day. There have been times that the feedback can be incorporated in between the events and the Dev Teams agree to do it. I will point out that these changes are usually very superficial UI changes and not significant backend changes. With all of my teams, the discussion in Sprint Review is around how involved the change is seen to be and how risky it will be to make a quick change of that nature.  If the entire Scrum Team feels it is acceptable, then the change gets made. If not, it goes to the Product Backlog for future consideration. Having this discussion in front of the stakeholders aids in the total understanding of why the particular decision is reached. Remember that a Sprint increment is potentially releasable so getting to fully releasable does not have to occur every sprint. 

I agree with what Daniel mentioned. I just have a small point to add.

Or they have Sprint Review and Sprint Retrospective at the end of a day, Sprint Planning is the start of the next day. 

In situations where the product feedback cycle with stakeholders is not so frequent, why not have the Sprint Review even a day before the Sprint ends? i mean it might give bit of more time to make the necessary adjustments to the product. 

@Harshal Rathee  In my current organization getting stakeholder feedback is not an issue. We actually get feedback from our stakeholders on a continuous basis through our sprints. 

But even if it were difficult, I would continue to coach that the Review, Retro and Planning occur consecutively on the same day or split across two days as I mentioned.  In reality, any adjustment, no matter how small could be introduced into the Product Backlog and incorporated in a future Sprint.  Since the Development Team used the information that they had available to forecast their work in a Sprint and adapted as new information came to be known, there really isn't a driving force to immediately implement feedback obtained in the Sprint Review.  If it really is a small change, then spending a couple of hours in the next Sprint is not a major problem. If the change is really minor it shouldn't be prohibitive to the stakeholder's ability to use the product and it can be delivered at most 1 Sprint time-box later.

This is very useful and interesting feedback! I appreciate it!

can anyone tell me what feedback is given by stakeholder in sprint review meeting??

@Swapnil, whatever feedback they can depending on their experience, role, etc. as a stakeholder. If a user of the product, they may give feedback on usability and capabilities.  If an executive on the organizational side, maybe feedback on how it fits into plans and goals, costs, needs they hear from customers/user, etc.  There is no "what feedback" as it will differ from person to person, role to role and case by case.  This is the opportunity of the Scrum Team to learn and move forward effectively.  Get any information that they need to ensure that they are on the right track, adjust and improve.

To add to this, a Product Owner might choose to invite stakeholders that can provide various different kinds of relevant feedback.

When I use the word feedback in relation to Scrum I think of this passage from the beginning of the Sprint Review section of the Scrum Guide.

 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.

To me feedback is anything that aids the Scrum Team and stakeholders to align on what is needed.  As @Eric Naiburg points out, the type of feedback will depend on the perspective of the stakeholder. I have even had teams that were writing public facing APIs that got feedback from internal developers that wanted to use the same API. Marketing can provide feedback that can help lead to adoption of the product features. I've even had one instance where an Human Resource representative from our company provided some feedback on the fact that our product wasn't usable by individuals with disabilities.  Anything that helps guide the Scrum Team to build something with greater value is feedback.