3 End of an iteration
This guidebook is written following the diátaxis “how-to guide” style. And because this document reflects how we work in the Seedcase Project, it is living and constantly evolving. It won’t ever be in a state of “done”.
We track our iterations’ progress and tasks on GitHub with this project board.
- It’s good practice to assign a timekeeper to keep us on track and so we avoid spending too long on any one topic.
- While this guide can apply to all members of the team, several parts of it are specific to the team lead. Those parts will be explicitly marked to indicate that they are only for the team lead.
The iteration’s end is a meeting to debrief and do a retrospective on how things went during the iteration. These should be between 1-2 hours. There generally isn’t anything to prepare for, aside from considering things that worked well and things that could be improved on for the iteration, unless a team member will do a demo.
A basic agenda is:
- Demo (internally or externally) the progress of the iteration (or some other form of progress).
- Evaluate the iteration aim and review how you all did and what you’ve all (briefly) accomplished.
- Do a retrospective reflecting on what each of you think everyone should keep doing and what you all should stop doing or improve on, as well as how you felt you all did and what struggles or challenges you faced.
- Group the notes into topics and add action items (if any) to each of the topics.
During the debrief and retrospective meeting, it’s helpful and often quite insightful to include some type of demo or showcase of what the team has done during the iteration. This can be a demo of the product or something learned or achieved that relates to the iteration aim. If you are the team lead, you would ideally ask if anyone wants to do the demo before the meeting, so that the person can be a bit prepared for it (or at least, mentally prepared).
For the retrospective, ideally the team uses some type of real-time collaborative note-taking system, such as Figma. This just makes it easier to write down notes while also being able to see what everyone else has written too.
During the retrospective, set a timer (for example 4 minutes) and write out all the things that you felt worked well or to keep doing and what to improve on or stop doing. Include things that are more personal to you, but also to the team as a whole. For example, include any personal barriers or struggles you had during the iteration or any challenges that you felt the team faced. If you ever felt any source of tension or friction in how you worked or did things, this is an incredibly valuable source of information for the retrospective!
It helps to write down as much as possible, without thinking about solutions or action items. Write down things that gave you joy or made you feel good, as well as things that made you feel frustrated or annoyed or where there was some friction or tension.
Once everyone has written down their notes, move them into the “worked well” and “improve on” sections. Then, you each read out your notes and share a bit more about them. Afterwards, everyone helps grouping them into common themes or topics. Then everyone would go over them and try to identify if there are any action items that can be taken for any of the topics.
If there are any action items and if you are the team lead, you need to add these actions items as issues to track and complete them. Ideally add them as soon as the retrospective is done.