product backlogs
ID – a unique identification, just an auto-incremented number. This is to avoid losing track of stories when we rename them.
Name – a short, descriptive name of the story. For example “See your own transaction history”. Clear enough so that developers and the product owner understand approximately what we are
talking about, and clear enough to distinguish it from other stories. Normally 2 – 10 words.
Importance – the product owner’s importance rating for this story. For example 10. Or 150. High = more important.
Initial estimate – the team’s initial assessment of how much work is needed to implement this story compared to other stories.
The unit is story points and usually corresponds roughly to “ideal man-days”.
How to demo – a high-level description of how this story will be demonstrated at the sprint demo. This is essentially a simple test spec.
Notes – any other info, clarifications, references to other sources of info, etc. Normally very brief.
How we prepare for sprint planning
Make sure the product backlog is in shipshape before the sprint planning meeting.
The concrete output of the sprint planning meeting is:
A sprint goal.
A list of team members (and their commitment levels, if not
100%).
A sprint backlog (= a list of stories included in the sprint).
A defined sprint demo date.
A defined time and place for the daily scrum
the product owner has to attend
Sprint planning meeting agenda
Having some kind of preliminary schedule for the sprint planning meeting
will reduce the risk of breaking the timebox.
Here’s an example of a typical schedule for us.
Sprint planning meeting: 13:00 – 17:00 (10 minute break each hour)
• 13:00 – 13:30. Product owner goes through sprint goal and summarizes product backlog. Demo place, date and time is set.
• 13:30 – 15:00. Team time-estimates, and breaks down items as necessary. Product owner updates importance ratings as necessary. Items are clarified. “How to demo” is filled in for all high-importance items.
• 15:00 – 16:00. Team selects stories to be included in sprint. Do velocity calculations as a reality check.
• 16:00 – 17:00. Select time and place for daily scrum (if different from last sprint). Further breakdown of stories into tasks.
分享到:
相关推荐
《硝烟中的Scrum和XP》是一本深入探讨敏捷开发方法的书籍,主要聚焦于Scrum和极限编程(XP)两种流行的敏捷框架。在IT行业中,这两种方法论被广泛应用于软件开发项目,以提高效率、灵活性和产品质量。下面将详细阐述...
本书《硝烟中的Scrum和XP》探讨了这两种方法论在实际项目中的应用和挑战,旨在帮助读者理解如何在复杂环境中有效地利用敏捷原则。 Scrum是一种以迭代和增量方式进行项目管理的方法,其核心在于团队的自我组织和跨...
在硝烟中的Scrum和XP这个主题下,我们可以看到两者在实际应用中可能会遇到的挑战和冲突。Scrum注重流程和角色,而XP更关注技术实践。有时,团队可能需要结合两者的优点,形成一种混合方法,以适应特定项目的需求。...
硝烟中的Scrum和XP XP
在这个名为“硝烟中的Scrum和XP”的资料包中,我们将深入探讨这两种方法的核心理念、实践过程以及它们在项目管理中的应用。 Scrum是一种轻量级的框架,强调团队的自我组织和迭代开发。它以短期的冲刺(Sprint)为...
Scrum和极限编程(XP)是两种非常流行的敏捷开发框架,它们在现代软件开发领域扮演着重要的角色。本文将深入探讨这两种方法的核心理念、实践原则以及如何在实际项目中应用。 **Scrum** Scrum是一种以人为核心、...
在本书中,作者Henrik Kniberg讲述了他在一年的时间里,带领40人的团队实施Scrum的过程。他们试过了多种团队尺寸(3~12人)、sprint长度(2~6星期),定义“完成”的不同方式,不同的backlog格式,各种测试策略,...
同时,Scrum的每日Scrum可以强化XP中的结对编程和沟通,帮助团队快速识别和解决问题。 **总结** 阅读《硝烟中的Scrum和XP-SCRUM与极限编程》可以帮助你理解这两种敏捷方法如何协同工作,提升软件开发效率。通过学习...