👆Level up👆 your retrospectives! (and why you should run one!).

You can also view this post on: https://dev.to/wabbbit

Regardless of which Agile methodology you use to deliver your software – You are using one, right?, retrospective is one of the most important meetings you can have. Sadly, it’s one of those meetings that can turn into an unstructured nightmare, and if you aren’t getting anything out of it, what is the point? This is a quick 5-min guide of leveling up your retrospective, or convincing you if you don’t already run one.

What is the retrospective for? Why should I run one?

By definition, a retrospective is a look into the past. In this context it is a chance for the team to get together at the end of a sprint/milestone and discuss what did and didn’t go well, and more importantly what can be done to improve. It should give the entire team a chance to voice their opinions in a safe space, and provide honest feedback that can be used to improve future iterations/sprints.

TL;DR: The aim of retrospective is to identify incremental improvements to make the next iteration/sprint better than the last.

Quick fact-sheet

Who runs it?: Arguably the meeting should be ran by the Team leader/Scrum master etc. However it can be ran by anybody as it is an open discussion owned by the entire team. Ideally one person should take ownership though to ensure the meeting stays focused and to track any outcomes.

Who attends: The retrospective should be attended by the entire delivery team. Business analysts, developers, testers, project managers, product owners etc. Anybody that was directly involved in the delivery of items. This meeting is not for the wider community such as stakeholders as this often limits honesty.

When is it ran:: The retrospective should be ran at the start of the iteration – looking back at the previous iteration. Typically this would be ran after any sprint-review/show & tell meeting and the stakeholders have left the room.

How long should it be: Keep it focused! 5 minutes per attendee. In an “ideal-size” SCRUM team this shouldn’t be more than 30-45 minutes.

An effective retrospective template

We have trialed many different approaches over the years for our retrospective. The theme has always been the same with the focus being on what went well, what didn’t and what could we change.

Lately we introduced a new template as retrospectives were becoming slightly unfocused talking-shops and although solid actions were coming out of them, people seemed hesitant to self-judge unless prompted.

Before this we also used the “Traffic light method”, also known as “Start, Stop, Continue”. My issue with SSC is that it has the potential to derail quicker and doesn’t feel as focused. SSC can also sometimes become dominated by one or two people and I felt that I was excluding people at times. That is why I like the 4 question method.

The 4(ish) question method

Part 1: Questions for each team member

Go around the table, each person answering the following 4 focuses.

  • What was a success for you this iteration?
    • For example: a particular piece of work they were proud of, a bug they resolved quickly, etc. This is important as it allows the team member to show-off or gloat a little. If you don’t let people discuss success, they won’t want to talk about failure!
  • What was a failure for you this iteration,and why? Could it have been avoided?
    • For example: “Not completing agreed work, because of X”, or “spending more time than they thought on Y”. 
      They should know why this happened and ideally what we could do to stop it happening again.
  • If you could have changed one thing about the last iteration, what would it be?
    • For example: “Break down work items sooner”, “Spend less time in meetings”
  • Did you learn anything?
    • Important as you want your team members to grow. Whether that is technical knowledge or product knowledge.

The answers should be simple one liners, and may prompt discussion among the group. For example, let’s say somebody says they felt one failure of the iteration was that they couldn’t complete a piece of work as the requirements changed last minute. You could ask why that happened and what we could do it mitigate this in the future.
Keep any follow up discussions short and concise. It’s very easy for someone to “go down the rabbit hole”. Take any discussion that will take longer than a couple of minutes offline or come back to them at the end. You don’t want to chew through all your time on one person, after all!

The person running the session should capture all the failures and changes.


  • What was a success for you this iteration?
    • A success for me this sprint is that we resolved a critical priority item well within the SLA and had a happy client with positive feedback.
  • What was a failure for you this iteration,and why? Could it have been avoided?
    • what: A failure for me this sprint I couldn’t get my changes into the test environment quick enough due to lack of Change Control resource.
      why: Change Control staff were not available at short notice.
      action We should schedule in resource capacity at the start of a sprint.
  • If you could have changed one thing about the last iteration, what would it be?
    • n/a
  • Did you learn anything?
    • I learned how {{some component}} worked.

This may have prompted discussion about how we need to think about how we deploy changes via another department and an action would be that we will do some up-front scheduling.

Part 2: Take action!

This whole process is pointless if nobody is taking any actions off the back of this session!
In part 1, the person leading the session should have taken notes of all the potential actions.

The session lead should quickly iterate over the actions captured and as a team decide;

  • Is this something that we should do immediately, or place in the backlog?
  • Who is taking ownership for this action?

Part 3: Coffee.

You deserved it, go you!

Although, there is no such thing as a free coffee. The actual 3rd item is to follow up on actions.

Issues you may run into:

People don’t want to talk about failure: Perhaps people feel like they are being judged. To combat this, really focus on the success of the sprint as the main talking point & promote an open/safe environment. If individuals don’t want to open up, the session-lead could drive an open conversation – i.e. “Why do you think we (as a team) didn’t achieve X”

Hostility: Make sure any feedback is constructive and blame free. Never attribute failure to another team member. Always use “we” never “you”. Promote collective ownership!

Lack of interaction Some people are introverts and may not want to join open discussion. If this is an issue, suggest people write the answers on post-it notes and have the session primarily led by the team-lead (Collating and discussing). Still give them the option to share or change their answers within the session.

Turning into a moan-fest. This one is really easy to slip into. To avoid this, promote constructive discussion. Ensure actions are being followed up or people may not take the meeting seriously and just use it as an opportunity to vent.

Retrospective your retrospective

Yo dawg. I heard you like retrospectives.

There is no “best” way to run a retrospective session. Every team is different and sometimes you may find the format doesn’t work with the people that are attending. If it isn’t working for you, don’t abandon it, adapt it! YMMV.

Using time tracking software to your advantage.

Ugh, Time tracking!

People often convulse when hearing “Time tracking” in a work context. Although some companies use this to ensure their pesky workers aren’t having any downtime and are constantly little cash cows, I believe it can be used for good and more importantly boost your own productivity. Why not use time tracking software to your advantage?!

Of course, this doesn’t mean the horrid aforementioned, corporate time tracking doesn’t exist, but don’t let this cloud your judgement.

The tool I will introduce is not a new tool by any means, but everybody I have introduced it to since has been hooked and hasn’t looked back.

So, why should I care?

You know the life of a typical developer. Constant interruptions, sporadic support emails and “quick” breakout sessions that turn into hour long meetings. You get to the end of your iteration and get asked “Why didn’t you get around to X”. Wouldn’t it be best to quantify instead of sounding off excuses?

Introducing, Toggl

Toggl is a completely free (With paid options) time tracking tool which is available for web, desktop and mobile. I have been using this now for almost 4 years.

The way it works is that you can assign Tasks against a particular project (I.e. “Client X support”, or “Internal Meeting”), which are attributed to a specific client. Tasks are free-text but can be grouped together for reporting by using the same auto-completed task name. You can keep everything completely unassigned or be anal retentive and go super-granular with multiple projects per client and different work streams (like me!)

For example, If I take a random day from the last few weeks I can see what I was doing, and how the day was distributed. I found it best to only create a new entry when my context changes – such as moving to a different bit of work, or having to go provide some support at someones desk etc.

Here, you can see I spent 7hr 53min on pure work activities that day. Within this day we spent 24 minutes in our daily catchup (Ouch!), and a chunk of my day was taken up with support of some kind and the rest pushing releases out the door.

What I like about Toggl is I can say something like “Wow, that is a lot of time for standup, how much time is ‘wasted’ each month?”

Toggl has a fairly decent web based dashboard, offering much more functionality than the desktop or mobile applications. You can drill down into each task, project or client to find out where your time is spent. See below.

That’s nice, but what’s the point? (aka. How I benefited)

a) Find out how much time you spend on repeating activities (& IDentify OPTIMIZATIONS)

Find out what your “expensive” repeatative tasks are and optimize them! For example:

Here, you can see I spent 10.5hr last month either in daily standups, show & tell or retrospectives (All under my SCRUM umbrella [scrumbrella if you will…]). Whilst this is only ~6% of my time, it is still a considerable chunk and an area I could look at optimizing within the team. A future post will be on running effective standups, watch this space.

One major win I had from using this tool was finding out how much time I was spending pushing and prepping release files. I monitored this over a couple of months, and then implemented Powershell scripts to automate the task. It now takes 10% of the time!

B) Track time working on QA vs. new features

The way I break down my projects is to have a core collection of projects under each client, usually:

  • <clientname> : (Used for any Change Requests and billable work)
  • <clientname> Support : (Used for client reported defects or queries)
  • <clientname> Release Activities : (Used to track testing and release cycle time)

This means that I have the ability to do the following:

  • Identify which clients are the most demanding or raise the most queries/defects (and allow us to highlight testing gaps, knowledge issues etc.)
  • Identify how much time I spend on QA vs billable work
  • Fill my time sheets in after the fact without manically scanning email trails and check in histories!!

C) Have a valid excuse!

It’s the last day of the delivery cycle and you haven’t completed a feature. Wouldn’t it be great to say (and have the backup) that you spend 25% of your time couped up in unplanned meetings?

Being able to justify something is good. Being able to justify it and point at a pie chart is better!


Toggl is a great tool (for me at least) and I really do recommend it if you want to see how your day is really spent and generate reports . After years of use, I dont see myself stopping.

Toggl has a ton of additional options too, such as tagging up tasks, marking items as billable for better invoicing and more- features I don’t personally use, but may be useful for someone.

What do you use, if anything, and have there been any success or failure stories of doing so? Note: this is posted to dev.to for discussion.