How to amnesia-proof your retrospectives?

I love retrospectives. Not because I am such a soul-digging person by nature. I prefer working through my ‘to dos’ than pausing to think about the past. But over the years, I have seen how we arrived at some surprising insights from these retrospectives. Like when we found out that it’s better to do our standups at midday rather than in the morning because George was more distracted in the mornings. Our standups became more efficient due to this minor tweak. And then there was that time where we realized that test development had become a bottleneck. So we took action and upped our test development skills. This change means that we can now release new versions almost daily, while as before, we could release only once every two weeks.

 

And then, we discovered that our retrospective process itself is sub-optimal. A retrospective is only as good as the input topics- that is, you must remember to raise anything worth discussing. But- after two weeks of a sprint, with so many moving parts, tasks, and events, we often forget to raise essential points. It’s frustrating to remember something critical two hours after the retrospective ended. Ouch!

 

So, to amnesia-proof our retrospective process, we decided to improve how we collected discussion topics. Welcome to retrospective breadcrumbs in Jira. 

 

How to breadcrumb your way into retrospective insights?

 

We use a classical Jira sprint board with the default issue types: epics,  stories, tasks. To make it more conducive for collecting retrospective inputs, we added a new custom field: Retrospective notes. When something noteworthy comes up, we jot it down there. Here are some Retrospective notes:

  • Ramesh noted on DEVT-23: “Bug requires a big infrastructure to reproduce, and this takes forever.”
  • Rina noted on DEVT-32: “IMO: This story was not ready for the sprint. Let’s check our eligibility criteria.”

We no longer need to trust our good memory or private notes to raise these topics at the retro meeting. A simple JQL query finds all the retrospective notes:

project=DEVT AND Sprint=2 AND "Retrospective notes[Paragraph]" is not EMPTY

 

Later we found that one of our frequent problems was that people were blocked from progress. Blockers were harming our velocity and hitting our motivation. We decided to focus on them, so we added a new Jira field: Blocker category. It’s a multi-select field, which ideally would srart empty, but as soon as anybody is blocked, they’d signal it there. 

The multi-select options are:

  • Technical environment issues
  • Dependencies on 3rd party
  • Dependencies on other teams
  • Too much multitasking or task switching
  • Changing priorities
  • Bad story slicing
  • Technical debt
  • Hidden complexity
  • Vagueness
  • Other

To clarify: the Blocker category field is not cleared when the blocker is solved. It’s only cleared after the retrospective. We use it for reporting- the field indicates that we had this blocker during the sprint. 

When we convene for a retrospective, we collect all recorded blockers: 

project = DEVT AND Sprint = 2 AND "Blocker category[Select List (multiple choices)]"  is not EMPTY order by created DESC



How to configure the Confluence template to surface the breadcrumbs- with Jira macro

Confluence is the virtual home for our retrospectives minutes. We added two new sections to the retrospective template: 

  1. The section ‘Retrospective notes’ collects all the fantastic ideas we jotted during the sprint. 
  2. The ‘Blocked issues’ section indicates if we are improving our process blockages.

The two sections feed on the two custom fields and use Jira Macro to list all the breadcrumbs we sprinkled during the development.

 

I love retrospectives. Not because I am such a soul-digging person by nature. I prefer working through my ‘to dos’ than pausing to think about the past. But over the years, I have seen how we arrived at some surprising insights from these retrospectives. Like when we found out that it’s better to do our standups at midday rather than in the morning because George was more distracted in the mornings. Our standups became more efficient due to this minor tweak. And then there was that time where we realized that test development had become a bottleneck. So we took action and upped our test development skills. This change means that we can now release new versions almost daily, while as before, we could release only once every two weeks.

 

And then, we discovered that our retrospective process itself is sub-optimal. A retrospective is only as good as the input topics- that is, you must remember to raise anything worth discussing. But- after two weeks of a sprint, with so many moving parts, tasks, and events, we often forget to raise essential points. It’s frustrating to remember something critical two hours after the retrospective ended. Ouch!

 

So, to amnesia-proof our retrospective process, we decided to improve how we collected discussion topics. Welcome to retrospective breadcrumbs in Jira. 

 

How to breadcrumb your way into retrospective insights?

 

We use a classical Jira sprint board with the default issue types: epics,  stories, tasks. To make it more conducive for collecting retrospective inputs, we added a new custom field: Retrospective notes. When something noteworthy comes up, we jot it down there. Here are some Retrospective notes:

  • Ramesh noted on DEVT-23: “Bug requires a big infrastructure to reproduce, and this takes forever.”
  • Rina noted on DEVT-32: “IMO: This story was not ready for the sprint. Let’s check our eligibility criteria.”

We no longer need to trust our good memory or private notes to raise these topics at the retro meeting. A simple JQL query finds all the retrospective notes:

project=DEVT AND Sprint=2 AND "Retrospective notes[Paragraph]" is not EMPTY

 

Later we found that one of our frequent problems was that people were blocked from progress. Blockers were harming our velocity and hitting our motivation. We decided to focus on them, so we added a new Jira field: Blocker category. It’s a multi-select field, which ideally would srart empty, but as soon as anybody is blocked, they’d signal it there. 

The multi-select options are:

  • Technical environment issues
  • Dependencies on 3rd party
  • Dependencies on other teams
  • Too much multitasking or task switching
  • Changing priorities
  • Bad story slicing
  • Technical debt
  • Hidden complexity
  • Vagueness
  • Other

To clarify: the Blocker category field is not cleared when the blocker is solved. It’s only cleared after the retrospective. We use it for reporting- the field indicates that we had this blocker during the sprint. 

When we convene for a retrospective, we collect all recorded blockers: 

project = DEVT AND Sprint = 2 AND "Blocker category[Select List (multiple choices)]"  is not EMPTY order by created DESC



How to configure the Confluence template to surface the breadcrumbs- with Jira macros in Confluence

Confluence is the virtual home for our retrospectives minutes. We added two new sections to the retrospective template: 

  1. The section ‘Retrospective notes’ collects all the fantastic ideas we jotted during the sprint. 
  2. The ‘Blocked issues’ section indicates if we are improving our process blockages.

The two sections feed on the two custom fields and use Jira Macro to list all the breadcrumbs we sprinkled during the development.

 

Retro notes Jira macros.jpg

 

Blockers Jira Macro.jpg

 

How to configure the Confluence template to surface the breadcrumbs- with the Jira Snapshots App

Over time, we realized that using Jira Macros for our retrospective minutes has a downside.

With each sprint, all our retrospective pages showed the current information in Jira. That’s how the Jira Macro works; it always shows the current data in Jira.

For example, when I view a retro page from a year ago, the ‘Retrospective notes’ section shows issues that were not even existing at the time that the retro meeting took place.  

As we often refer to our old retro pages, we changed the format and replaced Jira macros with Jira Snapshots macros. Disclosure: It’s provided by our marketplace App: Jira Snapshots - Time-Stamped Exports Into Confluence. This macro makes a static copy of Jira data. After the retrospective, whatever happens in Jira does not impact the  Confluence page. 

 

Retro notes Snapshots.jpg

 

Blockers Snapshots.jpg

 

Conclusion

We have been using this setup for the last few months, and it's been perfect. I no longer catch myself the day after thinking about forgotten topics. Our team even developed the habit of reviewing the breadcrumbs ahead of the meeting. So we propel quickly into brainstorming and debating.

Our retrospectives are now juicier than ever. Do you have more ideas on how to breadcrumb your way into better retrospectives?

 

PS: Do you want to see our retrospective pages live? They are available on our sandbox

 

 

5 comments

Marjorie
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
January 25, 2022

Thank you!  Great ideas here.  Especially capturing notes while in sprint.

Like # people like this
Birgit Strompen January 26, 2022

Great ideas. But duplicate content!

Like # people like this
Rina Nir
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 26, 2022

@Birgit Strompen thanks, but can you explain what you mean by duplicate?

Birgit Strompen January 26, 2022

@Rina Nir 

For example the first paragraph: "I love retrospectives...Iloveretrospectives1.PNG." is duplicated  below - shortly after the section "How to configure the Confluence template...Iloveretrospectives2.PNG

Like # people like this
Mykenna Cepek
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
January 28, 2022

One of my teams used to use a coffee can to collect pieces of paper for the retro -- old school.

@Rina Nir - I just LOVE these ideas to gather data at time-of-impact, right in the Jira issues, and flow them into the Retro!

A few thoughts of mine:

  • Configuring the two new fields to be in the "Hide when empty" section (Project Settings > Issue Layout) at the bottom of the Issue Detail pane is an easy way to introduce them without cluttering your current issue detail.
     
  • Customizing the Jira macro in Confluence to also include "Sprint = xx" in the JQL seems like a way to avoid having another add-on. I'm sure that Marketplace App offers more value than just this, but many of us try (or are forced) to minimize Apps. It would probably take only 1/2 minute to customize the JQL for the page macro to match the Sprint before the Retro.
     
  • We use a "Blocker" field today, but it's a single-select (the current source of the impediment). When our Blocker field is not empty, the card color changes on the board to visualize impediments.
     
  • As an Automation wizard, it occurs to me that it might be possible to use a Jira Automation rule, triggered on Sprint Close, to aggregate the historical values of that field into a separate field.

Thanks for the tips, Rina!

Comment

Log in or Sign up to comment
TAGS
AUG Leaders

Atlassian Community Events