Sprint Retrospectives

All Teams Should Do Retrospectives
The most important thing about retrospectives is to make sure they happen. They are extremely useful, and are the second most important event in Scrum (the first being the sprint planning meeting) because this is your best chance to improve! Without retrospectives you'll find that the team keeps making the same mistakes over and over again.

Organize Retrospectives
Do something like this:
 * Allocate 1-3 hours depending on how much discussion is anticipated.
 * Participangs: The product owner, Scrum master, and the whole team.
 * We move off to a closed room, a cozy sofa corner, or some place like that. As long as we can have undisturbed discussion.
 * Usually don't do retrospectives in the team room, since people's attentions will tend to wander.
 * Somebody is designated as secretary.
 * The Scrum master shows the sprint backlog and, with the help from the team, summarizes the sprint. Important events and decisions, etc.
 * Each person gets a chance to say, without being interrupted, what they thought was good, what they think could have been better, and what they would like to do differently next sprint.
 * Look at the estimated vs. actual velocity. If there's a big difference try to analyze why.
 * When time is almost up the Scrum master tries to summarize concrete suggestions about what to do better next sprint.

Feel free to use a whiteboard with the following three columns:
 * **Good:** If we could redo the same sprint again, we would do these things the same way.
 * **Could have done better:** If we could redo the same sprint again, we would do these things differently.
 * **Improvements:** Concrete ideas about how we could improve in the future.

After the team brainstorm up post-its, they use "dot voting" to determine which improvements to focus on during next sprint. For example, each team member is given 3 magnets and is invited to vote on whatever improvements they would like the team to prioritize during next sprint. Each team member can distribute the magnets as they like, even placing all three on a single issue.

Based on this select some process improvements to focus on, and follow this up during next retrospective. It is important not too get overambitious here. Focus on just a new improvements per sprint.

Spreading Lessons Learned Between Teams
The information that comes up during a sprint retrospective is usually extremely valuable. Is this team having a hard time focusing because the sales manager keeps kidnapping programmers to participate as "tech experts" in sales meetings? This is important information.

A sprint retrospective is not only about how this one team can do better job during next sprint, it has wider implications than that. One person attends all sprint retrospectives and acts as the knowledge bridge. Important rules for the "knowledge bridge" person:
 * He should be a good listener.
 * If the retrospective is too silent, he should be prepared to ask simple but well-aimed questions that stimulate discussion within the group. For example "if you could rewind time nad redo this same sprint from day 1, what would you do differently?"
 * He should be willing to spend time visiting all retrospectives for all teams.
 * He should be in some kind of position of authority, so he can act upon improvement suggestions that are outside the team's control.

To Change Or Not To Change
By just identifying a problem clearly is enough for it to solve itself automatically next sprint. Especially if you post the sprint retrospective on the wall in the team room. Every change you introduce has some kind of cost so, before introducing changes, consider doing nothing at all and hoping that the problem will disappear (or become smaller) automatically.

If you introduce a new change every time someone complains about something, people may become reluctant to reveal minor problem areas, which would be terrible.

"We should have spent more time breaking down stories into sub items and tasks"
This is quite common. Every day at the daily scrum, team members find themselves saying "I don't really know what to do today". So after each daily scrum you spend time finding concrete tasks. Usually more effective to do that upfront.


 * Typical actions:** None. The team will probably sort this out themselves during next sprint planning. If this happens repeatedly, increase the sprint planning time-box.

"Too many external disturbances"

 * Typical actions:**
 * Ask the team to reduce their focus factor next sprint, so that they have a more realistic plan.
 * Ask the team to record disturbances better next sprint. Who disturbed, how long it took. Will make it easier to solve the problem later.
 * Ask the team to try to funnel all disturbances to the scrum master or product owner.
 * Ask the team to designate one person as "goalkeeper", all disturbances are routed to him, so that the rest of the team can focus. Could be the Srum master or a rotating position.

"We overcommitted and only got half of the stuff done"

 * Typical actions:** None. The team will probably not overcommit next sprint. Or at least not overcommit as badly.

"Our office environment is too noisy and messy"

 * Typical actions:**
 * Try to create a better environment, or move the team offsite.
 * If not possible, tell the team to decrease their focus factor next sprint, and to clearly state that this is because of the noisy and messy environment. Hopefully this will cause the product owner to start pestering upper management about this.