Retrospective Goals

The goals of our retrospectives is not only to find areas that have to be improved, but also to make everyone aware of areas that work well. This is important both to make sure that everyone on the team knows what the success factors are – those habits that we should just keep on with and not forget. It also works as a moral booster that we are not only focusing on problems.

We split our retrospectives in four parts:

1. Group Brainstorming on Areas
2. Individual Brainstorming
3. Presentation
4. Discussion and Action Point Summary

Group Brainstorming on Areas

The first thing we do is to do a group brainstorming on areas. Everyone can come up with suggestion of areas that we should think of and discuss. A typical list from this first phase could look something like this:

• Requirements
• Code Reviews
• Development Environment
• Sprint Demo

There is no motivation done on the areas suggested, they are just listed as they are mentioned. This phase is typically done in a few minutes.

Individual Brainstorming

The second phase is the individual brainstorming. Everyone grabs a bunch of post it notes and a pen. On each post it note a plus or minus sign is noted together with a short comment.

+ The new deploy routine is really great.

- Sprint Demo was not well prepared. Embarassing in front of customer!

 

There is no limit on what topics can be listed. Everything that is related to the project can (and should!) be mentioned. When out of inspiration for more issues, the list of areas can be consulted, but there is no kind of limitation to only keep to those areas.

Presentation

When everyone has finished writing it’s time for the presentation. Each one on the team presents their post-it notes, putting them up on a whiteboard. Related notes are posted close to each other. Being the last one to present means frantically trying to remember if someone else said something similar and finding that note…

During the presentation there is no discussion, but it’s fine to ask questions for clarification.

- Was it the stuff that we demoed that wasn’t tested enough, or was it the order we demoed the issues in that was bad?

Discussion and Action Point Summary

Finally it’s time for discussion. At this point it is clear where the huge issues are. It’s just to look for clusters of minus-marked notes. Wherever there are several of them that are about the same issue something has to be done.

We pick the most important issues and then sort out what to do about them. Some goes to the team as general advice for the next sprint

Think twice before interrupting a fellow developer with headphones on. Send a mail or Skype message if the possible to avoid interrupting.

Some is added to the backlog

Fix build routine for deploy packages to be possible to do in one step.

Some is added as another point to the definition of done list

Always do a rebuild all and check for warnings before committing.

Some are sent on to the product owner to handle

The shopping basked checkout confirmation by writing a signature with the mouse is really, really awkward to use. Should we really keep it?

Last, but not least we take a look at the list of plus notes and talk a bit about them. Then we leave with the feeling that we’re doing a great job. Next sprint we’ll be even better, it’s time to raise the bar once more to get one step closer to perfection.

Scrum series

• Scrum for Developers
• Scrum – Nowhere to Hide
• Scrum and Project Governance
• Requirements in Scrum
• Disarming Different Estimates with a Deck of Cards
• Test and Verification in Scrum
• Scrum and the Business Implementation
• How we do Sprint Retrospectives