How should be a Sprint Retrospective ?

Sprint Retrospective

Sprint Retrospective is a meeting that happens at the end of each Sprint that usually occurs after the Sprint Review. This practice involves the Scrum Master and the team members to discuss what went right and what went wrong in the practices adopted during the Sprint. Thus, it allows modify some practices to maximize the positive and avoid negative points. This meeting provides a moment for greater interaction among the members and allows the team to self evaluate and propose the necessary changes, thereby strengthening the sense of teamwork.

Like the other meetings in Agile, the Sprint Retrospective requires many adjustments. In the experience reported in one of the Sprint Retrospective in John Deere TCI(Pune, 2013), someproblems that were faced related with the presence of all members at the meeting and related with the tool support. The first trouble was to find a time when everyone could attend, since this meeting was initially scheduled one day after the Sprint Review. The solution was to hold the meeting after the Sprint Review and limit the maximum duration for two hours, so this is not tiring. The second difficulty is the need for multiple tools for holding the meeting, the techniques to be followed to drive the meeting and raise the positive and negative suggestions, as well as project management tool like Rally for presenting data from the project’s progress, such as the Product Burndown.

Despite the importance of the presence of all team members in the Scrum meetings, in some situations, for example, a project with many distributed teams, a remote meeting with all members becomes impractical which should be avoided. Thus, for those situations, this proposed approach suggested to do a Sprint Retrospective by team, and saving the information collected at each meeting. This information collected should be shared to all members, allowing them to analyze the improvements suggested by other teams.

One last modification is to hold a meeting among each Scrum Master, similar with Scrum of Scrums, to discuss the Sprint Retrospective done by each team, and with that, it is possible to align the dependency among them. This meeting may occur the day after the Sprint Retrospective of the teams, and it is crucial that each Scrum Master considers the points raised by other teams before the meeting between them, in order to optimize its duration.

1 favorite thumb_down thumb_up 4 comments visibility_off  Remove from Watchlist visibility  Add to Watchlist

Outline/structure of the Session


Learning Outcome

To know about the Sprint Retrospective.

Target Audience

Agile Members

schedule Submitted 5 years ago

Comments Subscribe to Comments

comment Comment on this Submission
  • steve ropa
    By steve ropa  ~  5 years ago
    reply Reply

    I like Joel's idea here.  Maybe instead of several separate 20 minute experience reports, one longer one that shows how the various learnings combined to a greater effect?

  • Joel Tosi
    By Joel Tosi  ~  5 years ago
    reply Reply

    Hi Prashant,

       I had seen a few experience reports from John Deere - might it make sense to combine them all into one? 




  • Savita Pahuja
    By Savita Pahuja  ~  5 years ago
    reply Reply

    Hi Prashant

    Retro is always for the team and by the team. Scrum Master is a facilitator only. So I am not conviced with the last point regarding scrum master's consideration on retro points. Plus there are more than 100 ways already available to do retro.. whats unique in your session.



  • Sachin goel
    By Sachin goel  ~  5 years ago
    reply Reply

    Hi Prashant

    Retro is a key tool of Agile and being used in many ways. Having gone through the abstract, I am unable to assess whats the unique learning here? Some of the challenges you mentioned arounds teams, time, distributed locations seems quite common to me.

    Appreicate if you can summarise your key learnings and the uniqueness around it.



  • Liked Naresh Jain

    Naresh Jain - Scaling XP Practices inside your organization using Train-the-Trainer Model

    Naresh Jain
    Naresh Jain
    schedule 5 years ago
    Sold Out!
    90 Mins

    How do you effectively scale skill-based, quality training across your organization?

    Over the years, I've experimented with different ideas/models to scaling skill-based training across an organization. In the last 4 years, I've pretty much settled down on the following model. Its very useful when mentoring teams on skills like Test-Drive-Development (TDD), Behavior-Driven Development (BDD), Product Discovery, Writing User Stories, Evolutionary Design, Design Patterns, Problem Solving, etc. I've successfully implemented this model at some very prominent fortune 500 enterprises.

    The goal of this workshop is to explore what other successful models organized have used to scale skill-based training in their organization.

  • Dipesh Pala
    Dipesh Pala
    Agile Leader - Asia Pacific
    schedule 5 years ago
    Sold Out!
    90 Mins

    Breaking up User Stories can sometimes be as painful as a relationship break up - but it does not have to be like that!

    Our experience has shown us that the key to getting full benefit from introducing Agile is in how the project work is broken up. When it gets difficult to see how to write small enough user stories, teams often resort to technical story cards. While this can give the team visibility of the work that is being done, the business is not seeing potentially implementable product, or early delivery of business value.

    This talk will dig a lot deeper to expose the real reasons for splitting up user stories and not just talk about doing it as a good practice - we must BE Agile not just DO Agile!

    Using real-world examples, this talk will also offer a set of guidelines and some unconventional ways for breaking up larger chunks of work into valuable user stories that can help Agile teams become more successful.

  • Liked Shrawan Gaur

    Shrawan Gaur - Learn from Mistakes, Retain Your Strong Holds: Sprint Retro: Do As WE Do at John Deere

    45 Mins

    As the 12th Agile Principle states : "At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior accordingly.", it is quite easy to understand the importance of continuous evolvement which involves retaining learning and corrective actions.

    John Deere has started its Agile journey in year 2010 and since then has gone through various phases of transformation. Scrum teams has learnt alot and are continuously learning. Retrospection is one of very important scrum ceremony which paves path for team to advance in right direction.

    Here, I will demonstrate some retro techinques and its applications according to sprint work.