The Sprint Retrospective Process

Print Friendly, PDF & Email

Featured Sprint Retrospective

Wisdom from Agile Sprint Knowledge

Life experiences creates lots of Data.

Wisdom Triangle

Click the Image for the Wisdom Triangle

Experiences we have everyday generates warehouses of Data in our mind.

Our five senses records our experiences as life Data that is stored as Raw Information that aids in all the decisions we make in our everyday lives.

We Use Related Information 

… To Aggregate Analytical Conclusions

…… That We Call Knowledge

Collections of Related Knowledge is then used for some Real World Activity.

When Real World Activities produce a successful quantifiable result we have gained Wisdom.

Both successful and less than successful results generate more Data for our minds to store in our warehouses as New Information and the cycle repeats as long as we are breathing.

The TMD Sprint Wisdom Triangle defines Wisdom as:

Sprint Iteration Experiences Acquired from

… Successful Implementation of Acquired

…… Knowledge during a Task Development

The Sprint Retrospective Process creates Sprint Wisdom from the current Sprint iteration.

By organizing the Sprint Raw Data, Processed Information and Related Knowledge we can create reusable Wisdom that will improve the results of future Sprint iterations.

The TMD Sprint Retrospective Process

The goal of the Agile framework methodology is to deliver functioning product to the Business Team during the Release phase of each Sprint.

The methodology also requires that the Agile Teams support the Scrum Team’s ability to improve through wisdom gained by each completed Sprint.

This goal is facilitated by the Sprint Retrospective Process.

This process should be customized for the culture and constraints of each engagement.

The Purpose of a Sprint Retrospective is to

… Archive Wisdom based on the Knowledge Gained

…… By the Strengths and Weaknesses of the Evaluated Sprint

The Sprint Retrospective Session

After each Sprint, the Scrum Master facilitates the Sprint Retrospective.

The TMD Agile Sprint process schedules this on the Wednesday of the first week of the next Sprint.

A Sprint Retrospective is attended by the Scrum team:

  1. The Business Team Representative

  2. The Architect Team

  3. The Development Team

  4. The QA Team Representative

  5. The Network Infrastructure Team Representative

The Sprint Retrospective Session is structured to take two hours.

This session is designed into the Development Capacity Planning Process.

Mag Glass ManThe Sprint Retrospective is held after the scheduled Sprint Release Product Demonstration which is scheduled for the Tuesday after the completed of the “Sprint Under Review”.

The Sprint Release Product is scheduled for the Monday, the first day of the new Sprint.

The TMD Agile Sprint Retrospective uses a modified version of the Effective Sprint Retrospective process from VERSONONE as the format structure for the Sprint information gathering process.

There are five areas in this process and each have a fixed time limit to ensure that the session only takes two hours.

The Lexicon Master documents the Information gathered for the final phase of the structured session.

The TMD Sprint Retrospective Session Agenda

The details for the session are defined below for the five areas of the Effective Sprint Retrospective 

+Effective Sprint Retrospective
  1. What Worked Well – These are items that will be carried on to the next Sprint as “Wisdom Gained”
    1. Action: Documented consensus on the top three factors that worked well
    2. Time: Fifteen Minutes maximum
  2. What Was Problematic – These are items will be corrected or removed from the process
    1. Action: Documented consensus on the top three problem areas. The team engages in meaningful discussions and creates specific actionable items.  Do Not Play the “Blame Game”.  Actions are documented and become the responsibility of the Scum Master to take the appropriate corrective measures.
    2. Time: Fifteen Minutes maximum
  3. Review the Sprint Metrics – Understanding Key Statistics of the sprint just completed
    1. Actions:
      1. Discuss Velocity: Planned Story Points versus Completed Story Points
        1. Discuss Plan: Constructive discussion of any issues that prevented successful completion of a Story Point
        2. Document Findings: Summary of the discussions
      2. Discuss Team Capacity: Review the resource hours assigned
        1. Discuss Capacity Assignments: Were the assignments realistic?
        2. Document Findings: Summary of the discussions
      3. Discuss Effective Effort: Review the expectations Backlog reduction versus the actual Backlog results
        1. Discuss Estimated versus Actual: Was the resulting Increment statistic satisfactory to the team?
        2. Document Findings: Summary of the discussions
      4. Discuss Any Scope Changes: Assess the effect any scope changes  
        1. Discuss the Iteration Scope: Did changes during the Sprint adversely affect the success of the Sprint?
        2. Document Findings: Summary of the discussions
      5. Discuss Burn Chart: Review the Burn-up chart  
        1. Discuss the Iteration Progress: What issues affected the Burn rate if not already discussed?
        2. Document Findings: Summary of the discussions
      6. Discuss Impediments: Top 3 major impediments or impediment patterns
        1. Discuss Impediments: What are the top obstacles, weaknesses or repeated problematic behavior?
        2. Document Findings: Summary of the discussions
    2. Time: Thirty Minutes maximum
  4. Develop a S.M.A.R.T. Plan – The action plan to improve the Agile Sprint process
    1. Actions:
      1. Specific: Discuss User Story Point Designs
        1. Discuss Designs: Were the Designs adequate for understanding the expectations for development? Where any Blocks caused by vague or missing requirements?
        2. Document Findings: Summary of the discussions
      2. Measurable: Discuss Task Hours Assignments
        1. Discuss Story Points to Development Task Process: Were defined task effort understandable and estimated in realistic terms for the assigned developers skill set and experience?
        2. Document Findings: Summary of the discussions
      3. Achievable: Discuss Daily Development environment
        1. Developer Team Discussion: Did the developers feel comfortable in the expectation of their daily success?
        2. Document Findings: Summary of the discussions
      4. Realistic: Discuss the Daily Development pressures
        1. Developer Team Discussion: Did the developers feel pressured or behind in their assigned tasks due to unrealistic expectations?
        2. Document Findings: Summary of the discussions
      5. Time-bound: Discuss the expectations of Story Point delivery
        1. Sprint Team Discussion: Did the Sprint Team feel pressured or behind in due to unrealistic expectations of User Story delivery? Were the Stories chosen realistic for the Sprint capacity?
        2. Document Findings: Summary of the discussions
    2. Time: Forty Five Minutes maximum
  5. Sprint Retrospective Recap – Summation and documentation of the previous 105 minutes
    1. Action: Documented results and actions in the Sprint Retrospective Agile Tool
    2. Time: Fifteen Minutes maximum

In Conclusion

The success criteria of the Sprint Retrospective session is to gain Wisdom from the enormous amount of Sprint Data that has been collected as iteration Raw Information and processed during the Sprint Retrospective Process as Agile Sprint Related Knowledge.

The Sprint Retrospective Process only benefits from the TMD Wisdom Triangle when the team communicates freely, honestly and without fear of reprisal from other team members for their ideas and opinions.

Wisdom Pearl # 103 – Managing Technology Results

If You Can’t Measure It … You Can’t Manage It

… Create Ways to Quantify Your Results

Follow-up Content Recommendation …

Some content presented within this post can be found in a very good book on Sprint Retrospective by Luis Gonçalves and Ben Linders:

Getting Value out of Agile Retrospectives – A Toobox of Retrospective Exercises

With plenty of exercises for your personal retrospective toolbox, Getting Value out of Agile Retrospectives will help you to become more proficient in doing retrospectives and to get more out of them.

The following two tabs change content below.
Brad Huett
My Twitter profile

Brad Huett

I am a Principal Architect at Liquid Hub in the Philadelphia area specializing in Agile Practices as a Certified Scrum Master (CSM). I use Test Driven Development (TDD) and Acceptance Test Driven Development (ATDD) with Behavior Driven Development (BDD) as my bridge to Agile User Stories Acceptance Criteria in a Domain Driven Design (DDD) implementing true RESTful services
Brad Huett
My Twitter profile

Latest posts by Brad Huett (see all)

If you think this post was worth your time: Like It Please

2 Comments to “The Sprint Retrospective Process”

  1. Sonny Veiga says:
    January 8, 2014 at 2:27 PM

    Although this is what “Good looks like” for sprint retro, I have yet to work for a company that is following agile and it making good use of sprint retro.

    In all my 8+yrs working in Agile, the scrum master would organize the sprint retro and everyone will participate on what went well and what didn’t and what we need to do to improve on the items that didn’t go well etc ect but once retro is done, everything is forgotten. Retro is currently being used as a place to vent.

    It’s a challenge to turn items in retro into action items because it will affect the sprint backlog. Whatever is in the sprint backlog will always be prioritized higher than any items that need to be worked on from retro so trying to convince the business that we can’t do a user story because we need reject all user stories that don’t have requirements ( a retro item) would most likely be ignored.

    • Brad Huett Brad Huett says:
      January 11, 2014 at 4:56 AM

      Sonny,

      Thanks for your thoughtful insight.

      I agree with you completely on the “Venting”. My experience is that most of the time “Agile” is a word that is used but not a mindset that is the driving motivation for success.

      It is difficult to get a collection of people, with different experiences, together and work with the “One Team” philosophy that the Agile development methodology and Scrum Sprints require for true success.

      The main purpose of this post‘s intent is to offer a solution to the very real issue you presented. By creating a “Time Boxed” process that creates real usable outcomes, as defined by the S.M.A.R.T. concept, with emphases on “Achievable” and “Realistic”.

      The major “Venting” is generally a lack of usable requirements for development and testing. The detail is generally missing and the acceptance criteria are vague.

      A failed User Story should never be a “Retro Item”.

      The commitment to solve the flawed process that created the failed User Story should be the take away from the session: Cause versus Effect.

      All this is much easier to write about than actually solve in practice. It requires a team that has truly made the paradigm shift from Waterfall, and all its build-in failure protection, to the Agile philosophy of self-organization and accountability.

      Thanks again sir for taking the time to post what all of us using Agile have experienced more than we would ever like to admit.

%d bloggers like this: