The retrospective timeline is a useful exercise for gaining a better understanding and a richer context for a particular retrospective. This means that this exercise becomes less useful when you do retrospectives more frequently and especially useful when doing a retrospective spanning longer periods or you run retrospectives less frequently.

Goals
The timeline aims to give a very visual overview of the events that occurred during the period for which you are doing the retrospective. The facilitator should use distinct and bold colours to identify distinct events so that it is easier to interpret the results. The timeline is a great way of determining trends over time for periods in the project and a useful mechanism for getting a feel for how the team felt throughout the course of the project.

When To Use It
As mentioned earlier, the timeline retrospective is useful for refreshing the memories of participants and you might find it useful in the following circumstances:

• For projects that are run without any intermediate retrospectives
• For projects that require more formalised processes (i.e. not necessarily uber-agile)
• If you need to communicate a more complete perspective for outside parties that may require reporting to
• If all participants did not necessarily work on the project during the entirety of the project (people rolling on or rolling off)
• The end of a project retrospective

The Fundamentals (Part One)
There are two major parts to this exercise. The first is noting all the events. Make sure that everyone has access to different coloured pieces of paper where:

• Green represents good events
• Yellow represents significant or memorable events
• Orange represents problematic events

The types of events that you might want to consider suggesting include things like when people rolled on or off projects, when things kicked off, when someone in the business made a decision that affected the team in a great way, when the team did achieved something really amazing, etc.

Get everyone to scribble each event down on separate pieces of paper and then get them to tack it along a standard timeline along a whiteboard or several sheets of paper stuck to the wall. This is where sticky notes or lots of blu-tack helps. It should look something like the following:

It is a good idea for you to get everyone to explain events, especially if the participants may not have full knowledge of what was going on. The significant events help to put things into context and might answer a few of the puzzling questions some people might have about the project, and the good points help to identify strengths while the problematic points should lead you to discussing action items. I find this exercise is most useful for first putting context for a retrospective spanning a large time and then using other exercises to draw out further conclusions. It is a good mechanism just to get the discussions flowing within the team and allows the facilitator to try to put different perspectives on things.

The Fundamentals (Part Two)
The reason you want to reserve some space underneath the timeline is for the second part of this exercise. In this part, you split the remaining area into two sections where you get the team to fill in how they felt about each event or how they felt in general for that period. You can try to limit them by getting them to put three dots per significant period (week/month) or perhaps one per event posted, with the idea that you want to get a general feeling for the overall morale of the team. You should end up with a scattergram that looks like the following:

Once the team has finished plotting all their points, you can then try to draw a trend through them that helps to establish a real idea of how the project went such as below:

Trawling The Timeline
The visual nature of the timeline allows you to easily draw out a number of trends from the project. Large concentrations of a particular colour may attract your attention to a certain period and it would be worthwhile trying to pinpoint its underlying cause so you can attempt to replicate (or avoid) the same circumstances in the future. The general trend at the bottom may or may not coincide with the events above the line so there might be another discussion point for explaining why morale might be low even though there might be lots of green or why it is high even though there were problematic events (maybe it was a good team building experience or people were growing and learning).

Diagrams are always useful focal points for starting discussions, and that’s one reason I like using the starfish diagram for a retrospective. This particular retrospective technique helps people by getting them to reflect on varying degrees of things that they want to bring up, without having it fit into the black or white category of ‘What Went Well’ or ‘Not So Well’ so I think it scales a little bit better.

A little bit about each category:

• Keep Doing – Is a good starting point for team members to focus on typically all the good things that they liked about a project. You might want to encourage people to think about things in terms of, what would they miss if they didn’t have a particular practice, technique, technology, person, role, etc. A good example from a real session I’ve been in before is ‘Running performance benchmarking and tuning during an iteration helps to identify regressions or slowdowns so we can address them earlier’.
• Less Of – Helps to focus on practices that might need a bit more refining or that were simply not helpful in the current circumstance. Perhaps they add value but not as much as other practices could. An example here is that perhaps stand ups have become status meetings and so there should less of talking to one person (and more of talking to each other) during them.
• More Of – Is another type of focus that helps further refine or highlight practices, technologies, etc that team members might want to try more and are not necessarily taking full advantage of. A good example is that maybe people are pair programming but knowledge transfer and a better understanding of the code changing might be gained by doing more of swapping programming partners.
• Stop Doing – Obviously for things that are not very helpful to development practices or not adding much value. Perhaps it’s about writing that status reporting email at the end of the day (because you can substitute a simple one minute conversation for it instead)
• Start Doing – Is a great opportunity for team members to suggest new things to try because of things that may not have gone so well or just for simply keeping things dynamic and fun. Perhaps you might want to try a burn up chart on the whiteboard or try some new open source tool for helping improve developer productivity.

Interpreting the Starfish
Getting people to either write things up under the starfish in this manner gives you a scattergram of sorts and is a great visual technique of estimating the overall health of your project. Most of the points on the starfish also try to coerce people into actually creating action items instead of simply saying that something was not good.