What can be delivered in the Increment resulting from the upcoming Sprint?
The Product Backlog is examined and the Product Owner makes changes so that it is prioritised with Bugs prioritised amongst Stories.
The Product Owner is then asked to group the top ranking Bugs into Stories for inclusion in the Sprint; see this rule.
The Team are then advised of their resourcing for the Sprint as there may be additions, subtractions, leave or public holidays which are different to the previous sprint. Considering their previous record and their current resources, The Team decide on the number of story points that they will deliver in the forthcoming Sprint. When The Team are not currently co-located this is often done by voting on an IM group, and discussed until consensus is reached.
The Team then size (assign Story points to) Stories starting at the top until there are more than enough Stories to fill the Sprint.
The process of sizing is somewhat formal. Either using cards or IM (essential if not co-located) the team vote privately on the size of the story. They can either use T-shirt sizes of XXS, XS, S, M, L, XL, XXL and XXXL or their equivalent number of story points for which we use the Fibinacci Series of 1/2, 1, 2, 3, 5, 8 or 13, 21 Once the differring votes are in, the Scrum Master asks the smallest and biggest voters to explain the reasons for their vote. Assumtions and omisions are quickly identified through discussions and the Scrum Master encourages discussion until consensus on the Story points is reached. Any story voted at 13 or higher should be broken down into smaller stories; re-prioritised by the Product Owner and re-sized if necessary.
- Figure: A sample Sprint work item based on the Microsoft Scrum process template for TFS
Once enough stories are sized, the product Owner is given the opportunity to re-prioritise now knowing the relative sizes. If more stories need then be sized then they are. The Scrum Master keeps everything going and facilitates negotiation between The Team and The Product Owner until final priority is confirmed and The team commit to a number of stories and the meeting concludes.
This meeting should be timeboxed to an hour for every week in the Sprint. However, the Scrum Master must be sensitive to the meeting producing a workable result.
How will the work needed to deliver the Increment be achieved?
To answer the second question the team create tasks, with sub-tasks where necessary, for everything that needs to be done to implement the story. Every task and sub-task should be given an estimate in hours and the same value placed in the Remaining field.
No actual work on the Sprint should start until this planning is complete. It is these Remaining hours that determine the first value in the burndown chart which sets the Sprint on its way to completion. There must be no omissions or The Team will start without an accurate burndown and we all know that "The Team is nothing without a burndown".
The Team should also ensure that the burndown chart is working and will be automatically sent to all members of The Scrum Team overnight.
The meeting concludes when The Team reports to the Scrum Master that their planning is complete and they are able to display the burndown chart.
Ideally this meeting is timeboxed to as many hours as there will be weeks in the Sprint. However, this planning is so essential that it must continue to completion outside the meeting if necessary.
It is not essential for the Product Owner or the Scrum Master to be present for the whole meeting but they must be available for consultation. The Scrum Master should formally close the meeting.
Once this meeting is finished, the Scrum Master should email the Product Owner with a forecast
In Scrum, there are 4 meetings in total that you need to know about: