If you’re on an agile software development team, you should be having regular retrospectives. Having retrospectives is like eating your veggies for your scrum team; without them you can’t grow big and strong.
So we are going to assume that you do participate in retrospective meetings. Almost everyone I know who does is constantly complaining about the same recurring problem. They sit down in the retro meeting, go to write out their sticky notes or retro items to talk about, and cant. Think. Of. Anything.
The timer is ticking away, and nothing is coming to mind. Your mind might start to wander. Well, we had stand-up earlier today, what did people talk about then? AH! Suddenly three things come to mind and you jot them down. By the end of your retro writing period, you’ve got almost no retro topics to talk about and almost all of them happened in the last few days. Everyone on the team shares their items and the same thing happened, everyone is talking about things that already occurred in the past, but next to nothing comes up from the beginning of the sprint.
Questions pop up:
“What did we DO in the beginning of the sprint?
What went wrong in the first few days?
What did we absolutely NEED to talk about that I can’t remember at all?
How is this even possible, I remember we had a prod incident and it was a terrible experience, I just can’t remember what it was.”
This is a prime example of recency bias AND why it is an absolute killer for productive retrospectives.
Recency bias is: A true defined cognitive bias that “favors recent events over historic ones. A memory bias, recency bias gives ‘greater importance to the most recent event.’”
What this means is that for everything in life, given two events that happen of equal importance, we will over weight the impact of the event that happened closer to today, and discount the importance of the event that happened farther in the past. EVEN THOUGH THEY WERE BOTH JUST AS IMPORTANT.
Why is this such a bad thing when thinking about retrospectives?
Well retrospectives are a tool for an agile engineering team to look back at a period of time (typically a 1-2 week long sprint), think about what went well, what didn’t go so well, and define action items for ways to improve team performance. HOWEVER a 2 week period is a long amount of time! And if you are only thinking about the events that happened 1-2 days before you’re retrospecting, you are totally missing out on a goldmine of learnings that could be uncovered from the first ¾ of your retrospective.
OK, OK, so how do we work around recency bias? My memory sucks, and the days are just blending together during COVID.
Well reader, JUST REMEMBER HARDER.
I’m kidding, that’s not a useful takeaway.
In all seriousness, instead of waiting until your retrospective meeting to think back to everything that went well and everything that could be improved, try to do it during your sprint.
This is a hard habit to build, for a while, I tried to write everything down and keep a running list. There are also amazing tools out there to help you and your team capture real time retro items.
If your team uses Slack, Retrorabbit.io has built a slack bot that can actually remind you periodically during the sprint to think about retro items.
The coolest part is that you can enter notes throughout your sprint, which then gets automatically ported over to a standard retrospective board without doing anything more. Instead of starting your sprint, having the team sit there and think about retrospective items for 5 or 10 minutes only remembering recent events, you can head into your retro meeting ready to go with a full list of items and spend the majority of your time just focused on getting better as a team instead of trying to remember the past.
Tools like Retrotabbit also let you customize reminders for yourself to help build the habit. You can also see how many people have contributed retro topics throughout the sprint, and how many retro topics your team has before the meeting starts.
All of this combines into having more total retro items, more people on the team participating, and a retro with richer content from throughout the duration of the sprint instead of all at the end.
Regardless of how you do it, capturing, and then remembering real time retro topics to talk about throughout the sprint will dramatically change the quality of your team retrospectives. I highly recommend any and all teams that have regular retrospectives work to build the habit of regularly capturing retro items to avoid the pitfall that is recency bias.
Disclaimer: I am affiliated with Retro Rabbit, the tool highlighted in this article
About the author:
Ben Staples has over 7 years of Product Management and Product Marketing eCommerce experience. He is currently employed at Nordstrom as a Senior Product Manager responsible for their product pages on Nordstrom.com. Previously, Ben was a Senior Product Manager for Trunk Club responsible for their iOS and Android apps. Ben started his Product career as a Product Manager for Vistaprint where he was responsible for their cart and Checkout experiences. Before leaving Vistaprint, Ben founded the Vistaprint Product Management guild with over 40 members. Learn more at www.Ben-Staples.com
I do Product Management consulting! Interested in finding out more? Want to get notified when my next product article comes out? Interested in getting into Product Management but don't know how? Want book recommendations?! Contact me!