How To Do Sprint Retrospectives Easy #2

Reading time: 7 mins

A few days ago we went over the first part of “How to make sprint retrospectives easy” and today we are continuing on the subject. We will give more details about how to properly get feedback and how to set owners to the newly identified problems your team has surfaced. Nothing is easy but practice makes perfect and this small guide will make your life easier on how to tackle sensible situations while making progress.

Prepare your data

  • You have a list of problems that people care about
  • You have a list of possible solutions, no matter how feasible they are
  • Your team had time to think it through, so things might change

Create an excel file (or Google sheet):

  • List of issues that you want to fix (“Problems”) and try to group them in 3-5 “areas”. These will be your “pillars”
  • Give them name codes. That always helps, unless it doesn’t. A lot of people don’t really like namecodes, but are good with colors. Have a different color for each pillar.
  • Organize your actions for each PIllar
  • Make sure you didn’t miss anything and set up a Retrospective follow up meeting

You can take it one pillar at a time or all together, depending on how the team is feeling. If people get tired, break. Pizza helps in the start of these meetings to calm spirits and start constructive conversations.

Low hanging apples

Review actions for each pillar, add new stuff, modify existing ones 10-15 mins.

Now let’s see what can be done relatively quickly and with little effort. Put those on top of the action list and add owners against them. Should be done by EOD, right?

Fourth (hidden) rule: You shouldn’t be owning the actions. You’re accountable but not responsible. You’re driving the process, not loading the truck. Yes you could have one or two. Or help your colleagues out, but just don’t have your name against half the list.

Fifth rule: Always an owner (not 5) Always an ETA. IF not an ETA, an ETA for the ETA.

Other fields:

  • Priority: good, not mandatory
  • Impact: important when you report to others outside the team

Your table will look like this

Feedback ItemAction Key ActionStatusETAOwnerPriorityImpactComments

The real deal

Tough part starts now. You’ll likely have actions that require other parties to be involved to help or even divine intervention. Don’t panic! Take them one by one, assess the impact and also add the feasibility of the solution.

Likely people will start to complain, you’ll might hear things like:

  • We’ve done this x times and it didn’t work
  • This is always like that around here
  • Don’t even think of starting that conversation with them!
  • They are the ones that stay in the path of greatness
  • They are always like that
  • They something something

That’s when you need to steer the conversation to:

  • That was then this is now
  • Who are “they”? Let’s engage “them” to explain the impact. So add an action on the list with an Owner and ETA.

Oh, and there are the “impossible” things that you might find on the list

  • Add Owners and ETA
  • Find out why they are not feasible

And now it’s time for another

Break

Breaks are good, people think about things, they get to talk and come up with creative ways of dealing with things. Breaks are good.

What have you achieved

  • You have a list of Feedback items grouped in Pillars
  • You have a list of clear actions for each Pillar with Owners and ETA
  • You have a new thing that you need to drive and it will take time

This is it for today, if missed the first part of “How to make sprint retrospectives easy”, here you can find it.

I hope you enjoyed today’s article, please give us a thumbs up if you did and let us know what other Software Development subjects might interest you.

See you around.

Leave a Reply

Your email address will not be published. Required fields are marked *