Here at Scrum Inc. we've been thinking a lot about two things: impediments and the Sprint Retrospective. These are really where the rubber meets the road in terms of improving productivity. We'll have a later post on impediments, but I wanted to share this excerpt from Jeff's and Ken Schwaber's forthcoming book "Software in 30 Days," which comes out May 1st. We emailed it around our team yesterday after our retrospective just didn't feel strong enough. It is a good reminder that the Sprint Retrospective can be one of the more difficult things to do in Scrum, but also one of the most powerful.
Every member of the Scrum team strives to improve, Sprint by Sprint. The Sprint Retrospective is where the improvements are formulated. This meeting should be a natural break between Sprints, the Sprint Retrospective is when the Scrum team sits back, reviews what happened during the last prior Sprint, and formulates ways to improve their work and the way the work is conducted. The discussion might include:
- Whether or not the team members worked together well or not and why.
- Whether the team did more or less than it forecast and why.
- Whether the team has all the skills and facilities it needs to do the job.
- Whether or not the developers understood the requirements and why.
- Whether the team was able to complete the Sprint in line with the requirements, and, if not, why not?
- What could be improved or dropped in the next increment of functionality.
Next, the team identifies several things to do differently in the upcoming Sprint that will increase creativity, effectiveness, and productivity. In general, Scrum Teams continually improve. This is the Scrum Team’s chance to make its work and life better. New requirements often arise during the Sprint; new opportunities and challenges also arise. Often, just seeing the increment of functionality evokes new ideas.
English 
French 
Spanish