The scrum retrospective is a hard meeting if it is done wrong. On the other hand if it is done in the right way I offers a great chance improve the team morality, efficiency and happiness.
Participants: Development Team, Product Owner, Scrum Master
Moderator: Scrum Master
Content: Learning and improvement process
Duration: 45 minutes per sprint week
Time: After sprint review and before start of the next sprint
Reflection of the last sprint and the made experiences. Identify and define opportunities for improvement of the development process.
The scrum master will note all outcomes of the meeting.
Execution of the meeting
The retrospective should be done in a protected space. So you should execute it in a meeting room and not in the team room where other people are present or walk in. Furthermore the line manager of the participants should not be present in this meeting. During the meeting no criticism of persons is allowed and if you speak about observed problems should not search for a guilty person.
Initially you should note and visualize all relevant events of the past sprints on a timeline. The scrum master has to write these things down for example by using a flip chart. Then use a second flip chart to write down what went well and what could be improved. These points can be sorted by groups, e.g. team-specific issues and organization-wide issues.
At next you should go through all the points and do improvement suggestions. So you can look at the points which went well and think about possibilities to extend these points. And of course you should look at things you want to improve. So you should create a list with improvement suggestions. If this list is finished you have to prioritize the points of the list.
Improvement suggestions which affect the team only will be solved by themselves. The scrum master is only responsible for the remaining issues. Improvement suggestions which can be put into practice without or with low effort should be done immediately. All other things should be transferred as user stories into to product backlog. The team will then do an effort estimation for these new user stories. And now these improvement suggestions will be handled like any other user story. So the product owner can decide within the planning meeting 1 which of these improvements are done during the next sprint.
If you want to change something within the development process, the scrum retrospective will give you a perfect opportunity to start an improvement process.