Join GitHub today
GitHub is home to over 28 million developers working together to host and review code, manage projects, and build software together.Sign up
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.
- 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.
NRRD Retro ~ [date]
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; ¯\(ツ)/¯; (╯°□°）╯︵ ┻━┻
- As we