内容简介：为了将来的Sprint拆分大事项、分析事项、重新估计并重排优先级。团队；如果产品负责人是能够帮助梳理细节的专家，那么他会全程参与整个活动，否则他可以只参与其中一部分来设定方向或者重排优先级；其他理解需求并能给予团队帮助的人；ScrumMaster将在会议的开始部分来指导团队如何有效地开这个会，否则的话他不必参加。通常来讲不多于团队一个Sprint工作容量的10％，但有时对于“有大量分析工作”的事项来讲要更长一些。例如，对于两周的Sprint，可能要有一天的时间花在梳理上。
概述：
为了将来的Sprint拆分大事项、分析事项、重新估计并重排优先级。
参与者：
团队；如果产品负责人是能够帮助梳理细节的专家，那么他会全程参与整个活动，否则他可以只参与其中一部分来设定方向或者重排优先级；其他理解需求并能给予团队帮助的人；ScrumMaster将在会议的开始部分来指导团队如何有效地开这个会，否则的话他不必参加。
时长：
通常来讲不多于团队一个Sprint工作容量的10％，但有时对于“有大量分析工作”的事项来讲要更长一些。例如，对于两周的Sprint，可能要有一天的时间花在梳理上。
Scrum中一个很少有人知道，但很有价值的指导原则是，每个Sprint中整个团队要把一定百分比的时间专门用于梳理产品待办事项列表上，做为对将来Sprint的支持。这包含了详细的需求分析、把大的事项拆小、估计新的事项以及重新估计已有事项。Scrum中没有说这个工作该如何来完成，但是一个经常用到的方法是在接近Sprint中部或者结尾时开一个专注的研讨会，这样团队和产品负责人以及其他利益相关人就可以不受打断地专门做这些事情。
这种梳理活动并不是为了当前Sprint已经选择的那些事项。它是为了将来的事项，最可能是为了下一两个Sprint。有了这个实践方法，Sprint计划会议变得相对简单些，因为产品负责人和Scrum团队将从一组清晰的，被很好分析过并认真估计过的事项入手。没有开过这种梳理工作研讨会（或者没做好）的特征是Sprint计划会议中出现重大的疑问或者发现，或者令人困惑并感觉不完整。这样一来计划工作通常要延续到Sprint中去，这显然不是大家想要的。
以上就是本文的全部内容，希望本文的内容对大家的学习或者工作能带来一定的帮助，也希望大家多多支持 码农网
猜你喜欢:
- 如何使用React Hooks建立一个待办事项列表
- 禅道 9.8.stable 发布，增强待办功能和消息通知功能
- 喧喧 1.5.0 优化服务器性能，支持将消息创建为然之待办
- 微软待办事项To-Do Windows 10 UWP版更新：支持多账户切换
- [ Laravel从入门到精通 ] 测试系列 —— 通过测试驱动开发构建待办任务项目（一）：后端 API 接口篇
- [ Laravel从入门到精通 ] 测试系列 —— 通过测试驱动开发构建待办任务项目（二）：前端功能和浏览器...
本站部分资源来源于网络，本站转载出于传递更多信息之目的，版权归原作者或者来源机构所有，如转载稿涉及版权问题，请联系我们。
