I recently read the article “Why I don’t like discussing action items during incident reviews” by Lorin Hochstein. The article lists a few reasons why action items should not be discussed during incident reviews1. While I personally think an incident review is a great place to think about possible action items, I am missing one major reason to not decide on action items in that meeting: An incident review is not a planning session.
A planning session is a meeting in which a team reviews all the work they could do from a backlog, prioritizes it, and selects the top items. It’s the meeting where you pick what to do among all the possible things you could be working on.
If you pick what to work on during an incident review, you are not taking into account all the other tasks you can work on. Planning needs to take a holistic approach, which usually doesn’t attend incident reviews).
I have been in far too many incident review meetings where the right counterparts to make a holistic prioritization are not in the room. Examples of counterparts missing can be product owners, higher engineering managers, or other teams. If they are not in the room, the action items should not be decided to be implemented there.
So, what’s the alternative? Just make a small adjustment - call it “action item candidates”. They are candidate action items - albeit high priority - that you will bring into your planning session.
Throughout my career, I think this has been the biggest reason why incident review action items are forgotten, lost, and never implemented.
Addendum: My friend and former colleague jeekl pointed out that some teams have some kind of goalie/on-caller that doesn’t work on a backlog. They can of course start working on action items as long as they don’t compete with a backlog.
Also known as post mortems, learning reviews, After-action review (AAR), post-incident analysis, etc. ↩︎