-
Notifications
You must be signed in to change notification settings - Fork 6
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
- Technical overview
- Contributing to code
- Creating a new branch
- How to prepare and review PRs
- Releasing changes
- Database change management
- Tech Solutions
- Data overview
- How to upload monthly data
- How to upload OGOR-B Data
- Troubleshooting for specific datasets
- Goals and metrics
- Analytics
- DAP-GA4 templates & instructions
- DAP-UA templates & instructions
- User research plans & findings
- Joining the team
- Onboarding checklist
- Working as a distributed team
- Planning and organizing our work
- Sample retro doc
- Human centered design process
- User research study process
- Design Standards
- Usability testing process
- User research participant guide
- User research agreement
- Observing user research
- Design and research in the federal government
- Shaping process
- Research wiki
- Data catalog
- Problem statement (2016)
- Hypotheses (2016)
- Outcomes workshop (2017)
- Transition goals (2018)
- Product management training (2018)
- Information architecture
- NRRD-flavored Markdown (Jekyll site)
For information about our other website see our ONRR.gov wiki.