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:
Prior to the refinement session:
During the refinement session:
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.
Just an agile-dork writing about dorky agile things.