Scrum Backlog Grooming and why

In purist scrum planning you can plan a sprint, which is a time boxed event of development/work of anywhere from a week to a month, during what is called a Sprint Planning Meeting.  These sprint planning meetings can last up to 8 hours for a one month time box sprint.  That is a long time to plan all the work that is going to be done in the next month.  Not to mention that perhaps things will change during that time that will make some or much of the planning irrelevant as time goes on.  This is possible in situations where consistent work hasn’t already been done with definitions of done completed and estimates by the dev team provided.  Where there has already occurred plenty of work that can be looked back on and estimated accurately going forward you don’t necessarily run the risk of planning that is useless since you already have a good idea of what it is going to take to do the work.

All that said how can you potentially cut down on the amount of time a sprint planning meeting will take?  Answer: Backlog grooming sessions.  Ideally these sessions happen regularly so that the sprint planning meetings are both shorter and more effective.  These sessions are meant to improve the product backlog.  In it you can:

• Write/update user stories
• Decompose a story into several stories that are too big to realistically be done in a time box sprint
• Devs often love as much detail as possible to accomplish a story and so adding more definition or rewriting poorly constructed stories is useful
• With the dev team estimate the backlog items that haven’t already received estimates
• Add acceptance criteria and flush out the definition of done
• Assess deeper (lower down on your product backlog) stories/backlog items and do long term planning with domain experts or just when those items can be done.

Yes it is important to stay focused on the current workload, but don’t get too hung up on not looking beyond the current sprint if needed.  Just because you’re on schedule for the next release doesn’t mean you can’t proactively look to the future and see what additional research, domain experts, or technical hurdles may need to be addressed now before getting to the future.

So good things to do during a grooming session:

Have a stated goal.  Everybody hates meetings that drone on and don’t actually accomplish anything.  Devs especially hate this since they’re up against what they’re already working on and being in a pointless meeting just takes them away from the work they need to get done now.

At the bare minimum hold your grooming session a few days before the sprint planning so people are familiar with the backlog and can hit it hard during the actual planning session.

If you have stakeholders present, limit them to just a handful.  Don’t have 10-20 people in the meeting because they often don’t know the rules of scrum, will make things chaotic, plus people check out when there are too many people in a meeting anyways and input by default is minimized by the sheer size of the group whereas smaller groups can have more people contribute.  Go figure.

Implementing regular backlog grooming meetings helps sprint planning meetings go better and more efficient, familiarizes the team with what is on the product backlog, which then leads the team to committing easier to sprint goals/commitments.