If you ask poor questions in your retrospectives, you will get equally poor results. To uncover the problem areas that you need to focus on, you need to ask the right questions. Here are a list of questions I have compiled over many years of retrospectives.
Most of the questions here are very developer-centric, but some also apply to the broader picture.
The Three General Questions
These three questions cover most of what you want in a retrospective, but are too broad to be useful by themselves.
- What worked well?
- What didn’t work so well?
- How can we do better?
Specific Questions
Here are some specific questions I have found useful. Pick the ones that are most relevant to your situation.
General
- What is keeping us from delivering more value?
- Is the path blocked by unresolved obstacles?
- Are we getting to done?
- Are we uncovering new things every retrospective?
- Are we managing risk effectively? (tackling high risk tasks, or avoiding?)
- What were the biggest pain points? What was difficult?
- What low-hanging annoyances can we remove?
Team
- Are the team members happy? Tired? Grumpy?
- Are team members really collaborating? Learning? (in general, and from one another)
- Are we effectively utilizing the strengths of the team members?
- Are team members taking initiative?
- Are we respecting the team norms?
Communication
- How effectively are we communicating?
- How much time does the Product Owner spend with the team?
Environment
- What in our physical space is hampering our effectiveness?
Planning/Execution
- Are we faithfully tracking and discussing effort remaining?
- Are our tasks clearly defined?
- Were our estimates accurate? Why/Why Not? How can we do better next time?
- Were our requirements sufficient?
- Are the user stories too granular? too nebulous?
- Was the workload too much or too little? (Are developers over- or under-worked? Are they energized?)
- Are team members able to do focused work or are they pulled in too many directions?
- Was there an appropriate amount of slack time for cleanup and improvement?
Processes & Practices
- Is our iteration length appropriate?
- Should we pair program more? or less?
- Do we have sufficient test coverage?
- Is the quality of our code sufficient?
- Is our code base improving or degrading? Why?
- Are we adhering to development principles?
- Are we appropriately utilizing automation? (If you do something more than once, try to automate)
- Are we handling the unexpected well or reverting to our old ways?
- Are we utilizing the tools we have effectively?
- Are there any tools that would help us be more effective?
Resources
Some of the questions and concepts were taken from the following cheatsheets by Berteig Consulting.
