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硝烟中的Scrum和XP硝烟中的Scrum和XP硝烟中的Scrum和XP
硝烟中的Scrum和XP XP
硝烟中的Scrum和XP 大家看看翻译的咋样
硝烟中的Scrum和XP.pdf。这是一本技术书籍,从书籍里面可以学到一些学习思维和团队的思维 书籍
硝烟中的Scrum和XP高清敏捷开发介绍
硝烟中的Scrum和XP,学习PMP,学习Scrum, 项目管理等
硝烟中的Scrum和XP.pdf,高清带目录,希望大家能够喜欢
在本书中,作者Henrik Kniberg讲述了他在一年的时间里,带领40人的团队实施Scrum的过程。他们试过了多种团队尺寸(3~12人)、sprint长度(2~6星期),定义“完成”的不同方式,不同的backlog格式,各种测试策略,...