When to talk the problems we encountered during sprint, Sprint review or Sprint Retrospective? 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?

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.