一些最佳做法,即将推出的产品列表
可采取的措施清单是一个产品
产品负责人负责产品待办事项列表的内容、可用性和优先级。产品待办事项列表永远是不全然的,最初的版本号仅仅列出最初始的和众所周知的需求。产品待办事项列表依据产品和开发环境的变化而演进。待办事项列表是动态的,它常常发生变化以识别使产品合理、有竞争力和实用所必需的东西。仅仅要产品存在。产品待办事项列表就存在。
产品待办事项列表列出了全部的特性、功能、需求、改进方法和修复等对未来公布产品进行的改变。
产品待办事项列表条目包括描写叙述、次序和估算的特征。
产品待办列表里有什么?
产品待办列表的另外一个翻译产品待办事项列表显示产品待办列表里应当包括待办事项。
待办事项包括全部的特性、功能、需求、改进方法和修复等对未来公布产品进行的改变。
常见的待办事项是以用户故事形式来表达的。
怎样维护产品待办列表?
在Scrum Guide中,产品待办列表通常以价值、风险、优先级和必须性排序。
排在顶部的产品待办列表条目须要马上进行开发。
排序越高,产品待办列表条目越紧急,就越须要细致斟酌。而且对其价值的意见越一致。排序越高的产品待办列表条目比排序低的更清晰、更详细。
依据更清晰的内容和更详尽的信息就能做出更准确的估算。优先级越低。细节信息越少。
开发团队在接下来的Sprint 中将要进行开发的产品待办事项列表条目是细粒度的,已经被分解过。因此,不论什么一个条目在 Sprint 的时间盒内都能够被“完毕”。开发团队在一个 Sprint 中能够“完毕”的产品待办列表条目被觉得是“准备好的”或者“可运行的”,能在 Sprint 计划会议中被选择。随着产品的使用、价值的获取以及市场的反馈。产品待办列表变成了更大、更详尽的列表。由于需求永远不会停止改变。所以产品待办列表是个不断更新的工件。
业务需求、市场形势和技术的变化都会引起产品待办列表的变化。
若干个 Scrum 团队经常会一起开发某个产品。但描写叙述下一步产品开发工作的产品待办列表仅仅能有一个。
那么这就须要使用对产品待办列表条目进行分组的属性。“产品代表事项列表优化(英文原文是grooming)”是增添细节、估算和排序条目的举动。这是一个持续不断的过程,产品负责人和开发团队协作讨论产品代表事项列表条目的细节。在产品待办事项列表优化的时候。条目会被评审和改动。然而,产品负责人能够随时更新产品待办事项列表条目或酌情决定。
单列表的产品待办列表有什么困难?
树形的产品待办列表更具表现力
第一级列表(比方原始需求,史诗故事) | 第二级列表(比方用户故事,需求用例等) | 第三级列表(比方界面细节) |
---|---|---|
epic1 | userstory1 userstory2 userstory3 |
相应于userstory1的细节 相应于userstory2的细节 相应于userstory3的细节 |
epic2 | userstory4 userstory5 userstory6 |
... |
...... | ... |
长期运维的产品待办列表不再仅仅包含待办事项