Product Backlog Refinement
The product owner meets with the team to discuss stories coming up in the product backlog. The product owner will share the current known priority and may ask the developers for help in determining the relative cost and risk associated with any new items or items for which more is now known. The Scrum team is also asked to give input on the sequence of the work and is encouraged to suggest ways to optimize the order in which work is done.
The Scrum developers will estimate any new stories that have been added to the product backlog in this meeting. They may also re-estimate any existing stories in the product backlog based on new information they have learned during current and past sprints. For stories that cannot be estimated, the team may add a story to bring into a future sprint called a spike. Spikes allow them a set amount of time to research and explore some unknown factors about an upcoming story. Keeping the stories in the product backlog estimated and in priority order is essential, as it gives the product owner and the business insight into approximately which features will be completed by a certain date.
The duration of the product backlog refinement (release planning) meeting will vary depending on sprint length. As a general rule of thumb, the team should allocate one to six hours to this meeting, more time early in projects and less time as projects progress. As an example, at the beginning of a project using two-week sprints, six to 10 hours may be allocated for this meeting. As the project matures, this time may drop to as low as two to four hours per sprint.
This meeting should be timed to occur toward the middle to end of the sprint as illustrated in the diagram below. Please see this page in the resources section for a detailed fourteen day sprint timeline.
For a two-week sprint, the second Tuesday or Wednesday would be the best time for the meeting to occur. For a four-week sprint, late in the third week or fourth week is best.