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.

Published by The Daily Scrum

A CSP, CSM, CSPO who lives and works in Glasgow, UK.

%d bloggers like this: