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.
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.
扫一扫
865
被折叠的 条评论
为什么被折叠?
到【灌水乐园】发言
