Scrum Project Management

Search this site
Process‎ > ‎

Sprint Retrospective

The Sprint Retrospective is held at the end of a Sprint in order to learn from the Sprint and not repeat mistakes.

 

 Purpose
  To learn what works and what does not work and make adjustments for the next Sprint.



 Roles  Primary Performer
  Secondary Performers
 Inputs  Mandatory:

  Optional:



 Main Description
 The Sprint Retrospective is time-boxed to 3-hours and is attended by the Scrum Team, the ScumMaster and optionally the Product Owner.
The Sprint Retrospective is intended to answer 2 fundamental questions:
  • What went well during the last Sprint that we continue doing?
  • What could we do differently to improve?
The meeting is usually facilitated by the ScrumMaster who will also take notes. The meeting must end with a list of action item that have been agreed upon and that will be implemented. Those changes may be added to the Product Backlog.
 Steps
  


 Key Practices
  
 Guidelines

Sprint Retrospective and the Agile Manifesto:

  1. Meeting Customer satisfaction: The Sprint Retrospective can be used to reflect on how well the Scrum Team is addressing the customer satisfaction.
  2. Welcoming Changing requirements: The Sprint Retrospective is a good venue to assess if the Product Backlog is evolving and therefore the Scrum Team and Product Owner are flexible enough.
  3. Delivering working software regularly: The result and feedback received during the Sprint Review can be analyzed during the Sprint Retrospective to assess this element.
  4. Working together: Reflection on how well the business and technical people are working together is a good activity to ensure that the environment fosters communication between those 2 groups.
  5. Giving support and trust: The Scrum Team can self-assess and also assess if management has provided an appropriate infrastructure.
  6. Fostering face-to-face conversation: The quality and frequency of the face-to-face conversation is a point that can be analyzed during a Sprint Review.
  7. Delivering working software: Assessing the quality of the key deliverable to date is of essential value.
  8. Having a sustainable structure: Signs that could conclude that the project is not sustainable must be discussed.
  9. Technical excellence: As for point 6, quality is a non-negotiable aspect of Scrum and should be reviewed during the Sprint Retrospective.
  10. Keeping the system simple: Signs of an unnecessary complex system should be discussed.
  11. Working in self-organizing team: Evidences that the Scrum Team is hindered because not self-managed should be analyzed.
  12. Regular reflection: The Scrum Retrospective being such activity, this will always be true!

 

 Concepts When the Scrum Team feels that the Sprint was not a success, it is recommended to invite an outsider/facilitator to help learn from the Sprint.
 Checklists