Sprint Retrospective is the opportunity for the entire Agile Team (Product Owner, Scrum Master and Development Team) to inspect and create an action plan for improvements to the next sprint. The meeting helps the entire team to identify what worked well, and what should be improved.

I have some tips for making sure the meetings go swimmingly:

  1. The Scrum Master must be well prepared as a facilitator for the meeting.

There are thousands of retrospective techniques published in books and blogs, which when applied well achieve wonderful results. The main question is how and when to apply one particular technique or flow rather than another. However, an important issue is not only knowing the technique but knowing how to facilitate a retrospective.

Expertise in conducting good retrospectives is only gained after a period of experience. There is no single way for the Scrum Master to conduct good retrospective meetings.

The points below will help the Scrum Master to be prepared for the meeting:

  • Be prepared: Collecting relevant facts prior to the sprint cuts out the discussion as to whether, say, we have 20 or 25 stories completed.
  • Let all participants express their points of view.
  • The more the Scrum Master knows the team and the people, the more efficiently he or she can conduct the meeting. Get to know you team mates, and help them express themselves.
  1. Choose a good time for the meeting.

The scheduled day and time of a Sprint Retrospective is very important, because depending on the team and the daily work scenario, people may be tired, or focused on other important aspects such as deployment or bug fixes. You have to make sure everyone is available. First thing on the day after the sprint finishes sound good, but team members may also need time to gather their thoughts.

  1. The product owner needs to be present.

It is critical that the product owner is present to make a meeting effective and more productive. This is even written in the Scrum Guide. The first sentence of the Scrum Guide on Sprint Retrospective is as follows: “The Sprint Retrospective is an opportunity for the Scrum Team to inspect itself and create an improvement plan to be implemented in the next Sprint.”

Since the Scrum Team is composed of the three Scrum roles, including the product owner him/herself. The presence of the product owner is mandatory, whether or not your Scrum Team enjoys it.

  1. Do not look for the guilty.

One of the biggest fears when people enter a Sprint Retrospective is that the meeting becomes a witch hunt, where the only thing that matters is to find whoever is guilty for the problems. To avoid this, it is very important that the team understand the objectiveness of the meeting. The team should be prepared from the outset to listen to constructive criticisms so that they can create an action plan of improvements for the next sprints.

This will only be achieved after a time of maturation of the team within the Agile methodology, so these discussions should be encouraged by the Scrum Master.

Agile Development: Project Schedules on an Agile Methodology

If you come from a traditional project management background, or if you have a Project Management Office (PMO) that needs a project monitoring tool or status, then you’ll be used to Gantt charts; but in Agile we’ve got even better tools for the management and visualisation of progress.

Tracking the burndown graph that shows the evolution of the sprint is vital to the progress of the development cycle, as are Kanban boards that make it easier to see the task progression.

By using these two tools, we actually have significantly more control than with a complex Gantt chart. The tasks are the stories, which for the users have a clear outcome, as they can actually see the deliverable emerging.

The Kanban Board  is used to show progress of individual stories and their progression through the development cycle. There is no need to micro-manage the sub-tasks – just keep an eye on the story.

Kanban Board

 

 

 

.

Burndown Chart

 

 

 

 

 

The burndown shows the throughput of work, and how much there is to go. The work left to be done could be seen as both effort and complexity – because they are the same thing.

Here are some tips that can help you create these progress charts for Agile software development projects:

  • Don’t overcomplicate the Kanban board; just make sure it works and is being used.
  • The most granular level in the Agile timeline is that of the stories, so it is not necessary to include sub-tasks for the stories.
  • It does not make sense to control the timing of each story, since we are talking about the timing of each iteration (sprint), and the set of stories that compose these iterations.