Sheila's Blog

The Sprint Planning meeting is used to identify the work for a Sprint, and prepare the Sprint Backlog which details the estimates of time needed to accomplish each task.  The Product Owner prepares for the meeting by making sure the Product Backlog is up to date (add/describe new requirements, prioritise the items and make sure the estimates for each story are current).  The planning meeting can last about 2 hours for each week of a sprint – roughly half the time for discussing requirements, the remainder to break stories down into tasks.  At the end of the meeting, the team has committed to completing the items in the Sprint Backlog.

The team identifies their capacity based on the number of people available, less holidays etc for the sprint.  The wrong workload will cause the team to burnout.  About 60% utilisation is normal.  Starting with a gross capacity of hours, about 10% should be allocated for the scrum process (which will reduce over time).  Keeping the product and sprint backlogs up to date can take another 10%.  Maintenance of existing code should be allocated some time.  Finally a buffer should be applied that will be reduced over time as the team starts to estimate more accurately.

The team picks the top priority stories from the Project Backlog that it (without influence from the Product Owner) believes can be completed in the sprint, and drafts a Sprint Backlog to work from.  The teams asks questions of the Product Owner for each story – possibly agreeing acceptance tests/test data or UI designs as part of this so that everyone is clear what the criteria are for the story to be accepted as completed.  The team then discusses and breaks each requirement down into tasks and volunteers or assigns the tasks.  Tasks should be a maximum of 1-2 net days work.  This is to make progress clearer on a daily basis.  The team stops committing to tasks if the availabilty is consumed, or the knowledge/skill set of the team members is insufficient.

If uncertainty is high, dependent tasks in one sprint should be avoided.  Task estimates should not be padded – the buffer takes care of this.  The team is going to be measured by meeting their committments, not the time taken so it’s important to improve estimates as you go along.

Tags:   scrumNo Comments