Maturity measured by Retrospectives

Having built up a wide range of retrospectives I can't help but notice the changes teams go through as they mature in their practices.

If you think about it, if we are continually improving our delivery of software then it follows that our retrospectives will start to look and feel different as we focus on different problems.

1) Stop, I want to get off! - I think the first stage after the euphoria and excitement of moving to an agile process, is to winge. The complaints come thick and fast and it's usually everyone else's problem. It is cathartic but does not really move things forwards. Actions are probably difficult to get. The core problem is that the team don't want to own the process - they have been used to someone else owning it and have not accepted responsibility for it (or have not been allowed to)

2) Own it - Eventually, the team accept that although there are wider problems they own a lot more than they thought they did. I use the 'Perfect Sprint' retro to reset this - showing the team that their perfect sprint is largely in their control helps us get there. They start to come up with actions that they can do but these tend to be poorly managed. The team are still not clear that they own the process and it's still someone else's fault if it isn't working for them.

3) Going through the motions - It's easy coming up with ideas but putting them into action is another problem. The team essentially go through the motions, generate actions but don't have the guts or inclination to go through with them even if they are great ideas. If nothing is done about the actions then there is little point in the retro itself. The core problem is that carrying out actions requires a change in behviour, specifically it means the team need to take responsibility for their process. They realise they own it but changing it might still seem scary or too much work.

4) This is boring :( - To me, this is symptom of the process being OK and working for the team. The actions from the sprints might be predictable and may be difficult to implement since there is nothing much they want to improve when they look at the whole process. It feels boring to the team since everything is OK and the improvements are not immediately obvious or even with the process itself, which has been the primary focus up until now. Actions are pretty well managed by they might look and feel 'samey'.

5) Dive, Dive, Dive! - This is where we look at very specific areas rather than the process. Maybe this is a specific story or problem that the team have encountered. I have looked at metrics, team values, customers and suppliers and other focused topics. These focused retrospectives usually result in actions that are more difficult to put into action e.g. influencing other members of the organisation and usually take longer to carry out. The team will usually be good at keeping track of actions at this point and holding themselves to account.

6) Can we do that? - The team are creating actions and the scope of those actions is growing into a space where they are questioning what they can change. The team starts to ask to own more from its stakeholders and possibly changing the status quo.

7) Hands off - For me the last stage of this process is when the team own the retrospectives too. They see value in the ceremony and are disciplined in keeping track of and carrying out the actions they come up with. They challenge and support each other in carrying out actions and ask for help or advice if they need it.

This is not a sequential process and regressions are common. These are the stages I have seen and think about when working with a team - the goal being for them to own their process and it's evolution whilst honest enough to ask for help if they need it.

Retrospective: Health Check Retro

Across the organisation I work with, we do a quarterly health check which is very much stolen from the excellent work Spotify did way back in 2014.

One of the problems our community of practice brought up was follow up by the teams themselves. We did this which gave the organisation this fantastic view of how we feel about the teams we work in but the teams never used the same information to improve. Odd right?

I was guilty of this and so I decided to have a retro to focus on improvements the team wanted to make before the next health check.

The setup for this retro was to get the team to vote on the areas which they wanted to see the most improvement in. This was a really quick dot voting exercise at the end of a stand up.

In the retro itself, these are the focus areas. We kick off by asking the team to list the problems they see in each of these areas. I like time boxes and gave them a whopping 7 minutes to pull these thoughts out into a flurry of post its.

I now pick on someone in the team to group the post it so we can see some themes. This is often the person who has used their phone the most or failing that a BA (since they usually have a knack for seeing some groups).

Next, we focus on just a few problem areas by dot voting. Getting them to list the problems means I can now complete the setup and ask them to find solutions for the problems we came up with, again giving them an aggressive time box to work to.

We now go through everything we have come up with, clarifying anything that is abstract (there are always a few) and asking some questions to get people thinking about what they are trying to solve:

How does this help solve the problem?
How is this related to the problem?
If you did this, what do you hope to fix?
Will this fix the whole problem?
What else might be have to do to fix the problem?

This bit is to clarify what everyone has come up with, which is important since we are going to ask people to own these.

The last part of this is the ask people to come up and choose 2 solutions. One that they put into practice this iteration and another one which is longer term. If people look like they lack enthusiasm, point out that the first people get to cherry pick the best things.... that usually helps.

They each read out what they chose for this iteration and talk about what they intend to do. We can keep on top of these in stand ups, asking what help we need to give to keep up the momentum.

Their homework is to think about how they will bring their other longer term task into action and what help they will need, which we will discuss in the next retro.

Retrospective: Protest!

This is my new favourite retrospective.

Emotive and simple, it encourages members of the team to voice their concerns and create a protest.

Literally.

The format is very simple. Use the PowerPoint deck to show some examples of signs from protest and then get each member of the team to come up with a protest of their own along with a sign that would explain it.

I have been curating signs from protests for a while on Pinterest. I would give the link but they contain a wide range of swearing so it does not feel 'cool' to include the link here. Contact me if you want me to share the board privately.

You can then talk about each person's 'movement':

• What's the cause?
• Who is the audience?
• Who are your followers?
• What's your ideal solution?

This is more of a way to get the team to open up about issues they feel strongly about. These might not have been addressed so this gives a direct way of the team telling you what their cause is - without having to start a real protest!

View the Protest PowerPoint

Remembering past last week

We know from experience that people often have very short memories when they participate in a retro.

It is no surprise that we only usually get the problems from the end of the sprint since this is often where the pressure is. Any good things are usually drowned out by the tide of problems we discovered yesterday.

So imagine my delight at taking people back over 6 months. And not just one team - a whole bunch of teams all working on the 'Consents' programme of work which basically made our company GDPR compliant.

So here is the method I used, which worked nicely and created some good conversations and insights for the people who participated.

We first set a homework task. This is essentially the ice breaker but served a purpose too. The team were asked to bring a picture that represented the project at the beginning and one that represented the project now.

The idea is to get people to think back to the beginning. I was conscious that different people got involved at different times and that is fine. We just wanted them to take the time to think back right to the beginning to break the cycle of only remembering the last things.

I drew a timeline which represented the project from beginning to end and got people to show the pictures they chose and explain why e.g.

A picture of the lone ranger herding some cats was because that person really didn't know how to go about this project at the start, they chose a cover of George Orwell's '1984' to explain that during the project he became much more data security aware and by the end it was something he was seeking out since he was interested in it.

We heard several stories which started with this very simple beginning and end. You don't need everyone to do this (they won't) but a couple set the scene. This is usually funny and often thought provoking - I have used this as the basis for a team retro too.

Next we add some points on the timeline to give some scale. For us, we added some key sale periods  and Christmas. It will always be terribly inaccurate, you just need enough to make sense of the timescale as a whole.

With about 20 people in the room, you will generate a LOT of data. The trick is to find a way of bringing out trends. Grouping will take too long so I use a colour key and an additional dimension to allow the group to talk about what happened.

With this group, we gave them different coloured post-its depending on their role in the project, there were 4 in total. The dimension we added was good/bad - if the thing they are remembering was good then place it above the timeline, the opposite for bad. The further it is away from the timeline, the more pronounced that is.

I then gave the group 7 minutes to go post-it crazy and place these insights on the timeline. I can be messy and little loud but it's only for 7 minutes!

Once finished we asked them to look at what they had created:

Next, we ask them to look for some trends:

* On balance, which group of people had the most insights? Who had the least?
* On balance, was this a positive experience or a negative one?
* Was there a specific part of the project where something was wrong? What happened?
* Which part of the project was busiest and why?
* What happened here? (point to a cluster or peak)
* Was this the best thing that happened? (point to top post it) Why?
* Was this this the worst thing that happened? (point to bottom post it) Why?

For the most prominent groups, we asked them to tell their story from beginning to end. This is often lead by and individual but they speak for a group since people tend to work together to remember what happened.

People add insights from their own perspective as each of these is told. Over half the session is just this. As a facilitator, you can ask open questions and maybe pull in individuals who aren't speaking or look like they want to but cannot break into the dialog.

At this point we collecting data, sharing perspectives. I usually ask for the high and low point from each of the story tellers, which can break them out of concentrating on a single time period. You can pull out specific cards from the wall if there are interesting ones but the purpose is not to use that data - it is just a vehicle to get people to think across the whole timeline and highlight areas that might be interesting to talk about.

To close, we want some canned insight that we can learn from. To do this I pose the question:

If you were on another project and you were working with some new people, what advice would you give them? If you could hand them a piece of paper that would help them, what would it say? What mistakes would you want people to steer clear of and what inspiration could you give based on what we have found out today?

The output is a single statement from each person. We grouped these into themes that allowed us to see where there was consensus in their experience even though their involvement and roles in the programme were completely different. As people left, we asked them to vote for their favourites and encouraged them to use this insight to improve the next programme they were involved in. We share the favourites with the more senior management and try to steer the structure of work at a higher level based on this feedback, hopefully improving each one as we go.

Retrospective: The End

People leave. Occasionally, this will be the SM. This retro is dealing with the handover to the next SM and acting as a exit interview for the SM.

The goal behind this is to give the new SM insight into how the team regard their process, what they need help with and most importantly what they want to keep. This was to give my new SM a good idea of what the teams buttons where so he would get off to a flying start with the team.

It also helped me see some improvements that I could carry with me to my next team. Some I knew about some I needed to acknowledge. SM's, like teams aim to continuously improve.

The icebreaker I used was a simple game where I wrote up some numbers and asked the team what they thought they correlated to. I went back to when this team formed and found totals for: Number of Sprints, Total number of stories, Total number of points, Longest Lead time and average velocity.

Then we did a happiness radar to give the overview of what the team think about 3 areas:

• People - the people they work with both in and out of the team
• Technology - the kit they work with on their local, development and integration environments
• Process - the way they work

I gave my team 2 votes each and they created this:

Thinking like my new SM, I would be thinking "Hmm, I wonder what's up with the technology?" and maybe "So, observe for a while since these guys think everything is working just fine".

The last section was just a post it session around some key questions:

• What should the SM leave alone?
• Is there something the new SM should look into straight away?
• What are our strengths?
• What does Richard do that our new SM should do too?

As usual, it's the little things that made me chuckle - biscuits, always a favorite:

When the SM arrived I went through what the team had said and gave them a rough history of the team so he had some context. Not only did I find this process quite therapeutic, I think it helped the team know that the next SM would help them continue on their chosen path rather than make them take a different route.

Now that's what I call a plan.

Creating a bunch of stickies never felt like a satisfactory result from planning. This is a reflection on the progress made by one team to create a real plan of how to convert story into software.

Stage 1 - Creating tasks without conversation

The team's planning session creates stickies for various tasks that we need to develop the feature. This is led by only a few of the developers and it is almost entirely directed by them. The stickies represent pretty big elements of work and the estimates are pretty high - most are over a day in length. There are very few testing tasks, which are created by the QA guy only.

Observations:

• The team aren't thinking how to do this work - someone else has decided and are dictating the tasks as they see them
• The tasks are not very granular so detail is being missed and the resulting estimate is not very accurate
• The team is not owning the QA - they are creating 2 teams which might not join up to deliver the work

Stage 2 - Experimenting with Diverge and Merge

A recommendation from our Agile Coach gets the team using Diverge and Merge to create tasks. The whole team creates tasks in parallel and then they merge their stickies. This breaks the dependency on individuals leading and makes everyone think about what needs to be done. Merging creates conversation as some people think of things that others haven't and we all reach agreement where we have the same tasks. To make this work, it is need to follow the work through sequentially. You can optionally play a game to see who keeps the most stickies on the board, which keeps the session flowing.

Observations:

• The team don't really buy into Diverge and Merge but the sequential story of what needs to be done makes sense to them
• Involving more of the team means we have less direction from individuals - there is more ownership from the team rather than following individuals
• QA still a secondary process within the team
• Tasks are still quite large

Stage 3 - Creating tasks sequentially

SM encourages the team to explore how to do the work sequentially, encouraging quieter members of the team to contribute. Larger tasks are broken down and things we often forget also take time are included like documentation, deployment packages, merges. The QA guy is still doing the same thing but SM asks them to explain the approach to the team, which does not result in a lot of feedback.

Observations:

• Following a linear path through the tasks makes it easier for the SM to pull developers into the conversation
• The larger tasks were hiding detail that we need to discuss in order to estimate - breaking them down helps reveal these
• Asking the QA guy to explain the testing approach helps to breakdown the 'us' and 'them' - it introduces the notion that the whole team should understand testing, led by QA

Stage 4 - Team ownership of Quality

We start the planning by talking about testing not development, which was an action raised in a retro. The team create a basic test plan and everyone estimates the test tasks. There are clear gaps in knowledge as estimates are wildly different - team estimates and indicates which tasks need pairing for knowledge transfer.

Observations:

• Talking about testing first influences the order they develop in, so the tasks are a little different.
• The testing plan being known by the team means they can shift between development and testing tasks - this gives the team more options as to how they deliver the work during the sprint
• The knowledge sharing is clear and improvements are found easily as a part of the process - no retro needed for this one

Stage 5 - Team collaborates on an approach

The team realise some stories need more thought. If left to the sprint, these decisions need to be made by a single developer rather then by using the wholes teams skills. A retro action is to use a whiteboard session to discuss the approach before a story is started. The sessions visually describe the areas of the system making it easier to spot difficulties or additional tasks that might be missed with conversation alone.

Observations:

• Pictures work better and getting people to explain using the diagram helps too
• This is very Just-in-Time - is there an earlier opportunity for this?
• Some areas of discussion maybe go too deep - the team sometimes dive a little too deep into implementation.
• A retro action from the team empowers them to huddle if they need team ideas/consensus - this helps counter only one or two developers deciding things without anyone else knowing

Stage 6 - Planning using a whiteboard

The team move the whiteboard session to planning and then decorate the system areas using tasks as they follow the development sequentially. The team discuss testing as a part of the conversation, making testing more integrated into the development. By grouping the stickies to areas of the system, they are able to see how many of them could work on the story at the same time.

Observations:

• The combination of a picture and sequentially discussing the development works nicely - it helps expose tasks the team has frequently missed
• The team is starting to think more about how the tasks could be done in parallel by picturing areas they can work on without tripping over each other
• Testing tasks are easier to spot - impacts on existing tests are highlighted quickly

This journey took quite a few sprints. There were regressions as well as advances but when I look back I saw these stages of development. The retrospectives drove many of the changes but we also saw spontaneous creativity - using the whiteboard sessions to plan against, is a good example.

The key thing I saw from the team was a shift in focus. Instead of planning how to do the development, they are now thinking about how to deliver the story. This goes further than a list things to do - it should aim to answer the questions:

• What order is best to do these tasks in?
• Who has specialist knowledge that we need to leverage?
• What does testing look like for this story?
• How can everybody assist with testing?
• How can we get everybody working on the same story?
• What do we need to knowledge share on for the future?
• What does the final solution to this look like?
• What are the 'risky' tasks?
• Who else might we need help from?

What does your 'plan' look like?

Super quick themed retrospectives

At the beginning of my current role, I decided (possibly foolishly) that I would not repeat a retro with the same team. The goal was to create a new retro for each team, every time.

Some, I have lavished time on but when you need to pull one together in double quick time, I took the advice of Helen Meek who is the master of the themed retro.

The theme is usually a movie but musicals, sports, bands or TV shows are equally applicable. You can get creative with this and I think pretty much anything goes.

We all want to get actions from our teams so we pose questions about the sprint to help them look back and find those improvements e.g.

• What problems did we encounter?
• What's going to hit us next?
• What went well / not so well?
• What went according to plan?
• What caught us by surprise?

etc etc

Using the theme, we can cunningly wrap the same questions up to keep the whole thing interesting and unique.

Here is an example:

Happy, Mad, Sad is sooo 1990s! Replace Happy with Joy, Mad with Anger and add Disgust and Fear and you have the main characters from Inside Out:

What made us happy?

What did we find unpleasant?

What made us sad?

What should we be scared of?

What made us loose our temper?

Quick and easy. Also works with kids up to 8 years old :)

With a bit of imagination you can pick 3-5 scenes from any film and come up with some questions to get your team thinking here are some examples from "The Internship" (which was an unpopular choice solely due to it's Rotten Tomatoes score, geeks eh?):

How did we help each other out?

What did we get wrong?

What can we celebrate about this sprint?

Since these are quick, you can tailor them to the teams current situation. When a few people left one team, I quickly added a '"How are we going to stay together?" question in a matter of minutes.

Google is an obvious place to have a look for scenes from films or you could have a look at film-grab.com to get those ideas going. Here's one that Dan Rushton sent me, which made me chuckle:

Did we see anything shocking?

Still stuck for ideas? Get the team to suggest a movie or something they are interested in. So when I heard one of my teams discussing the Great British Bake Off...

What was our showstopper?

What was the technical challenge?

Which of our creations would have turned Mary's stomach?

What did not go according to plan?

Maybe it could be a new film they are all talking about? Maybe a Xbox/PS4 game? A season finale, perhaps? The format is simple and flexible and I enjoy them as fillers between more focused and structured retro's when there is something I want to "deep dive" into.

Be warned. Some people don't get metaphors. There is no helping these people, believe me I have tried :(

For a masterclass, be sure to visit the many blogs of Miss Meek, enjoy!

My Retrospective on my Retrospectives

I have been doing regular retro's for about a year since I changed direction career-wise. I have recently been looking over how my style has changed and looking at why these changes came about.

Working with an experienced Agile coach has certainly been the catalyst - Helen Meek has pointed out many areas of improvement which I have been gradually working on over the last few months. Other inspiration was from an amazing talk from a lady who works with kids on the Autistic spectrum called Gina Davies.

She describes how she centers attention around a box. There is something different every time in the box and the kids she works with respond to this by sitting and waiting to see what happens next. You don't realise how effective this is until you see some video - kids with ASD don't get 'waiting' but after a relatively short amount of time, they start to participate and want to wait to see what happens next. The box is 'magic' - something new happens every time.

So this got me thinking, what's my 'magic box'? The obvious answer is the retro. It should be fun and engage the team. It should be something we all look forward to. Here's my observations on things that I have changed over the last 6 months:

Keep it Fresh - One of the key things I have tried to uphold is to never repeat the same retrospective with a group. I mix up sections of the retro or come up with a dedicated retro to target a specific area that the team needs to improve on. Sometimes I am inspired and come up with something completely new, other times I spend some time putting something together using the awesome Retromat.

Experiment - Each team is different. Different styles and techniques fit with some teams and are lost on others. Experimenting with formats lets you continuously improve getting the team involved and engaged. You also learn what works for a given situation - your retro style and format may well change depending on the sprint and team morale.

Sit back, relax - Helen encouraged me to sit back and watch the team rather than stand up and direct. Sounds easy but your team may now be a bit lazy! By you sitting back 2 things will happen - first your team will need to get more involved and second you can observe your team and start actively getting people involved. Helen encouraged me to direct, rather than lead which is a really nice way of seeing it.

Stories not Events - I have noticed that the events that stick out are usually the bad ones. These are usually the ones brought up with allows for improvements but does not help with celebrating successes. We should be pepped by the end of a sprint! Using timelines you can encourage storytelling, allowing you to replay a sprint from beginning to end. You can journey through the sprint, looking at what happened so you can see both the good and bad points.

Be prepared! - I spend as much time prepping a retro as doing one, if not more. Since I vary my format, I have to spend some time thinking about what I am going to do. This is a good thing and the team deserve it. Playing out the same retro might feel safe but I should imagine the team dread it after a few months. Dedicate time to preparing your retro, fitting it in with the teams personalities and requirements.

I'm sure there is more but these are the ones I have had on my mind recently. Enjoy!

Retrospective: The 'Perfect' Sprint

This retrospective switches the attention of the team from the sprint they just had and allows them to explore what their 'perfect' sprint would look like. I have used this with teams that had a bad sprint - topics from the sprint will surface irrespective.

We represent the sprint as 4 columns - Prep, Planning, Dev Day, Review. You can choose the columns you want to focus on. The team then write up stickies for their perfect sprint, focusing on a column at a time. You will find that opposites occur at this point e.g. the opposite of what actually happened in this sprint. You can pose questions to get to the root cause and add more stickies if required.

I usually pair people for this, which seems to work better that everyone individually participating. I allow a time box of about 5 minutes and then we quickly go through the points raised. You can group common themes at this point. We repeat this for each column in sequence, following a journey through the sprint.

The key is keep the team focused on the perfect sprint. You can dive into specific issues as required - these will likely be based on the current sprint so they make good topics for discussion. I found this fits into a 60-90min retro with 4 columns at a good pace. If you have less time you can use less columns.

At the end we start to highlight what is in our control. This is usually pretty high - 50-75% seems to be about right. This leads the team to the obvious question - why don't we have our perfect sprint more often, given so much of it is in our control?

This outcome drives which actions we want to take into the next sprint - taking one from each column is a nice idea, but it does depend on what you came up with.

Retrospective: Ghost's of Retro's Past

This is a retro design to confront teams with actions from retros that have not been put into practice. Without actions there is little point in the retro, right? This is not a format you can run regularly - ideally you should not have to!

Start of by hunting down all the outcomes from the previous 4-5 sprints. Print them off in large print, cut into individual cards, fold them up and place them in a bowl. On a board or wall, draw out 3 columns - Ditch, More and Done. The team now take it in turns to pick an action from the bowl and place it in the column they think the action is relevant to.

Encourage discussion at this point - I played devils advocate often e.g. "I thought that was done?", "Didn't you do that?", "Yeah, we said that 3 months ago...." - you might not be so mean.

If actions are in More they are still relevant so there is no reason why they should not be done. Anything in More represents a missed opportunity for change. It is worth pointing out how awesome these ideas are and that they already came up with them - seems like a bit of waste.

Ditch suggests this is no longer relevant - you might want to explore if this is because they are old or we have evolved as a team. You might want to ask why didn't we need it? What do we know now that we did not know when we came up with this action? How did we ever survive without it?

You can also look at the Done actions and look at why they were Done - are they special/easy... what was different? It might come as a surprise how little has been 'Done'. This can be a valuable learning exercise in itself.

You can now focus the learning on why we did not do these things and then tease out which ones from More should we do immediately. Make sure the team buy into addressing these items in the next sprint. Ask the question "What could we put into practice today?".

Retrospective: Island Voyage

The concept behind this is to encourage the team to replay their sprint and discover key parts of their journey. The linear voyage you take the team on means we focus on the whole sprint rather than just remembering the final few days, which might not be the best to refer to.

You start with drawing an island in the top right of the board. This is the destination and represents what we delivered. Mine has palm trees and a tiki bar - it is a lovely place to be :) You can have fun with the name, mine was 'Delivery Island' which is a bit boring.

You start the retro by asking, which kind of vessel represented this sprint as the icebreaker. You draw this in the bottom left hand corner of the board. You can play with the speed of the boat, how large it was, was everyone on board, did we have space space for more stories, what kind of motor did it have, was everything ship shape - you get the idea. Naming the boat is a nice touch.

You can then spread out the visual cue cards for the team to see. These help them explain events or things they noticed on their journey to the island in the boat they described. I usually give a description of what they are too as this gets peoples creative side kick started.

If it was a not a clean sprint, you can ask the team where they got to. Was it close to the island? One of my teams decided they got to 'Acceptance Bay' but never made it the island itself. Maybe it went terribly and they ran out of fuel halfway?

Encourage them to use the cards as cues to describe their journey to the island, these can represent things we saw, things we avoided or things we did e.g.

• did we avoid any big storms or did bad weather push us off course (hurricane)
• did we know where were going (compass)
• was our time kidnapped or did we have to go out of our way to avoid being kidnapped (pirates)
• is there blood in the water or do we need to be cautious (sharks)
• did we see anything amazing (sunset)
• did anything distract us (dolphins)
• was there somewhere we would have preferred to be (desert island)
• was there the threat of destruction (sea monster)
• what held us back or what stopped us from floating away (anchor)
• what could sink us or what did we manage to avoid (whirlpool)
• did we have anyone overboard (man overboard)
• where we all alone or did we loose our way (dead calm)

The cue cards mean the team don't have to draw anything but if you have a creative bunch, ditch those immediately! If they cannot see a picture that represented what they wanted then they can draw anything they like. You can find pictures easily on Google - I would watch out for mermaids though, they tend to be NSFW (you have been warned).

During the journey you can experiment with detours - you can ask "did we have to go that way?", "Was this the scenic route - was there a more direct way?". You can also explore short cuts - these represent a better way of doing things based on what you know now - "Can you see a faster way of getting from here to here?". Maybe you the team got lost? If so, how did they get their bearings again?

The journey path can meander and double back on itself if the team had problems. It can suddenly go straight if there was a breakthrough. You can go around features if you avoided them (The Hurricane of Support) or show the path going through them (The Whirlpool of Broken Builds) if it was a rough time. You can stop off at places if you had slow progress and show the paths of other obstacles that you crossed which maybe hindered or halted your progress.

The linear nature of the journey lends itself to story telling and the nautical metaphor is pretty easy to grasp. By telling the story of the sprint, you often cover things that we might have forgotten about otherwise.