Retrospective Technique: Playtime

Title:  ‘Play’ with iteration products to remember what happened during the whole project


1) What kind of retro is it best suited for?

    Milestone, End of Project

2) What phase of the retro would you use it in?

    readying, present, future

3) Purpose

    If the software product has been developed iteratively, then each

    iteration (or release) is supposed to have at least partially working

    version of a product. During the readying of the retrospective it is

    good to consider, if these products could be used during the actual

    retrospective workshop.

Length of Time:

    5-15 minutes to allow brief playing or usage of each iteration’s software product(s).

Short Description:

    Playing or using each iteration’s product briefly before other retrospective exercise such as building part of a timeline makes it easier for participants to remember their significant tasks and other issues of a certain project phase than it would be without these artefacts.


    At least one computer (and possibly a video projector, if the group has more than 3 people), and each “iteration release” of the product.


    Especially in the case of reviewing longer periods of time (more than 6 months) it may be necessary to bring along some of the iteration products to get the discussions “flowing” naturally. If the various releases of the products can be used briefly and the retrospective’s time limit allows “playing with iteration  products” before more detailed discussion about the team’s learning related to certain period of time, then use those.


    Instead of working software some other concrete artefact such as iterations evolving paper prototypes, ER-diagrams etc. could be used, if the project has more systems design and development than only software development.

Resources: None.

Source: Mauri Myllyaho

I find this techique interesting as sometimes I feel that the Team can often forget some contributons that were to the iteration.  Playing with the product can often bring out these small reas and any conflict, improvements and impediments that may have occured during the sprint but were forgotten about at the retrospective.


A retrospective is held at the end of an iteration.  The Scrum Master will invite all members of the team (Product Owner, developers, QA etc) to a meeting to dicuss the successes and failures of the sprint.

Each member will discuss what went well and what did not go well in the Sprint that they have just undertaken.  These are then discussed by the team and any measures to make improvements on the failings of the sprint are discussed.  It is planned that the improvements will be implimented to make the sprint run smoother next time.

One main fear of mine is that Team members will see a retrospective as a negative thing.  A meeting that only the negatives are drawn and a place where people can vent their frustrations and blame onto other Team members.  This is not the case, the retrospective should be treated as a positive thing that will help the team by not only recognising the good areas within the team, but will aim to improve the negative areas rather than dwell on them.

I read an interesting article below which is based here:Retrospective Prime Directive

“One of the most obvious fears people have when first trying a retrospective is that the ritual will become a negative gripe session, interspersed with blame and counter blame.

Clearly such an event will not contribute to much learning.

The key to a constructive successful ritual is assuring that all the participants adhere to the Retrospective Prime Directive.

 The Prime Directive says:  Regardless of what we discover, we understand and truly believe that everyone did the best job that they could given what they knew at the time, their skills and abilities, the resource available and the situation at hand.

At the end of a project everyone knows so much more.  Naturally we will discover decisions and actions we wish we could do over.  This is wisdom to be celebrated, not judgement used to embarrass.”

The Retrospective Prime Directive is a good guide to follow. Working as part of a team means that you must trust and believe in your team mates abilities and that they will always give 100% to you and the work that they carry out. It is not fair to single out one member of the team to criticise and embarrass but try to think of ways to improve the team as a whole whether that be through reviewing actions and decisions we know we will be able to improve on should the same scenario arise again. This will make you stronger and more effective as a team.