Sprint Backlog Grooming

Sprint Backlog Grooming

Now, this is an event not in the guide but one I have used successfully and one I’d recommend you consider; it’s a Sprint Backlog Grooming review. I hold the review meeting a couple of days before Sprint Planning, it can take between 1 or 2 hours to complete. Attendees include the business stakeholders, business analysts and the event is organised by the Scrum Master. The purpose of this meeting is to plan for the upcoming Sprint with internal stakeholders to ensure the business value of the tickets chosen for the next Sprint are still valid and they are to proceed. It’s good communication to ensure the entire internal team is on the same page before going into Sprint Planning. There is nothing worse than senior business stakeholders starting to query tickets in Sprint Planning in front of your development team. They’ll throw the event off on tangents and undermine the product owners authority.

So use a Sprint Backlog Grooming session to provide that safe zone for these discussions. The development team is free to join and we may include them if we want to discuss a future story in more detail, but I use this a chance for internal stakeholders to discuss their requirements.

As a Product Owner, I’ve also embraced the concept of being a servant-leader, I can’t know everything and I have to rely upon the experts around me for advice and direction at times. That’s how we all come together as a team and build great products.

Some will say this is wrong, but the reason I introduced this to allow the internal stakeholders the chance to discuss and agree on their top priorities for the next sprint. I could also ensure tickets were fit for review before going to Sprint Planning.

Sometimes tickets will need further refinement, explanation or acceptance criteria. In large teams, tickets will be produced by business analysts, customer support and the BAU production team, and not always through the product owner. It’s a chance for internal stakeholders to discuss their needs and be questioned about the priority or business value, without them being called out in front of the full team. It allows everyone to be heard and respected.

These internal discussions can become quite heated, with stakeholders arguing for position, grandstanding and berating the slowness of delivery. Some department heads are notorious for using this valuable time to use their power to try and influence decision-making and undermine the product owner’s authority.

I don’t find it productive for the development team to hear this or to be in attendance at those sessions. So I give the stakeholders their opportunity separately, which ensures when we hold Sprint Planning that session goes so much smoother; with fewer interruptions, no arguments in front of the team, and total focus on the development team, backlog and the sprint goal.

TIP: Product Backlog grooming is best undertaken before each Sprint starts, and you should be refining, adjusting and prioritising the next Sprint while one is in development. Product owners should keep on top of it constantly because Sprint Planning has a habit of coming around very quickly. Also, don’t do the grooming in isolation, discuss items with stakeholders, business experts and the development team too.