Ben*_*Ben 6 scrum user-stories
我们使用Scrum.当我们发现用户故事不够精细以捕获完成冲刺所需的工作时,我们在冲刺期间遇到问题.
特别是,我们发现我们提供的UI线框包含的复杂性比原始故事所暗示的要复杂得多(例如,由于可用性原因,复制功能).这导致燃尽图表看起来像是在冲刺的最后一天完成所有事情.
我们花费周一在每个为期2周的冲刺开始时讨论由项目团队创建的故事,在此期间我们通常会对故事进行一些细化并将其分解为任务,估算每个故事创建燃尽的时间图表.在这一天,我们觉得我们没有时间有意义地提高故事的质量.
如何最好地打破我们冲刺的不完整/不充分故事的循环？
这是项目团队在一开始就没有充分确定故事,或者我们(即开发团队)应该承担一些责任吗？
所以你这样说:
开发团队是否有可能真正与客户/用户交谈？用户故事有时被视为开始对话的一种方式,而不是需求文档/规范.
编辑:一些链接:
编辑:Martin Fowler昨天在ConversationalStories上发表了一篇博文,其内容比我更好.
你在进行冲刺回顾吗？在回顾会议结束时,您应该拥有高优先级的可操作项目,以改进上一个sprint中发生的事情.同样的事情不应该反复出错.
在sprint期间,您的产品所有者是否可访问？如果不是,您可能需要为任何估算添加额外内容,因为用户故事的详细信息不完整.
@Pascal建议将5%的冲刺用于产品积压修饰是一个很好的建议.这应该可以使您的用户故事在sprint开始之前处于更详细的位置.
我们花费周一在每个为期2周的冲刺开始时讨论由项目团队创建的故事,在此期间我们通常会对故事进行一些细化并将其分解为任务,估算每个故事创建燃尽的时间图表.在这一天,我们觉得我们没有时间有意义地提高故事的质量.
听起来这是您的sprint计划会话,您是否可以控制您在sprint期间提交的用户故事？如果你没有足够的细节,你怎么能承诺？
这将带您回到有良好的回顾并解决所提出的问题.
如何最好地打破我们冲刺的不完整/不充分故事的循环？
回顾,规划,积压修饰.
这是项目团队在一开始就没有充分确定故事,或者我们(即开发团队)应该承担一些责任吗？
它是整个团队的责任.发现责任不会带来价值,但每个承担责任的人都会给每个人一个成功完成项目的机会.
也许在周一早上的计划会议期间,您可以让任何正在编写用户故事/线框的人参与进来,找出他们缺少的细节,哪些细节会使您的估算更容易,更准确.也许可以制定一个他们应该包含的模板.
| 归档时间： |
|
| 查看次数： |
2069 次 |
| 最近记录： |