Rob*_*nik 5 project-management scrum estimation user-stories
我们开始了一个将使用Scrum/XP管理的项目.我们预先编写了整个产品backlog用于评估目的.我们确保所有故事都以客户为中心,我们正在评估它们
100个故事点可能有一些故事与遗嘱/将不会有,因为它们实际上是更大的复杂故事,如果需要将在以后细分.
通过不重叠MoSCoW故事,计算故事的重要性基于价值和努力.
但是,如果没有100个故事,我们的故事到目前为止(也已经细分)的复杂程度在2到8之间,我们认为这是一个适当的故事大小,以避免微观管理.但有些故事相互关联或相互依赖.如果首先完成,我们的故事可能会花费更多,如果在他们之前完成其他故事则会减少.
问题
是否有可能在开发过程中稍后调整故事点,因为我们可以处理故事任务,我们可以在其中重新评估它们,添加新内容,删除现有故事或故事情况不是这样吗？因为改变它们的复杂性,也将根据计划的速度改变结束日期估计.在这种情况下,最佳做法是什么？
你绝对可以再次估计你的故事,你应该.只有当团队在Sprint开始之前的Sprint计划会议中向他们提交时,才会锁定这些积分.
我使用的一种做法是在进行单独的Sprint规划时,您应该再次评估每个故事.团队会随着时间的推移而学习,并通过估算和识别依赖关系变得更加准确.记住Sprint的内容取决于团队,产品所有者定义整体积压.如果项目有时间限制,请不要试图使估算符合结束日期,如果你这样做,那么你就是在为失败做好准备.
请记住,使用Velocity,您首先要猜测您可以完成的任务.通常直到第3或第4个Sprint才能确定团队可以管理的真实速度.是的,这意味着你可能认为球队每次冲刺可以得到20分,实际上只能得到15分.是的,这意味着交货时间结束或故事低于切割线.
至于依赖故事,您应该与产品所有者合作.如果团队与他们交谈,您通常可以重新安排故事.大多数人都接受别人,告诉他们:"如果我们做了,现在它会采取全力冲刺,但如果我们做了以后它会采取一个Sprint的15%",使得它非常有说服力.
尝试一种有用的做法是在Sprint中安排故事.在计划会议期间,一旦所有故事都经过验证和讨论,团队就会提取日历并讨论他们何时完成任务.通过在日历上放置目标日期,它有助于识别故事之间的重叠和依赖关系.这可以识别串行的内容并可能导致Sprint失败.
希望这些信息有用.