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:
- The section ‘Retrospective notes’ collects all the fantastic ideas we jotted during the sprint.
- 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:
- The section ‘Retrospective notes’ collects all the fantastic ideas we jotted during the sprint.
- 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.
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.
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
Was this helpful?
Thanks!
Rina Nir
5 comments