Where do retrospective action items belong? (Probably not in Jira)

回顾会议的行动项应该放在哪里？（大概率不该是 Jira）

You know the cycle. Your team runs a great retro. People are honest. Three or four genuinely good action items go up on the board. Someone says “I’ll put these in Jira.” Everyone nods. Two weeks later you’re sitting in the next retro and someone raises the same problem. 你一定熟悉这个循环：团队开了一场很棒的回顾会议，大家畅所欲言，看板上列出了三四个真正有价值的行动项。有人说：“我把这些放进 Jira 里。”大家纷纷点头。两周后，当你坐在下一次回顾会议中时，又有人提出了同样的问题。

That moment, multiplied across thousands of teams, is why a 2023 Scrum Alliance survey found only 35% of teams consistently complete their retro action items. The other 65% are running the conversation, generating the insight, and then losing it within about a week. I’ve watched this play out enough times that I have an opinion now, and it’s not the one I started with. Most retro action items don’t belong in Jira. Some do. The ones that don’t belong there are the ones that quietly disappear. 这一幕在成千上万个团队中不断上演，这就是为什么 2023 年 Scrum Alliance 的一项调查发现，只有 35% 的团队能持续完成回顾会议的行动项。另外 65% 的团队虽然进行了讨论、产生了洞察，却在一周内将其遗忘。我观察过这种情况足够多次，现在我有了一个观点，而且这与我最初的想法不同：大多数回顾行动项不应该放在 Jira 里。有些确实需要，但那些不该放进去的，往往最后都悄无声息地消失了。

The two camps every team falls into

每个团队都会陷入的两个阵营

Camp 1: dump everything into Jira. It feels rigorous. Jira is the system of record for the rest of the work, so if a thing is real it should have a ticket. “Improve our PR review process” becomes JIRA-4471, gets assigned to Sarah, and joins the queue. Sarah remembers it for about six days. 阵营 1：把所有东西都扔进 Jira。 这感觉很严谨。Jira 是其他工作的记录系统，所以如果一件事是真实的，它就应该有一个工单。“改进 PR 评审流程”变成了 JIRA-4471，指派给 Sarah，然后进入队列。Sarah 大概能记得这件事六天。

Camp 2: leave them in the meeting notes. Someone pastes the action items into a Confluence page or a shared doc. The expectation is that people will check back. Nobody does. By Wednesday they couldn’t find the doc if you paid them. 阵营 2：留在会议纪要里。 有人把行动项粘贴到 Confluence 页面或共享文档中。大家的预期是人们会回头查看，但没人会看。到了周三，就算给他们钱，他们也找不到那个文档了。

Both camps fail for the same reason. The place you store an action item should match the cadence and shape of the work it represents. Jira is built for prioritised, customer-facing work that flows through a board. Retro action items usually aren’t that. The shared doc has the opposite problem: it tracks nothing. 两个阵营失败的原因是一样的：存储行动项的地方应该与该工作本身的节奏和形态相匹配。Jira 是为那些通过看板流转的、面向客户的优先级工作而设计的。回顾行动项通常不是这类工作。而共享文档则有相反的问题：它什么也追踪不到。

Why Jira feels right and usually isn’t

为什么 Jira 感觉是对的，但通常却不是

Putting an action item in Jira looks responsible. You’re treating it like real work. It tends to fall flat anyway, for four reasons: 把行动项放进 Jira 看起来很负责任，你把它当作真正的工作来对待。但它往往还是会落空，原因有四点：

No stakeholders. A Jira ticket usually exists because a customer or a PM wants something shipped. A retro action item exists because the team wants to fix itself. Without external pressure on the assignee, it sinks.
没有利益相关者。 Jira 工单通常是因为客户或产品经理想要交付某样东西而存在。回顾行动项是因为团队想要自我改进而存在。如果没有来自外部的压力，指派人往往会将其搁置。
Grooming kills it. Backlogs get prioritised by impact, urgency, and customer pain. “Add a 5-item PR checklist” loses to every customer-facing ticket. Forever.
梳理（Grooming）会扼杀它。 待办事项列表是根据影响力、紧迫性和客户痛点来排序的。“增加 5 项 PR 检查清单”永远竞争不过任何面向客户的工单。
Invisible to the next retro. When the team brainstorms again, nobody opens Jira to check what’s still open from last sprint. The information is technically there. The flow doesn’t bring it back into the room.
对下一次回顾会议不可见。 当团队再次进行头脑风暴时，没人会打开 Jira 查看上个冲刺周期还有什么未完成。信息虽然在技术上是存在的，但工作流并不会把它带回会议室。
Process improvements don’t scope down. “Communicate better about blockers” or “do refinement before planning” aren’t tickets. They’re rituals. Forcing them into a story-points-and-acceptance-criteria shape distorts them and makes them harder to do, not easier.
流程改进无法拆解。 “更好地沟通阻塞点”或“在规划前进行需求梳理”不是工单，它们是仪式。强行将其塞进“故事点”和“验收标准”的框架中会扭曲它们，反而让执行变得更难。

The action items that DO belong in Jira

确实应该放进 Jira 的行动项

I want to be fair. Some retro action items absolutely belong in your tracker. The test is whether the action is real shippable work. 我得公道一点。有些回顾行动项确实应该放在你的追踪工具里。判断标准是：该行动是否是真正可交付的工作。

“Add integration tests for the checkout flow.” Engineering work, has an outcome a PM cares about, ships.
“为结账流程添加集成测试。”这是工程工作，有产品经理关心的产出，可以交付。
“Fix the three flakiest tests in CI.” Real work, scoped, owned, ships.
“修复 CI 中最不稳定的三个测试。”这是真实工作，有范围、有负责人，可以交付。
“Document the on-call runbook for the auth service.” Borderline. Real work but it’ll never win against customer features in grooming. Probably better in your retro tool with a Jira ticket linked when someone actually picks it up.
“记录认证服务的运维手册。”处于边缘地带。这是真实工作，但在需求梳理中永远竞争不过客户功能。最好还是放在回顾工具里，当有人真正接手时再关联一个 Jira 工单。

The clean rule: if the action item would survive a sprint planning conversation as a regular ticket on its own merits, it belongs in your tracker. Push it there with a one-click export, link the ticket back to the retro item, and move on. 清晰的规则： 如果该行动项凭借其自身价值，能够在冲刺规划会议中作为常规工单存活下来，那么它就属于你的追踪工具。通过一键导出将其推送到那里，将工单链接回回顾项，然后继续前进。

The action items that DON’T belong in Jira

不该放进 Jira 的行动项

Almost everything else. “Stop scheduling refinement on Fridays.” “Run a 5-minute kudos round at the end of every retro.” “Try a 4-day sprint for the next two cycles as an experiment.” “Stop merging on Fridays unless a release manager approves.” 几乎所有其他内容。例如：“停止在周五安排需求梳理”、“在每次回顾会议结束时进行 5 分钟的表扬环节”、“尝试在接下来的两个周期内进行 4 天冲刺作为实验”、“除非发布经理批准，否则停止在周五合并代码”。

These are commitments and rituals. They matter, but none of them have a definition of done that fits a sprint board. They need somewhere they can be revisited weekly without competing for priority against feature work. That somewhere is your retro tool. 这些是承诺和仪式。它们很重要，但没有一个符合冲刺看板的“完成定义”。它们需要一个可以每周回顾的地方，且不需要与功能开发竞争优先级。那个地方就是你的回顾工具。

Why the retro tool is the right default

为什么回顾工具是正确的默认选择

Four things engineering trackers don’t do well: 工程追踪工具在以下四点上做得不好：

Continuity. When the next retro opens, last sprint’s open action items are right there. The team sees them before brainstorming new ones. This single behaviour does more for follow-through than any other intervention I’ve tried.
连续性。 当下一次回顾会议开始时，上个冲刺周期的未完成行动项就在那里。团队在头脑风暴新内容前就能看到它们。这一简单的行为比我尝试过的任何其他干预措施更能促进执行。
Context. The action item lives next to the retro item that produced it. Click through and you see the original “we keep merging on Fridays and breaking things” thread, the discussion, the votes. Tickets in Jira get stripped of all that and become a one-line subject nobody can decode three weeks later.
上下文。 行动项与产生它的回顾项并列。点击进去，你可以看到最初的“我们总是周五合并代码导致出错”的讨论串、讨论过程和投票。Jira 工单会剥离所有这些信息，变成一行三周后没人能看懂的主题。
Cadence. Retro action items want a weekly heartbeat. A ticket on a sprint board wants daily standup attention or it gets buried.
节奏。 回顾行动项需要每周的脉动。冲刺看板上的工单需要每日站会关注，否则就会被淹没。
Pattern detection. When the same problem comes up across three retros over six weeks, that’s a different problem than a one-off complaint. Jira can’t surface that, because it doesn’t know the items are related.
模式检测。 当同一个问题在六周内的三次回顾会议中反复出现时，这与一次性的抱怨是完全不同的问题。Jira 无法发现这一点，因为它不知道这些项是相关的。

That last one is what tipped me. The first time I saw a tool flag “this team has raised CI flakiness in three retros over six weeks and only one action item from those retros has been completed”, I realised I’d been undercounting how often we punted on the same thing. It was uncomfortable, and it was the most useful single data point I’d gotten about my team in a year. 最后一点是让我转变观念的关键。当我第一次看到工具提示“该团队在六周内的三次回顾中都提到了 CI 不稳定，且这些回顾中只有一个行动项已完成”时，我意识到我一直低估了我们在同一件事上拖延的频率。这让人不舒服，但却是我一年来从团队那里得到的最有用的单一数据点。

What this looks like in practice (Kollabe)

实践中的样子 (Kollabe)

I work on Kollabe, so take this with the appropriate grain of salt. The patterns generalise; if your tool of choice does these differently, swap in the equivalent. 我在 Kollabe 工作，所以请带着批判的眼光看待这一点。这些模式是通用的；如果你使用的工具处理方式不同，请替换为等效功能。

Action items live with the retro that produced them. Each has an owner, a due date, and a status. They show up in the next retro before the team starts on new ones. Every Monday morning, anyone with open action items assigned to them gets a single email summarising what’s still open. Not a Slack ping in a channel where it scrolls past lunch. A direct email at the start of the week, addressed to one person. 行动项与产生它们的回顾会议绑定。每一项都有负责人、截止日期和状态。它们会在下一次回顾会议开始前显示出来。每周一早上，任何有未完成行动项的人都会收到一封总结邮件。不是那种在 Slack 频道里午饭时间就刷过去的提醒，而是一封在周初直接发给个人的邮件。