From Fedora Project Wiki
There are many ways to conduct retrospectives, so this is a write down on how it works for our team with 3 people.
Offline Process
- Use sticky notes (red for items which need improvement, green for positive items from the sprint).
- Every team member notes down a small sentence on the sticky notes, using one sticky note for each item.
- The sticky notes are all attached to a whiteboard or surface for discussion.
- Every team member explains its sticky notes.
- The team agrees on common good points and common problems from the sticky notes.
- What action items from the last retrospectives are solved, needs revisiting.
- Solutions/Action points are derived from the noted down problems.
Digital Process
Based on the described offline process:
- Use a system which allows comments underneath a document.
- Every team member starts with adding a comment with a list of good points and things which need improvement (sticky notes).
- Now let every team member explain their notes.
- Collect common good points first and list them underneath a table showing retrospective outcomes.
- Now collect the common problems.
- Compare what action points you have made in the last retrospective. Are they done?
- Once you have listed the common problems, think about solutions in a team. These solutions will form action points if applicable.
Tips
- The retrospective list should be written in full sentences not just bullet points. This makes it easier to understand outcomes once you read them again in a couple of weeks/months.
- Remember: the retrospective is about the development process not about technical difficulties with the code.
Common Pitfalls
- Good/Bad points not process oriented, but technical problems. Code improvements are better discussed on bugs or mailing lists.
- Agree on what a common problem is first, before you think about solutions. This is very common cause of missed opportunities to think about a solution as a team, since it's very easy to propose already a solution to an individually perceived problem.
- Check the action points of your last retrospective. Are they done? Do they still need doing? There is no point to add new items if you haven't even addressed the action points from the last retrospective.
- Remember: just because you conduct a retrospective, doesn't automatically improve your process. You'll have to actively look back and judge if the action points are actually working for you.