Toward Scrum, part 3: The Retrospective

← →

Russell Bateman
December 2016

Looking at the past provides clues as to where to go in the future. A retrospective answers these questions for each team member.

1. What went well?
2. What didn't go so well?
3. What have I learned?
4. What still puzzles me?

The single most important thing to know about a sprint retrospective is that it's not about the work that's done in the sprint, but about how that work went in terms of Agile/Scrum.

It's hard to make developers cough up what amounts to actual retrospective comments. Explain what a retrospective is really about and, even if they're careful not to lapse into a recital of what projects they successfully completed or failed to complete, they'll sit perplexed by what they should try to say.

One good way around that is to ask questions they can answer with what they do know:

1. What do you think helps you to be successful as a team?
2. How did you do any of those things this sprint?
3. Where and when did this sprint go wrong?
4. What did you expect? from whom?
5. What tools or techniques proved to be useful? (Not limited to "Agile" tools!)
6. Which did not?
7. Were there any major bugs? How were these solved? How much did they detract from sprint velocity? Could these bugs have been predicted?
8. What caused the problems that you had in this sprint?
9. What was your biggest impediment, obstacle or blocker?
10. If you could change one thing, what would it be?
11. Where did things go wrong in coding, testing, etc?
12. Which things went smoothly in this sprint? Which did not?

← →