As a best practice, I organize Refinement meetings every second week of our 2 weeks long Sprints. This is really key in order to run an effective Sprint Planning event.
I prefer to use Refinement but not Grooming as the latter has a recent negative meaning.
At the invitation I send to the team for Refinement event, I briefly mention about the PBI that we will talk about. These are mostly the items those have the highest priority and have not been yet estimated. Refinement sessions could potentially get postponed if the team is working intensely to accomplish the Sprint Goal and short in time. That’s why it’s a good practise to schedule it to the very beginning of the second week in order not to jeopardize achieving the Sprint Goal.
When the team comes together, most of the time me as the Product owner ( alternatively my analyst collague) is briefing the team about the PBI that is likely to be scoped on the next Sprint. Ideally, the item(s) we discuss should have been created beforehand as an Epic in Jira board with the relavant sub-items. This allows the team to estimate the target items effectively. The refinement session is a unique opportunity to align the PO and the development team regarding the prior items of the PB. PO is supposed to explain to the team WHAT will be most probably included in the next delivery package. Following that, the team starts discussing HOW to implement it, better to say, HOW to bring it to the DONE state.
PO is expected to make a prepration before the Refinement session so that team’s valuable time is utilized at the top-most efficieny. In order to solidify the expected preparation, let’s assume two different types of Product Backlog Item definitions:
- The user will start from Point A, make a visit to Point B and return back to the initial point.
- a) The user will start form Point A. b) The user will go from Point A to Point B. c) The user will give 5 minutes break at Point B. d)The user will come back to Point A.
If you try to estimate the effort required to accomplish these 2 similiar tasks, obviously, estimating the second one will be not only easier but also more realistic. Also monitoring the progress via a burndown chart would be much more transparent if the items are divided into smaller pieces. I should admit that dividing a bulk task would require further analysis effort by the PO. Nevertheless, this extra study surely pays off later on down the road.
If the candidate task has been nicely divided into smaller pieces and the sizing (estimation) is done by using a technique like poker planning, the Refinement session achieves its main goal. At the end of the Refinement session, the development team has an overall understanding of the items waiting to be taken care of on the next Sprint. Once the current Sprint is over and the team meets for the next Sprint’s Planning event, the Story Points are already assigned to the candidate PBIs. Hence, the development team should simply pick the items in priority order from PB while bearing in mind the team’s capacity and velocity record.