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 ScrumMaster 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 ScrumMaster 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 ScrumMaster must be sensitive to the meeting producing a workable result.
In Scrum, there are totally 4 meetings that you need to know:
