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.

Scrum at CNN

I found an article that documents the development change at News Network CNN from the waterfall method to Scrum.

The article documents the reasons on changing from Waterfall to Scrum, the challenges, the benefits and the outcomes.

Its surprising to me that CNN would use Scrum as I never really thought that they would have much development needs, but I suppose in the world of news where nothing stays still, Scrum would be suited as the possibility of having working software in a short space of time far outweigh the Waterfall method of having working software after a long wait.

Available for Download from the Scrum Alliance site.  Scrum at CNN

The Accidental Scrum.

I was flicking through the Scrum Alliance site when I found an article entitled “The Accidental Scrum”.  It was written by Royal Navy Logistics officer who was posted to a Ship that had to leave port sooner than expected.  He had to have the ship ready to leave port in 5 days time when origionally he had been given a few weeks to prepare.

He describes the common sense approach that he took to prepare the ship for deployment.  Coming from A software development background before being deployed to the Royal Navy, he knew nothing of Scrum and how it works.  It was not until later that he would find that the method he took to get his ship ready was infact Scrum.  He describes Scrum as a common sense approach, which when you think about it, scrum really is all about common sense.  He describes in basic terms how he tackled getting the ship ready for deployment in a short time using Scrum.

“Without knowing Scrum at all, I had set a sprint goal (“We have to be shippable, quite literally, in five days.”), developed the product & sprint backlogs (our deployment requirements and daily priorities), and established a daily scrum. I knew intuitively at the time that we had to come together at least daily to monitor progress and that any issues affecting the sprint goal had to be resolved by me, so that the team could be left to deliver. Now I understand that what I was doing was setting up daily scrums and acting as ScrumMaster for the team.”

This is an interesting article for me, as up until recently I have only been focusing on Scrum in a Software Development sense.  I think that when you look at Scrum as a bigger picture you begin to understand it more.

The Accidental Scrum

Terminating a Sprint

I have been researching the theory of terminating a Sprint. I have never encountered an occasion where I have had to terminate a Sprint, but I thought it was always good to research why Sprints would be terminated, and how the Team would deal with a Sprint Termination.

The Product Owner is the only member of the Team who can terminate a Sprint. Sprints can be cancelled before the allotted Sprint end date but it is often looked at as a worst case scenario. Sprints may be cancelled because of changes in business, competition or if the technology needed to carry out the work is not available. more often than not, the Sprint Scope is evaluated and adapted to meet the change encountered, rather than Terminating the Sprint.

If a Sprint is terminated before the sprint end date, the team must start the Process of starting a new iteration again. They must hold a new sprint planning meeting where the reason for terminating the Sprint is reviewed by the team and any outcomes from this meeting documented.

 The team will then start a new iteration as normal.

Retorspective Technique. Weather report

I have conducted a few retrospectives using the weather report as a sort of break in method to try and help the group engage with one another more and find out their mood.

I printed off some cards with some symbols printed on them to represent some weather patterns.  Sun, Sun / Cloud, Thunder and Rain. 

I then explained that these represented their mood for the past iteration. 

Sun = Brilliant

Sun / Cloud = Good

Rain = Bad

Thunder = Terrible

I then set out a Grid and split it into each of the sections above.  I then asked each Team Member to pick a card that represented their feelings about the last iteration.  This gave me a quick check of how the last iteration went.

You could practice this method often and keep a record of each Iteration and you could chart when the Team are happy or Sad 🙂

Here is the Technique explained.

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

I use it in iteration retros but could use it all kinds of retros

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

I use it in history, but could also use in readying.  I used it also as a short reflection on the retrospective itself.

3)  Use: 

Best suited for iteration retrospective for getting a sense of the mood the team is in.  I find it important to repeat this exercise on a regular basis, e.g. in every iteration retrospective.

Length of Time: 

For only getting a sense of the mood:  a couple of minutes, if you want to use it in the readying you might use this as a start for a discussion or other exercises.

Short Description: 

Every participant answers the question:  How was this past iteration for you?  The possible answers are: great (pure sunshine), good (sun half covered by a cloud), bad (rainy), miserable (thunder and lightning). The participants answer by placing a sticker in the area of their feeling.

Materials:  flipchart, marker, stickers


We capture the weather report every iteration and develop a team satisfaction thermometer from it.  At first it gives you a sense of where the team is currently.


You can use the weather report also as an opener for the history part.




Jutta Eckstein

Scrum From Hell

One of the areas a Scrum Master needs to practice is facilitating meetings.  I have found an exercise that can help train a Scrum Master in Facilitation.  One of the problems that I had when facilitating a Scrum meeting was being able to move the meeting on when appropriate.  I would let people ramble on and attempt to make their point, when it had no relevance to what we were talking about.  When I was able to move the meeting on when appropriate, the meeting progressed smoothly and finished on time.  When I couldnt progress, the meetings often over ran and often meant that some people couldnt have their say.

I hope there are some areas that this could help improve.

Goal: Practice managing a Scrum Meeting (or Standup Meeting in XP)

Time: 15-20 minutes.

This exercise is for a group of 6 to 8 participants who stand up, and some number of observers who may sit and watch.


§  Describe a Scrum meeting, so people understand the three questions and the flow of the meeting.

§  Describe common problems and interventions that address them. For example:

§  Implicit impediment: Listen to everything; sometimes someone mentions an impediment but doesn’t identify it as such.

§  Side discussion: ask people to listen when they are not speaking.

§  Rambling on: ask people to summarize more quickly.

§  Sidetracked meeting: ask people to have a meeting immediately afterwards for people who care about the topic.

§  Observer (“chicken”) who speaks: remind them that they’re an observer.

§  Late arrival: Charge them $1 if that’s what your team does; offer to fill them in after the meeting.

§  etc.


Prepare a set of cards, each with a secret goal.

Make twenty identical cards that say:

§  Answer the three questions.

The other ten cards should say (one each):

§  Only speak to or look at the ScrumMaster (ignoring everybody else unless you’re asked a direct question).

§  Arrive late.

§  Hidden impediment: Mention an impediment but don’t be obvious about it.

§  Noisy chicken: start by saying, “I’m only an observer” and then report on things the group doesn’t care about.

§  Silent chicken: as an observer, just say “pass” or “I’m just observing” when it’s your turn.

§  Ask a clarifying question on somebody else’s turn.

§  Ramble on until you’re asked to move on.

§  Try to sidetrack the meeting.

§  Try to solve somebody’s problem.

§  Start a side discussion.

Shuffle the cards together.


Have the group stand in a circle. Identify one person as the ScrumMaster.

Tell the group these three things:

1.      “I’d like you to imagine that you’re a member of a team developing an e-commerce site; take a moment to decide what you’ve been working on and how you’ll answer the three questions.”

2.      “I’m going to give each of you a secret goal; this card is for you only to see. During the scene, you’ll have this goal as hidden second agenda.”

3.      “If the ScrumMaster addresses your behavior, then don’t persist in it.”

Have the group do their standup meeting. Then debrief them.


“What behaviors did you see?”
This question is for participants and observers.

“How was it for you?”

“What insights do you have for the ScrumMaster?”
This question is for participants and observers.

“What does this tell you about the role of the ScrumMaster?”
This question is for anybody.

 “What will you do in the future?”
This question is for anybody.


§  You can vary the balance of “simple” vs. dysfunctional cards. (Try the exercise before you make it harder.)

§  You can repeat the article with different people acting as ScrumMaster.

§  You can do a large group “fishbowl” style, with the bulk of the group observing the team.

[William C. Wake, 2004. Developed for the Scrum Gathering in Denver, October, 2004. Thanks to the participants there for helping to improve it. Name changed 5-16-05; was originally “Second Agenda.”]

The Agile Manifesto

The Agile Manifesto is a statement of the principles that underpin agile software development.  The Manifesto was derived by representatives of various new methodologies such as Scrum and extreme programming where they saw the need for lightweight methodologies to replace the traditionally used heavy weight ones.

The 12 principles of the Agile Manifesto are:

Our highest priority is to satisfy the customer
through early and continuous delivery
of valuable software.

Welcome changing requirements, even late in
development. Agile processes harness change for
the customer’s competitive advantage.

Deliver working software frequently, from a
couple of weeks to a couple of months, with a
preference to the shorter timescale.

Business people and developers must work
together daily throughout the project.

Build projects around motivated individuals.
Give them the environment and support they need,
and trust them to get the job done.

The most efficient and effective method of
conveying information to and within a development
team is face-to-face conversation.

Working software is the primary measure of progress.

Agile processes promote sustainable development.
The sponsors, developers, and users should be able
to maintain a constant pace indefinitely.

Continuous attention to technical excellence
and good design enhances agility.

Simplicity–the art of maximizing the amount
of work not done–is essential.

The best architectures, requirements, and designs
emerge from self-organizing teams.

At regular intervals, the team reflects on how
to become more effective, then tunes and adjusts
its behavior accordingly.

I can relate to most of these manifesto rules by relating them to the way that we work today. We strive to keep the customer happy and we work together as a team to achieve this. We also look to release working software within a 2 week cycle which is also a marker for our progress. If you compare these to the way that you work using Scrum, you will see that you are following the agile manifesto.

The Product Backlog

The Product Backlog is like a a wish list of requirements.  The Backlog is like a living list that is always changing as stories are added, prioritized and deprioritized daily.  It is the Product Owners job to keep the Product Backlog Items prioritized and constantly groomed to to allow maximum efficiency.

Not only is prioritization essential but story quality is essential too.  Stories that are well defined will be prioritized towards the top of the backlog.  Stories that are cumbersome and undefined will be held at the bottom of the backlog awaiting breakdown.

If we look at the Backlog as being an ice berg.  We all know that the largest part of the ice berg is under the water and the smallest part of the ice berg is above the water.  We can compare this to our Product Backlog.  Our largest stories are at the bottom and are therefor under the water line and are unable to be worked on.  The Smaller stories are above the waterline and are able to be broken down and worked on.  Once these smaller stories are completed, more work is brought up from the list, just like an ice berg!

In general, the product backlog is the ‘What’ of the system.  They are the functional requirements, non functional requirements and issues which are prioritized in order of importance to the business and then estimated.  It is important that the Product Backlog is prioritized and kept up to date frequently by the Product Owner to reflect any changes in business priority effectively.


Daily Scrum Mistakes.

After researching techniques that would improve my Daily Scrum.  I thought I would highlight some mistakes that can occur within a Daily Scrum Meeting that you can further improve to make your Daily Scrum more appealing.

I read an article on “Scrum from the Trenches” Daily Scrum Mistakes  that echo’s some of the sentiments felt by myself.

The first mistake that people often make are to over run the allocated 15 minutes.  This can cause people to lose focus on what the Daily Scrum meeting is truly about.

The second mistake that people make, and I myself allow this to happen on occasion, is that Team members are effectively Reporting Status to the Scrum master.  Many people look at the Scrum Master whilst giving their status rather than giving a status report to the whole team.  I try to not make eye contact with the person speaking as to avoid it being a status update aimed at myself, rather than to the whole team.  The Scrum Master is part of the team and holds no managerial authority, so therefore a status update should be aimed at the whole team and not just the Scrum master in general. 

Leading back to my first point about the allocated 15 minutes. Remember the Daily Scrum is a status meeting.  It is very easy for a Daily Scrum to become a design meeting when one person is describing difficulties that they are having.  The Scrum Master has to be aware of this and limit technical and design discussions.  encourage Team Members to take their discussions “offline” and discuss the possible solutions after the Daily Scrum. 

The best possible way to conduct the Daily Scrum is to have the attendees standing up.  If the Team are sitting down, they become more formalized and meetings tend to run over.  If the Team are standing the meeting becomes more efficient due to people wanting to have the meeting done and dusted quickly so that they can sit down again! 

One problem that I had in the past with my team was that we were always being drawn into design and technical meetings in our Daily Scrum.  The Scrum Master must be firm on this.  I see myself as a nice guy, but at the beginning I was too nice for my own good.  I was worried that continually interrupting these meetings, would see me as being labeled rude.  But I soon realised that the team were labeling the meetings as laborious as they continually over ran.  So therefore I had to step in and limit the design and technical discussions until after the meeting.

we now have a designated time where we allow converse with interested parties after the Scrum meeting where Team Members can gain clarification on requirements of discuss problems with other team members.  I would say that this has improved our efficiency overall as the Daily Scrum is useful again and not laborious.