When to talk the problems we encountered during sprint, Sprint review or Sprint Retrospective?

Question

I'm still learning about Scrum. In the book I read this:

The sprint review focuses on the product itself. The sprint retrospective, on the other hand, looks at the process the team is using to build the product.

I want to know where should we talk about the problems we encounter during Sprint Execution, such as when we found too many bugs and that's why we need more time to fix it but we are still able to fix the problem on time. In sprint retro, the developer should answer 3 questions (What worked well?, What didn’t work well?, Where are some opportunities to do things differently?) and I feel like the example that I stated before fits in the sprint retro rather than sprint review, but sprint review also talks about the product which is something I'd like to talk about in the sprint review.

How can I differentiate between those two?

Answer 1

Discussing problems during Daily Scrum is perfectly fine. When a team member mentions some impediment you can stay right after the Daily Scrum and discuss the issues. From Scrum Guide:

Here is an example of what might be used (during Daily Scrum):

• ...
• Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?

The Development Team or team members often meet immediately after the Daily Scrum for detailed discussions, or to adapt, or replan, the rest of the Sprint’s work.

Retrospective is more formal because not everyone is comfortable raising issues during the sprint, some people need a dedicated time for this. Also some problems are deep and complicated and require a long discussion.

Spring Review is about demonstrating the progress, more like a demo. Its purpose is to inspect the Increment and adapt the Product Backlog if needed. So Retro is about the team and process, Review is about Backlog and product.

Answer 2

I think it's generally true that the emphasis of the Sprint Review is on the product and the Sprint Retrospective is on the process, but that doesn't mean the Sprint Review is exclusively about the product and the Sprint Retrospective is solely about the process.

The Scrum Guide does state that during the Sprint Review, "the Development Team discusses what went well during the Sprint, what problems it ran into, and how those problems were solved". However, it's also appropriate to understand who attends the Sprint Review. Both the Scrum Team and stakeholders are present. Since a discussion of problems is only one element out of several identified and there are external stakeholders present, it's not a good opportunity for a deep dive into all issues and solutions. It would be helpful to identify the problems of interest to all attendees.

The Sprint Retrospective is a more appropriate place for a deep dive into problems encountered during the Sprint. However, distilling the retrospective down to 3 questions is likely to be an oversimplification. The questions may be useful to hear from everyone and prioritize what to discuss quickly, but merely answering a few questions won't help the team perform a deep dive and come up with meaningful process improvements to help improve the way of working.

Answer 3

Problems or things which went wrong, should be raised in the retrospective.

The retrospective is for the whole team internally. The results can be shared with others. The retro is the event with the green (what went well) and red cards (space for improvement). Inside a retro the are no hirachy, many teams exclude management from that meetings, so everybody can speak open.

The review is the event where the new product feature are presented to the team, other stakeholder, other teams, other departments of the company or even to customers.

Answer 4

There isn't a straightforward answer to this type of question because a lot depends on:

• the nature of the problem. Is this a technical problem? Is it a product related problem? A problem regarding the processes, practices or tools? Is it about the team?
• the target audience. Who needs to know about this problem, and most importantly who needs to solve it?
• raising the problem vs solving it. You have to realize that any problem is first discovered and then solved. These are two distinct things and can occur one after another in a short period of time or they can occur after a longer period of time. Talking about a problem can mean raising the issue, solving the issue, or somewhere in between. A rule of thumb is to allow a problem to be raised anytime (it's good communication) but then think about the nature of the problem and who needs to know about it in order to decide when to solve it.

Here are some examples:

• a developer discovers a problem during the sprint that affects the goal of the sprint. They can raise it to everyone on the spot, or they can wait for the daily standup. It will be too late to raise it at the review or retrospective because by that time the team would have probably already missed fulfilling their Sprint Goal. Depending on what kind of problem it is, you might solve it on the spot, you might solve it during the stand-up (usually not possible because the daily is time-boxed to 15 min, unless the problem can be solved by someone taking a decision, like the product owner, for example), or people can meet together after the daily to solve the problem.
• someone discovers an inneficiency in the process. They can again raise it on the spot, at the daily, or wait until the retrospective. This is something to solve by the team and will most likely be discussed during the retrospective. It can be solved during the retrospective, or everyone can decide on action items that will be implemented during the next Sprints until eventually the inneficiency is resolved.
• if the problem is related to the product (i.e. a business issue) it can again be raised immediately, during the daily, during the retrospective, or most likely during the review. During the review the team demonstrates the increment they built and ask for feedback and it's the best place to talk about any business problem. The problem can be resolved during the review meeting, or again, people might decide on some approach that takes more time to be implemented. Just as well, the Product Owner can take care of the problem (if possible) when it was initially raised and not wait for the review meeting.
• given your example of too many bugs discovered during the Sprint, people can again raise the issue when they realize that "hey? Why so many bugs?" Or they can raise it during the daily, or wait until the retrospective if the team manages to fix the bugs but still want to discuss further what happened and how things can be improved. You will probably not need to raise this issue at the review unless this affects the product in some way (like you couldn't fix all the issue and the release contains bugs), or if it affects the work in the next sprints (like, you need to take some time to fix bugs or refactor your design, so you will have less features developed in your next increment);
• etc.

You also have to realize that you don't need to make a problem fit into some Scrum event like the review or the retrospective. If you need to organize a separate meeting to deal with it, you can do that too. Also, you don't need to raise the problem in just one place. Depending on the problem you might raise the same issue during the retrospective if the team needs to improve on the issue and you might also raise it during the review to discuss it with the stakeholders if this also affects the product.

Answer 5

In the Sprint Review, you show the customers (and everyone else that is interested) the product increment you have just completed. If during the sprint you encountered problems that caused you to deliver something else than what you lead them to believe (less functionality, different functionality, etc.), then it would be good to mention those problems as an explanation for why the expectations you gave can't be met.
If the problems didn't affect the product increment, then there is no reason to mention them in a Sprint Review.

If the problems are not just things that need to be solved on the technical side, but something that you want to prevent from happening (as frequently) in the future, then you need o adapt your processes to build in safeguards that can either help you spot the potential problems earlier or even prevent them from happening.
Such process changes are discussed in the Retrospective meeting.

If your problems affected both your product and you want to prevent them in the future, then you should bring them up in both meetings.

Answer 6

When to talk the problems we encountered during sprint, Sprint review or Sprint Retrospective?

When it's more effective.

Scrum (and agile) are not very prescriptive. That's one of the biggest challenges for people trying to shift into them. and that's good. Just requires experimentation.

The same challenges can (and will) be raised at different forums, depending on their nature.

Example:

• A team member is struggling to understand a specific piece of implementation. There's no reason to wait for the daily Stand up. Raise it right away.
• This team member didn't get the required assistance, for any reason. Raise it during the next daily Stand up to get assistance from the team.

• The team reviewed the code together and realised two things:

  a) the code is much messier than expected, exposing the Sprint goal to risk and

  b) there's a possibility to address the problem using a public library.

• It should be raised to the PO right away for discussion.
• The team raised the code challenge to the PO and the team missed a Sprint goal, but made the code more resilient and ready to be fixed on next Sprint as they adopted the public library.
• During Sprint review, this experience should be shared with stakeholders. Something like

we have found this unexpected problem during the Sprint ("what problems it ran into") and applied this solution that will increase our code quality in the future ("what went well during the Sprint")

• finally, during Sprint Retro, the team will discuss what the team can do to avoid recurrence of this problem (better refinement? more peer programming?)

In summary: Remember, such methodologies are not very prescriptive on purpose, to give people the freedom to experiment. Being agile is about experimenting. Fail fast, learn faster.