Among all, which 2 things should not be discussed in Sprint Retrospective?
> Definition of "Done"
> Arranging the Sprint Backlog for the next Sprint
> How does the team perform its work
> The value of work currently represented in the Product Backlog
> Relation of the team
Rather than listing what should not be discussed, I'd suggest the Scrum Team find specific topics that they feel they should discuss, in order for the Sprint Retrospective to achieve its intended purpose.
The Scrum Guide says that "the purpose of the Sprint Retrospective is to plan ways to increase quality and effectiveness". Although it specifically identifies "individuals, interactions, processes, tools, and their Definition of Done" as things to inspect at the Sprint Retrospective, I do not believe that is an exhaustive list. I'd inspect and discuss anything that enables the team to increase their quality and effectiveness.
Based on your list, some of these things are explicitly identified as things that should be inspected: the Definition of Done, how the team performs its work (processes), relations of the team (individuals, interactions). Although maintaining the Product Backlog and ensuring that its contents and their ordering represents the best path for value delivery is part of Product Backlog Refinement, I don't see why it can't be done at a Sprint Retrospective, especially if the team feels that the ordering of the Product Backlog is an impediment to quality and effectiveness.
The only one that I'd specifically exclude is arranging the Sprint Backlog for the next Sprint. This is a part of Sprint Planning, which would follow the Sprint Retrospective and start the next Sprint.
The only one that I'd specifically exclude is arranging the Sprint Backlog for the next Sprint. This is a part of Sprint Planning, which would follow the Sprint Retrospective and start the next Sprint.
I initially felt the same, but upon re-reading this part of the Scrum Guide, it occurred that a Scrum Team might already begin arranging the Sprint Backlog, even if there is more to be done in the subsequent Sprint Planning.
The Scrum Team identifies the most helpful changes to improve its effectiveness. The most impactful improvements are addressed as soon as possible. They may even be added to the Sprint Backlog for the next Sprint.
I almost thought the same thing, Simon Mayer, but I'm not sure that's true in the latest revision of the Scrum Guide. In it, the Sprint Retrospective "concludes the Sprint" and the Sprint Planning "initiates the Sprint". Since "a new Sprint starts immediately after the conclusion of the previous Sprint", there should be few working hours between the Sprint Retrospective and the Sprint Planning.
Given the nature of the Sprint Retrospective, it may be worthwhile for the team to talk about how they go about creating the Sprint Backlog, and perhaps even do some lightweight experimentation with techniques. However, generally speaking, crafting the Sprint Backlog isn't something that should be done in the Sprint Retrospective. There are more useful outcomes.
This only underscores the fact that it's important to understand the context behind questions and answers, such as the ones here. Without more information, it's hard to say for sure what the best thing for the team to do is. Generally speaking, though, I wouldn't expect the team to spend time crafting a Sprint Backlog at a Sprint Retrospective.
I think we're generally in agreement.
The point I was trying to highlight with my first post is that blanketly excluding topics is probably unhelpful, as opposed to focusing the Sprint Retrospective on achieving its purpose, irrespective of the topic.
My concern with questions like this, is they seem to want a dogmatic answer, which can then lead to inexperienced Scrum Teams tying themselves in knots because they read somewhere that something is forbidden.
If a Sprint Backlog were to exist a priori the Sprint, the value of Sprint time-boxing would degrade.
In the exam I had these choices for this question:
1- Identifying high priority process improvements for the next Sprint.
2- How the team collaborates.
3- The order of items in the product Backlog
4- Documenting acceptance criteria for items in the next Sprint.
Personnaly I think the first and the second options are the correct ones, but I hesitate with the answer 4 because I think it means the definition of Done.
The option 3 is discussed during Sprint Planning or any time during the sprint.
But if you were me, what would you choose?
In the exam I had these choices for this question:
Firstly, this post is about what should NOT be discussed, which means that out of your questions four answers, option 3 & 4 would not be discussed.
Secondly, if this question was from a Scrum.org certification assessment (not an open assessment), then you have just breached the T&C for that assessment by posting it on this forum.
For the OPs question, options 2 & 4 would not be discussed.
> Definition of "Done" -- there is no better occasion to discuss this than the retro
> Arranging the Sprint Backlog for the next Sprint -- this is on the agenda of planning
> How does the team perform its work -- good candidate for the retro
> The value of work currently represented in the Product Backlog -- this is for the review
> Relation of the team -- a retro-ish topic, isn't it?
Well, I would state simple, which 2 things should not be discussed in Sprint Retrospective?
> Arranging the Sprint Backlog for the next Sprint
> The value of work currently represented in the Product Backlog