Running a Retrospective

Retrospectives are a core part of our process for keeping projects running smoothly, encouraging open communication, and hitting our goals. In this video, Joe Ferris, thoughtbot CTO, leads Chris and Ian through a typical retro while describing the process and thinking behind each step.

Overall Structure

We strive to keep our retros very lightweight with minimal process and structure, but we none the less have a typical flow and outline that we use to capture the work.

To begin, the advisor will open a blank document to take notes, with the following structure:

What went well?
---------------

What we're worried about?
-------------------------

What's next?
------------

What Went well

The first question we'll ask in a retro is "What what went well?". The advisor will go around the room asking everyone to comment, and noting their responses. It's useful to note these positive comments as likely we'll want to reinforce and support these items moving forward.

In addition, it's good to start on a positive note, and gets everyone engaged and saying something, making them more likely to speak up later in the retro as we get into slightly heavier topics around concerns and issues.

What are your worried about?

The next question the advisor will ask (again, going around to everyone at the retro), is "What are your worried about?". The goal here is to highlight issues early, giving us a chance to address them as they come up, rather than when they've grown out of control.

Note: During this segment, we try to only collect the concerns, but defer the discussion until we've collected the concerns from everyone. This allows us to see if there are any standout issues on many folks minds, as well as prevent derailing the discussion to focus on a single issue.

Once everyone has shared their concerns, the advisor will then go through the concerns (possibly in order, possibly leading with one if it seems to be more a cause / central) discussing how we can handle it. This is a prime example of a portion of the retro that doesn't have any more specific structure, but instead is intended to provided a space for whatever conversation is needed.

Project Planning Tool

Over the years we've used just about every project planning tool in existence (and built a few of our own). We've found that nearly any tool can be made to work, and our current preference is for Trello as it provides a nice compromise between functionality and freedom to structure as needed.

Project Planning Structure

The following is our typical structure, implemented as "Lists" in Trello, with each piece of work moving through the Lists as it is worked on.

• Backlog - Prioritized list of stories, preferably well defined and set for someone to go to work on whenever they are ready.
• Up Next - Staging area for the current week of work. All the more important that the stories in this list are prioritized and clarified.
• In Progress - Current work being done.
• Reviewing - Code review and or acceptance (on some projects these are split into two lists).
• Deployed - Stories that were deployed to production in the last week or so.

Finally, we'll often have an Ideas or Epics column used to track more abstract aspects of the work, things still needing detail and specifics. This list is a great place to collect early wireframses and mockups and have higher level discussions about features.

Previous Retrospective Review

Each week as we finish out the retrospective, we'll create a checklist of things we agree to do. At the next retro we'll review that list to confirm everything is done. Once everything is checked off, we'll archive the card, but until then it will stick around becoming and ever more prominent reminder to complete the retro tasks.

Prioritizing the Backlog

After reviewing the conversation points and the previous retro, we'll turn our effort to ensuring we've identified the work for the next week. The goal is to ensure we have sufficient clear, prioritized work captured in the backlog to take us through the week. We want to know what the next steps are and be ready to dive into work as we complete other tasks.

Note - If this feels like it will take up too much time (more than five minutes) then we'll organize a separate planning meeting to handle that. The goal is to keep the retro focused and useful for everyone.

Similarly, if we regularly find that we need to schedule that extra planning meeting, it's worth taking a minute to understand why this is. Ideally, planning and prioritizing is a continuous processing appending throughout the week, and not something we need to set aside specific time form.

Wrapping Up

Often the advisor will end by asking "Is there anything else you want to talk about?". This is another example of providing space for conversation, without necessarily dictating the structure of that conversation. Typically there will not be anything else to discuss, but when there is, it's great to have the space for it.

Once the conversation has wound down, the advisor will post the notes in a Trello card, capturing any tasks in a checklist to ensure we get everything done and allowing for review at the next retro.

What We Don't Do

While we've tried to highlight the actual process and type of discussions we encourage during our retros, it's worth noting some of the things we purposefully don't do.

Estimation / poker points

One thing we try to avoid is providing estimates for all work or trying to use any sort of point system. We've certainly tried this in the past, but we've found that it is extremely difficult to get right and tends to be a poor substitute for regular honest communication.

Note this isn't to say we refuse to estimate: estimations are useful in the process of planning and prioritizing work. Often we'll provide an estimate to help prioritize and decide if a certain feature is worth taking on in the current week, but we decidedly do not estimate or track velocity on all our stories.

Specificity as the Work Approaches

Similarly, we do not try to deeply specify work that is more than a week or two out. Often there is a desire to gain a picture of "all the work to be done" or a burndown chart that can help understand when the work will be done. In general we've found that this effort quickly proves to be misguided as we work on a product and better understand what we're building.

Instead, we prefer to only loosely define work more than a few weeks out, discussing in abstract terms and via wireframes, rather than with the specificity of exact interface elements, workflows, etc. Only as the work approaches do we work to provide this detail, typically just before we begin working on it in the next week.