At TG, I do the scrum master role for four development teams. For three of those teams, part of that role involves conducting an iteration review meeting. In this meeting, the goal is to inspect and adapt. Essentially, the team takes a look at what happened over the last iteration and figures out how to improve it.
In my first few iteration review meetings, I asked three questions:
- What went good'
- What went bad'
- What are our recommendations'
After a few of those meetings and a bit more reading, I've changed my structure to ask four questions:
- What did we do well'
- What did we learn'
- What should we do differently next time'
- What still puzzles us'
I've found that the phrasing of these questions gets better results. In particular, the rephrasing of 'what went bad' into 'what did we learn' seems to make folks a bit more open to discussing things that they want to improve.
In addition to these broad questions, I have a number of charts of metrics that I discuss:
- # of stories completed
- total story points completed
- total task points completed
- iteration burndown chart
- code coverage
- build automation success (i.e. how many times has the build broke')
- FXCop
- defect count
Metrics bring out a lot of strong opinions. Put simply, they suck if they're used the wrong way. However, metrics have a lot of value if they're used in the proper way.
That's about it for the reviews. They can take 30 to 60 minutes to complete properly but could take much longer if your iterations are longer than a week.