-
Notifications
You must be signed in to change notification settings - Fork 41
Sample retro doc
This an example of how one might structure a sprint retrospective. This document should be open in a shared location, where all can edit and see it (for example, a shared Google doc). First, time-box 5 minutes. The team goes at the doc and writes things that are going well (。◕‿◕。)
, things that are meh ¯\_(ツ)_/¯
, and things that are not going well (╯°□°)╯︵ ┻━┻
as bullet points. Next, time-box 3 minutes. The team dot-votes on the points raised, as per the @ and + instructions below. Finally, time to discuss. The moderator should starts with the good stuff, to start on what's going well, and then jumps to talk about the (╯°□°)╯︵ ┻━┻
with the most dots. Possible ways to resolve are discussed and added to the 'actions' section at the bottom. The moderator continues leading the discussion in dot-order.
Key points:
- Everyone starts adding to the doc separately. This avoids some amount of groupthink, and also allows those who don't speak right away a chance to write.
- We write these down. Only talking through a retro doesn't always lead to concrete solutions.
- We have actions. We want to try to mitigate or solve the issues raised, not just air grievances. The point of retro is process improvement.
Retro Prime Directive: Regardless of what we discover, we understand and truly believe that everyone did the best job they could, given what they knew at the time, their skills and abilities, the resources available, and the situation at hand.
@ = +1; awesome; (。◕‿◕。)
+ = +1; I share this concern; ¯\(ツ)/¯; (╯°□°)╯︵ ┻━┻
- Your
- Feels
- Here
- Your
- Feels
- Here
- Your
- Feels
- Here
- Add
- These
- As we
- Discuss
- Feels
- Problem statement
- Product vision
- User scenarios
- What we're not trying to do
- Product risks
- Prioritization scale
- Joining the team
- Onboarding checklist
- Working as a distributed team
- Planning and organizing our work
- Sample retro doc
- Content style guide
- Content editing and publishing workflow
- Publishing a blog post
- Content audits: a (sort-of) guide
- User centered design process
- Research norms and processes
- Usability testing process
- Observing user research
- Design and research in the federal government
- Shaping process
- Preview URLs
- How to prepare and review PRs
- Continuous integration tools
- Releasing changes
- Github Labels