Mike Cohn专栏
您应该一直努力保持产品待办列表小而易管理，因为如果其中的条目过多，就会出现三个问题：
首先，过大的产品待办列表很难用。查找条目，会很浪费时间（“我只知道它在其中某个地方。”）。对产品待办列表进行优先级排序，会花费更多时间。由于添加一个“以防万一”的条目比确保它还没有列出要容易得多，于是就出现了重复项。
其次，开发团队会几乎感觉不到他们取得了任何进展。完成了50个产品待办项中的10个，团队能明显感觉工作取得了进展。而同样是完成了10个产品待办项，但却有着1000个产品待办项时，团队就不会有这种成就感。他们会开始琢磨是否只完成9个也没什么关系。
Read more →
理想情况下，Scrum团队能完全不受干扰地实施Sprint工作。产品负责人永远不会引入变更，客户永远不会提出紧急需求，用户也永远不会发现任何缺陷。
尽管团队都渴望能有一个不受干扰的Sprint环境，但大多数团队都无法独善其身。绝大多数Scrum团队确实得在Sprint中处理各类干扰。
尽管用户故事（User Story）很有用，但其并不适用于所有团队。对于某些团队来说，工作故事（Job Story）是一个令人兴奋的替代方案。工作故事不太关注使用功能的用户，而更关注待办工作。工作故事起源于对讲机项目，艾伦•克莱门特（Alan Klement）对此做出过最好的解答。 工作故事模板 为了弄明白工作故事是如何从关注用户转变为关注待办工作的，让我们看一看所推荐的工作故事模板： 
Read more →
今天，我突然意识到：多年来，有一位完美的Scrum Master就摆在我眼前，那就是蝙蝠侠。当然，我想他是不会愿意放弃其打击犯罪的使命而去担任一名Scrum Master的。但是，只要他愿意，我认为有五大要素使得蝙蝠侠能成为一名理想的Scrum Master。
1. 蝙蝠侠很谦逊
Read more →
如果您已在使用计划扑克估算，那么您或许已能熟练运用斐波那契序列（或者修订的斐波那契序列）卡片。
传统的斐波那契序列是1、2、3、5、8、13、21等等，每个数都是其前两个数之和。
多年前，我开始让团队使用修订的斐波那契序列（1、2、3、5、8、13、20、40和100）进行估算。
为什么要使用斐波那契序列呢？
因为彼此之间过于接近的数字作为估算值使用时，难以进行区分。 Read more →
敏捷团队有一个常用的度量指标——团队是否完成了迭代规划的全部工作。
评估团队多擅长完成其承诺，这并没有错。但不能要求团队每次迭代都完成全部工作。
这不现实，并且会导致团队为了安全交付所有工作而保守地承诺。
Read more →
我完全理解一些团队成员对参与每日站会的抵制。我也不喜欢开会。但有些会议是有用的，值得花时间投入。我把运行良好的每日站会归入此列。
在本文中，我将分享如何应对每日站会的四条常见异议。然后，我将分享运行良好的每日站会的一些特性，这能使其不被与会者抵制。
Read more →
组织会出于多种原因而采用敏捷方法。一些组织希望能提高生产率和缩短产品上市时间，另一些组织希望能够获得更成功的产品，还有一些组织希望能增强开发人员与业务人员间的协作，以提升质量或提高团队成员的工作满意度。
当然，还有许多组织采用敏捷是希望能同时实现这些好处的组合。
但是，为了能从敏捷中尽可能多地获得好处，组织似乎也存在很多误解。在本文中，我想谈谈关于敏捷产品开发的六个误解。
Read more →
Scrum只有三个正式角色：Scrum Master、产品负责人和团队。对于程序员、测试人员、数据库工程师、分析人员、设计人员等角色，并不加以区分。
例如，测试人员也只是团队成员之一。测试人员与其他团队成员共有同一个职责：在冲刺结束时开发一个潜在可发布产品增量，以实现冲刺目标。
在每位团队成员帮助团队实现这一目标的方式方法上，会存有差异。测试人员会尽可能地从冲刺待办列表中选取测试工作，而设计人员则会选取设计工作。
Read more →
作者：Mike Cohn
译者：李洁（Jerry Li）
审校：廖靖斌（Eric Liao）
本文由Mike Cohn授权翻译，未经许可请勿转载
几年前，我把几个高尔夫球打到湖里了，一起打球的朋友给了我一些建议。现在那位朋友打高尔夫球已经不比我强了，但他仍在没完没了地建议。他说：“问题是，你得把球打得更远。” 他这样说还不如告诉我，“问题是，你打了很多次才把球打进球洞。” 我当然需要打得更远。但怎么做到呢？
类似的，你们可能也被告诫过——ScrumMaster、敏捷教练或敏捷项目经理都可能告诫你——敏捷项目管理是要领导团队而非管理团队。
