Refinement Best Practices

VALUE:
The intent of the refinement ceremony is to ensure the backlog remains populated with items that are relevant, detailed and estimated to a degree appropriate with their priority; and current understanding of the product and its objectives.

The team (Product Owner, ScrumMaster, Developers) meets regularly to refine the product backlog, which can lead to any of the following:

• removing user stories that no longer appear relevant
• creating new user stories in response to newly discovered needs
• re-assessing the relative priority of stories
• assigning estimates to stories  (in the form of Fibonacci* story points, t-shirt/animal/vehicle sizing etc.)
• correcting estimates in light of newly discovered information
• splitting user stories which are high priority but too coarse grained to fit in an upcoming iteration
• determining if research spikes are necessary before a story can be worked on

 
 
BEST PRACTICES:
Prior to the refinement session:

• The Product Owner prepares the stories by adding descriptions, clearly defined acceptance criteria and other appropriate artifacts. This ensures the story is well understood by the PO and that they are prepared. 
• Once the PO has a good idea of which stories they want to discuss, they forward a prioritized list to the team. The team can review the stories beforehand and gather their thoughts and questions; thus increasing the effectiveness of the meeting. 

 
During the refinement session:

• The PO summarizes what she expects to achieve so the team has a clear understanding of the goals of the meeting.  This could simply be something like “I’d like to walk out of this session with 4 groomed/refined stories.”
• The Product Owner focuses the team’s attention on the first story, using the prioritized backlog. The story is reviewed and the team is encouraged to collaborate, ask questions, suggest modifications and provide feedback. 
• Once all concerns/questions/comments are addressed, the Product Owner requests a high level story point estimate (relating to size & complexity), using the Fibonacci sequence.  Story points allow POs to quickly size features and consider the sprint plan without getting bogged down in implementation details. 
• If there are team disagreements, the ScrumMaster reiterates that story points should be decided by consensus and opens the floor for the team to reach a resolution.  Some level of consensus should always be possible.
• As a general rule of thumb, each story discussion is time boxed (I like 12 minutes per story) to keep the conversation moving and not get bogged down in the implementation details.
• Not all refinement sessions will be straightforward and uncomplicated. There are times research spikes are identified or stories need to be further split, and story points just can’t be identified.
• Although the PO needs to recognize their meeting goals, they should be adept enough to keep the session moving and organized enough to return to the following session, with the new spikes/stories in hand.

 
More information on estimating stories based on the Fibonacci sequence can be found at: http://www.allaboutagile.com/how-to-implement-scrum-in-10-easy-steps-step-2-how-to-estimate-your-product-backlog/
 
TIPS FROM OTHER AGILE PRACTIONERS:
 
- My team meets daily for an hour; we alternate Design meetings with refinement sessions. Yes, this is time consuming -- however, since we’ve already discussed the story implementation beforehand (during Design), we’re able to efficiently identify story points and tasks during refinement.
- Having 2 refinement Sessions per week keeps us from falling behind. In addition, I have a nice set of stretch and future sprint stories to pull from.
 
- For any team members off site, we use either Pointing Poker, Planning Poker or Plan-It Poker. (All are free, and defaults to Fibonacci point values but can be customized ahead of time). 
- I like this because 
• Team members can vote when they are ready and there is a button to ‘Show Votes’ all at the same time. 
• There is a timer that re-sets after each ‘Clear Votes’ has been triggered (optional)
• There is the option to join a session as an Observer.
 
- I always try to have an Acceptance Meeting at least a day or two before each refinement session to make sure there are no questions in regards to testing.  I always book it, but we end up cancelling if we don’t need the time which is about 80% of the time. If we are all on the same page, I know that the refinement session will go smoothly. If we’re not, I at least have some time to add more details or even split a large ticket into smaller tickets before the refinement session. Also, having them aware of the tickets is almost as much detail as I am will allow him to help me timebox in the refinement session so we stay productive.
 
- The QA on my team reviews the stories before the developers see them, so they can verify that the acceptance tests are captured and that the story is testable.
- I send the list of stories to the team about 24-48 hours before refinement.  They review them and reply all, responding with questions or red flags about the stories.  This lets us identify stories that require a design session or other technical planning and are not yet ready for refinement.
- During the meeting, each story is timeboxed – 4 minutes for discussion, everyone throws points, then 2 minutes to discuss and agree on points.  If a story needs more than 6 minutes, it’s not ready for backlog refinement and we hold it for a design session.
 
 
**Just an additional note **
You may have heard this ceremony referred to as “Grooming”, but recently, that word has been given a pretty bad connotation. Which is why it’s “Refinement” is the more accepted substitution. You're welcome.