Purpose of backlog refining:
- Prepare stories for planning
- Provide Product Owner with a rough estimate to aid their planning
- Breakdown epics into manageable stories
- Verify stories take us towards our goal and fit with our vision.
- Identify Spikes
When?
Refining should happen for at least 2 hours each sprint to stay on top of the backlog and ensure that there are sufficient stories estimated to be ready for planning – preferably a number of sprints ahead. (early in a project more time may be needed to get ahead)
Who?
- Product Owner
- Scrum Master
- Entire Development Team
Before you begin
Product Owner should order backlog by his current perceived priority.
Agenda
The Agenda is the backlog, move through the stories one at a time estimating or breaking down epics until the timebox has expired. (or all stories in backlog are estimated)
Timebox
The Scrum Master (or designated facilitator) should ensure that the meeting is time-boxed. Refining is tiring and has taken us away from the current sprint. Keep to the allocated time and schedule another meeting only if it is necessary.
Focus
The Scrum Master must ensure the discussion remains on topic. If a discussion is getting into deep detail on the solution it is likely you are off topic. The goal is to give a rough relative estimate, keep discussions to a high level. If the answer to a question wouldn’t alter your estimate you probably don’t need to ask it.
Estimates
There are a number of techniques for estimating PBIs, some teams use relative story points, some use T-shirts. The value in the estimates is to the Product Owner and not the team – although there is some indirect benefit.
Story estimates should not be confused with Task estimates which occur at Planning Sessions. Estimates should be of the relative size compared to other stories (it is not a measure of complexity). Many teams find it useful to identify an initial series of stories to use as your benchmark, or to create a datum to guide estimates.
An proper estimate is the relative size of a story to meet the definition of Done, including any requirements for documentation, testing and delivery – i.e. the package not just the coding.
Note: Estimating is tough! But it is not unique to Scrum, there are dozens of books on estimating software development. Scrum takes a view that estimation by a cross functional team is better than estimation by a single individual.
Story Breakdown
The refining meeting will often identify ‘Epics’ or stories that are too big or complex to estimate or to fit in a single sprint. A skilled ScrumMaster can help the team breakdown stories into smaller slices that still have business value, it may be necessary to arrange specific story-writing sessions for some of the more tricky stories. There are a number of different techniques that can be used to break down stories.
Note: Story writing is tough! It will take time to get used to story writing and to find a level that suits the team, it is an acquired skill, and there are many techniques. A good Scrum Master may make the process a little easier.
John Yorke 