步骤4:Sprint计划(任务)

完成后 步骤#3并明确要求 对于针对Sprint的所有Product Backlog项目,下一步是详细计划Sprint…

Sprint规划研讨会(第2部分)

Sprint规划研讨会的第一部分(在本系列的最后一步)重点在于阐明所选产品待办事项的要求。 Sprint规划研讨会的第二部分着重于将需求分解为任务并估算完成任务所需的时间。

尽管研讨会的第二部分可以从第一部分开始继续进行,但有时这有助于两次会议之间的短暂间隔。大概1天。这使您有时间在继续下一步之前,弄清研讨会第1部分引起的任何未解决的问题。

确保所有团队成员都参加了会议。包括所有角色。业务分析师(如果有)。测试人员(如果有)。产品的Scrum团队中的所有开发人员。

产品负责人以及任何客户,用户或业务代表都无需参加Sprint Planning研讨会的这一部分(第2部分),因为这本质上可能更具技术性,并且更多地与团队一起研究如何选择选定的待办事项。已交付。

但是,如果愿意的话,应该欢迎他们参加,这可能有助于他们了解提供功能所涉及的内容,并且在讨论和评估任务时,如果需要进一步澄清,可能会有所帮助。

设置冲刺预算

首先,计算团队的Sprint预算。这是团队在Sprint上必须工作的可用小时数。

首先将“ Sprint持续时间”中的可用小时数乘以“ Sprint”中的专​​职人员数量。对于在Sprint中兼职的人,请包括他们可以承诺的工作时间。

然后,合理推断出团队成员将无法花费在Sprint上的时间。减去假期,任何已知的会议,可能花费在其他项目上的时间等。根据过去的经验,在适当的时候减去合理的支持时间。

确保所有这些计算都是透明的并对所有人可见。

将需求分解为任务

仔细检查为Sprint选择的每个产品积压项目。将需求分解为任务。

任务可能包括开发生命周期中的传统步骤(尽管仅限于所讨论的功能,而不是整个产品)。例如:设计,开发,单元测试,系统测试,UAT(用户验收测试),文档等。

Remember, agile software development methods do not exclude these steps. 敏捷 methods just advocate doing the steps feature-by-feature, just in time, instead of in big phases.

这些任务(尤其是开发)中的每一个都可以进一步细分。也许在组件级别上,详细介绍了交付产品功能所需的软件体系结构的每个单独元素。

在Sprint中包括使Product Backlog项目100%完成(即可能可装运)所需的所有任务。团队一致同意 完成的定义,因此每个人都知道必须完成哪些工作并将其包括在估算中。

尽可能将任务陈述为可交付成果。可交付成果比任务更具可衡量性。除了描述您将要做的事情,还描述您将要交付的内容。

以小时为单位估算任务

保持较小的任务。以小时为单位估算所有任务。团队评估每个任务。

询问每个人他们的想法,以便确定错过的任务或确定更简单的解决方案。
理想情况下,任务估计不应超过1天。如果估算值远大于此,则应进一步分解需求,以使任务减少。尽管这可能很困难,但实践起来会更容易。

将任务保持足够小以至于估计少于1天会有一些特定的好处。

首先,将任务分解成很小的块意味着它们更容易估算。结果,您的估算精度将得到提高。其次,在每日Scrum(站立会议)中,少于1天的任务更具可衡量性。 1天的任务完成或未完成。

提交Sprint待办事项列表

为选定的产品待办事项汇总所有任务估计。如果它们大大超出了团队的Sprint预算,请减少为Sprint选择的产品待办事项的数量。请记住,产品待办事项列表是按优先顺序排列的,因此,如果可能的话,应该是从Sprint中删除的待办事项列表中较低的项目。

剩余的估计任务列表–完成Sprint中选定的产品待办事项所需的任务–是您的Sprint待办事项列表。

团队应致力于交付Sprint待办事项列表。

确定伸展任务

有时团队承诺不足或高估了。发生了奇怪的事情! --

以我的经验,当团队不熟悉Scrum时,这很常见。我认为这是因为他们不熟悉该过程,并且一开始可能超出了他们的舒适范围。他们过去可能没有太多的估算经验。并且他们可能以前没有被要求承诺自己交付。有时,这可能会导致对估算值的谨慎处理。

除了您认为可以实现的目标之外,请始终在Sprint Backlog中包括一些其他范围。为了使团队尽早交货,这是很重要的,因为理想情况下,Sprint应该保持固定的长度。

清楚地将这些项目标识为“拉伸任务”。产品负责人永远不要期望达到拉伸任务。如果从未达到“拉伸任务”,则任何人都不应被殴打。而且,如果您确实完成了任何拉伸任务,这应该值得庆祝!

下一个…

所以现在你已经 整理您的积压订单, 估计您的积压, 阐明您的要求,并计划您的冲刺。现在您已准备好执行步骤5 – 创建一个协作工作区

凯莉

也可以看看:
如何通过10个简单步骤实施Scrum:
步骤1:按顺序整理您的待办事项!
步骤2:如何估算您的产品积压
步骤3:Sprint计划/明确要求
步骤4:Sprint计划/估算任务
步骤5:创建协作式工作区
步骤#6:冲刺!
步骤#7:站起来,算数!
步骤#8:使用每日燃尽图跟踪进度
第9步:完成您说的话
步骤10:查看,反映,重复…

在脸书上分享
Facebook
分享到Twitter
Twitter
在linkedin上分享
LinkedIn

发表评论

您的电子邮件地址不会被公开。 必需的地方已做标记 *

最近的帖子

文化,技能和能力//如何成为数据驱动型组织

在我们的白皮书“如何成为一个由数据驱动的组织中”,我们写了一个组织需要采取的五个步骤,它们是:成果:定义目标和指标以确保获得清晰和可衡量的结果分析:实施和共享分析,以改善数据驱动型决策创新:通过假设测试和学习来测试假设数据平台:获得新见解

Read More »

数据平台//如何成为更具数据驱动力的组织

这是我们关于“如何成为一个由数据驱动的更多组织”系列文章中的第四篇,我们将专注于数据平台。在这一点上,大多数人开始深入研究Data Lakes vs Data Warehouse的技术方面,但是我们想让我们回到一个更高的水平,并要求

Read More »

创新//如何成为更具数据驱动力的组织

在我们的白皮书“如何成为一个由数据驱动的组织中”,我们写了一个组织需要采取的五个步骤,它们是:成果:定义目标和指标以确保获得清晰和可衡量的结果分析:实施和共享分析以改善以数据为依据的决策制定创新:通过假设检验和学习来检验假设数据平台:获得新

Read More »

搜索博客

敏捷 Management Made Easy!

All About 敏捷

凯利·沃特斯(Kelly Waters)

“’Agile’ is one of the biggest buzzwords of the last decade. 敏捷 methods often come across as rather more complicated than they really are. This book is an attempt to unravel that complexity. To simplify the concepts. This book breaks the concepts into small bite-sized pieces that are easy to understand and easy to implement and delivers the message in a friendly and conversational style. Allaboutagile.com is one of the most popular blogs about agile on the web. ”

凯利·沃特斯

敏捷 101 is available to purchase. GAME ON!

敏捷 101

艾玛·霍普金森火花

“尽管有很多方法可以根据您拥有的团队和想要的学习成果来改变游戏,但是游戏的基本流程是所有人共有的。”
艾玛·霍普金森火花

我们为什么制作游戏?

怎么玩游戏?

伦敦

101种方式Limited
城市路145号
伦敦
EC1V 1AZ
英国

阿姆斯特丹

101种方式BV
Weesperstraat 61-105
1018 VN阿姆斯特丹
荷兰

联系我们

如果您想与101 Ways的团队之一联系,请填写以下表格或给我们发送电子邮件: contact-us@101ways.com.