在此博客文章中，我想分享一些有关为敏捷团队创建合理的产品待办事项列表的准则。虽然这当然是产品经理或产品负责人的领域，但往往要由BA来帮助或“拥有”敏捷团队中的Backlog详细信息。- 修饰–每周进行两次修饰会议。记住Schwaber提供的10％的投资指导–因此每个小组成员每个冲刺周4小时（无论是个人还是在会议中）
- 另一个指南是，在执行Sprint之前，与团队反复探索每个用户故事至少4倍。
- 作为高级史诗；至少在执行前发布
- 作为一个故事或一组故事，距离执行3-4个冲刺
- 故事1-2冲刺离执行
- 作为一个故事 就在之前 执行
- 对于更复杂的工作，新功能，硬重构等，请确保确定了对这些故事进行脱机，协作整理的子团队，重点是
- 早期设计讨论
- 识别故事工作流程& breakdown
- 迎接挑战& risks
并始终在故事或Wiki中留下足够的工作笔记。通常我将其捕获为SPIKE。记住有关尖峰的两件事：
- 您应该明智地使用Spike Stories作为一种方法，让您的团队将复杂的史诗精炼成有意义的故事和工作流程。我想说大约有20％的用户案例是Spikes的候选人。不要短缩它们！
- 尖刺应该在冲刺中进行 之前 将执行目标定位的Sprint。这鼓励团队进行一些健康的预见。
- 产品积压应首先设置为优先顺序，并始终由产品所有者按优先顺序重新排序。订单可以更改，但也应该稳定-代表产品所有者的市场/客户意识来满足业务需求并增强团队信心。因此，不要无休止地积压待办事项积压，因为这会降低团队的信心。
- 美容会议着重于3 等级 积压的
- 史诗般的故事：将大型史诗分解为多个部分；估计其规模，复杂性并确定优先级/工作流程；可能不超过两个版本。
- 中期故事：整理离执行2-3个冲刺的故事。让团队开始思考设计；执行效率，
- 短期故事：在目标冲刺之前“修饰”故事。
- 运行端到端的Blitz计划，以获取团队对工作流的反馈。我认为经常进行Blitz Planning是有益的。例如，在计划好发布之前要多次。您也可以在一个发行版的中期进行此操作，以便尽早猜测下一个发行版中的内容可能性。不要害怕经常与您的团队一起执行这些端到端视图！
- 分配时间来修复每个Sprint的错误！即使您将这些设置为团队的“伸展故事”，也需要将时间分配给用户意图和接受标准。
- 分配时间用于每个冲刺的硬化和测试时间。这些是用户故事，在进行闪电战计划时特别有用。他们应该具有接受标准，以指导团队达到实现“完成”所需的LOE。
- 说到完成，应该对整个组织有一个明确的“ Done-Ness”定义，并在适当的情况下为团队唯一定义。所有故事的评估和验收标准都应牢记这一成熟度水平来创建。其中应包括以专业和负责任的方式完成每个故事的工作。
积压的积压有哪些“气味”？
- Sprint Planning令人难以置信的清晰，简短而轻松；通常需要2个小时或更短的时间才能进行2周的冲刺。会议内没有任何建筑或设计讨论，这些讨论的相关部分早已发生。
- 团队成员正在讨论将来针对冲刺2-3-4冲刺的史诗和故事-在每个冲刺中几乎每天都在进行，并且很自然地与产品所有者的愿景保持一致。
- 团队可以轻松地为Backlog贡献新故事，以代表基于非功能的工作；例如：测试工件，非功能性测试工作，重构，自动化开发，性能调整，SPIKE等。 他们认为这是共同的责任。
- 团队对产品的长期发展有一种感觉，并为该愿景制定了工作计划，设计，主题建议和权衡方案。
- 每个Sprint的目标都可以轻松地从积压中得出；即，在待办事项列表中容易浮现出一些周到且有意义的主题。有时将它们视为“包装”。
- 产品负责人在每次冲刺中都包含团队反馈（错误，重构，改进，测试等），并以一定百分比为重点。他们清楚地表明了团队对他们的反馈，判断和技术意见的信心。
- 由于尺寸估算，产品负责人很少更改元素的优先级。这不包括将它们拆分为Now&后来的位。说明优先级主要来自翻译成故事的外部业务需求。
- 闪电战计划每2-3周进行一次，不仅作为计划工具，而且作为风险/调整工具。 对于XP专业人员，可以将发布计划视为类似的练习。关键是，针对下一个发布里程碑的端到端计划非常频繁地发生。
- 团队正在尝试一些弹力项目，并在每次冲刺中投入更多工作。有一种热情，可以通过创造性地权衡故事子元素来朝目标提供更多目标。
- 待办事项映射到团队的技能和能力，扩大了他们的能力–是的，但不是要求他们去做他们无法通过技能或经验来做的事情。
- 产品负责人的每个冲刺都会根据与团队的互动进行微调整，以调整范围。永远-寻找最小的可销售功能集！
- 团队在Sprint计划中从未感到惊讶。甚至没有一个故事。 我知道，应该发生变化，但是让最后一刻发生变化的团队感到惊讶……不是！而是–等到下一个冲刺。
- 团队认为他们在待办事项列表，功能与改进项的分配方面都有发言权。但是他们的观点不能完全是狭och的。他们需要从客户POV提出业务案例，以应对Backlog中引入的所有非功能性工作。而且他们乐于做到这一点！
希望对您有所帮助...
鲍勃
不要忘记在下面留下您的评论。
