Getting actionable ideas from Sprint Retrospectives

At the end of each Sprint our teams have a Sprint Retrospective.  In this meeting the team look back at the things that happened during that sprint.  Good, bad or indifferent, the points are discussed to allow the team to hopefully improve upon their performance during the next sprint.

The retrospective meeting is mainly for the benefit of the team however we sometimes ask our Product Owner along too.

During the meeting the Team are asked 3 questions:

·       What worked well last Sprint that we should continue doing?

·       What didn’t work well last Sprint that we should stop doing?

·       What should we start doing?

The Team then prioritise in which order they want to talk about the potential improvements and each item is then discussed separately and actionable items are collated by the ScrumMaster for implementation in the following Sprint.

To avoid the retrospective from becoming long, drawn out meetings we employ the following guidance:

·       Time box the meeting as these discussions have a tendency to run over.

·       Throughout the Sprint keep a log of things that happened during the sprint and things that the Team are doing differently to the last Sprint.  At the beginning of the meeting give an overview of these.  This helps focus the developers on improvements that could be made.

·       Each item raised should have an associated action for improvement.

·       Get the Team to write their points on post its and stick them to the wall.  Then ask them to prioritise the points to ensure that the most important ones are discussed first.

Viewing progress through releases

In the Harvard Business Review article on Breakthrough Ideas for 2010, Teresa M. Amabile and Steven J. Kramer note that what really motivates workers is not recognition or incentives but rather the feeling of progress.  They write that from extensive study of workplace activities  it has been found that "On days when workers have the sense they’re making headway in their jobs, or when they receive support that helps them overcome obstacles, their emotions are most positive and their drive to succeed is at its peak".


I recently remembered this article when discussing the benefits of Scrum with a client.  When using Scrum the overall project progress can be demonstrated using a Product Burndown Chart as this shows the overall progress through the Product Backlog.  However this must be used carefully as the Product Burndown can increase over time as new features are added to the Backlog.


The addition of new features to the Product Backlog should not be discouraged, the fact that new requirements can be easily and quickly added to a Product Backlog to deliver the greatest ROI in the shortest time is one of the main advantages of Scrum.  However the Product Burndown may not be the best way to show progress within your team as they may mistake the addition of items to the Backlog as negative progress.


Instead, planned, regular releases, occurring after a set number of Sprints, each with specific goals, can give your team the sense of progress that they desire.  With each successful release being celebrated and reviewed.  The release need not be shipped, rather it is used as a target for developers, a goal with which they can gauge their success.


Within a project with a large number of Sprints the completion and release of a Sprint can in time become the norm and the view of progress being made can become hazed.  With the addition of releases the team have larger goals allowing them to assess their efforts and more importantly view their progress throughout the project.