For those who might not yet be aware, at the end of an agile sprint we do (we must do! we should do!) the retrospective. Its goal: to highlight in the context of the iteration we just completed: what worked, what didn’t work, what we could improve.

Here’s one (it’s a mix of excerpts from several clients, which I’ve anonymized), just to make things concrete. You can judge it, criticize it, use it, etc.

How: we gather the whole team (team, scrummaster, product owner). We set 4 main axes: “the pluses”, “the minuses”, “the optimizations to consider”, “the action plan”. The action plan being made up of optimizations that we want to implement right away, or that concern an event for the next sprint. Almost an antechamber: if we regularly consider the same optimization we’ll have to decide to move it into “action plan”. Similarly we can quickly slip into “the minuses” the action plan items that we ultimately haven’t or poorly implemented. Everyone mentions the points they want to highlight. I only intervene (as ScrumMaster) at the end, but I have my say and if I can influence in one direction or another I don’t hesitate but I don’t decide.

My comments in italics.

The pluses

• More complete backlog and stories (More complete stories: at the level of acceptance tests and/or validation scenarios)
• Reorganization of the space, room, post-its, etc. (at this client a dedicated space was set up for agility during the sprint).
• Team motivation (speaks for itself, but I explain that it’s normal with Scrum to have more motivated teams. On the other hand it’s essential to signal when motivation is no longer there, and especially why. Not everyone can be motivated 100% of the time.)
• Integration of unit tests in the definition of done (speaks for itself)

The minuses

• Poor breakdown of stories and tasks (too many dependencies !)
• Punctuality (speaks for itself)
• An external expert can interfere with the sprint scope without being part of the team. (we’ll need to resolve this point if it repeats, it’s a watch point)
• Pace not regular enough (last-minute rush). Story validation must be regular. (speaks for itself, an action plan item is dedicated to this problem)
• Difficulty reconciling sprint focus and external requests (we need to protect this team)

To consider/optimize?

• Integrate peer review in the definition of done (that is to say that in this case it applies to all stories).
• Better data sets.
• More/Better use of coding/development/naming standards. (XP…pair programming will follow…)

Action plan

• Regular validation of stories (no final rush) (on the next sprint -3 weeks- we set the first validations for the second week)
• Each team member announces to the others at the beginning of the sprint the number of days they estimate they can accomplish on the project (some estimation issues linked notably to “actual” time spent on the sprint)
• Team temperature chart (one of the participants is coming out of a Scrum training, they told him about a chart describing the morale curve of team members, he wants to implement it. I’m going to hand over to him as ScrumMaster to take a step back. This is his first “mission” as ScrumMaster: establish this chart and monitor troop morale)
• advance preparation for the arrival of a new team member (announced for next month, we need to prepare this arrival, the last time we lost a ton of time!)

There you go. The retrospective lasts one hour max. I display on the wall (radiator) only the action plan. Naturally the more concise it is the more it will be followed [2012 revision: the action plan should contain only one single item!!!].