The Ultimate Guide To Sprint Backlog

The sprint backlog refinement meeting is the last opportunity for the team to inspect and adapt items before committing to a sprint. Not only should it be held shortly after the Product Owner Workshop, but should also happen at least once every other week. Some teams hold refinement meetings even more frequently than that. The goal of these meetings is to get everything from “ready” to “testable” and reduce the number of items in the sprint backlog by 4-6 per meeting. In this article, I’ll go over several ways that you can facilitate a powerful refinement meeting and understand who can execute the work of the sprint backlog.

This is part one of a two-part series about Sprint Backlog Refinement. While it will make sense alone, you may want to read the other article too.

NEED TO CATCH UP?

This is part one of a two-part series about Sprint Backlog Refinement. While it will make sense alone, you may want to read the other article too.  Sprint Backlog Refinement – Part One: The Basics

The sprint planning meeting is a time for planning and commitment. It’s when you take the product backlog items that will be completed in the sprint, then decide which ones to choose for this sprint. You should also estimate how long it will take to complete each one (and get agreement from the team), assign them to team members, and note dependencies between items if you think they might affect the order in which you’ll do them. You then commit to completing all of these items within the next 30 days.

Sprint planning is not the time for making detailed technical decisions (that’s what spikes are for, if necessary), but it is a time to make sure everyone understands enough about what needs to be done so that their work can begin. It’s also an opportunity for team members to ask questions and clarify anything they feel they need to know before beginning work on their chosen tasks.

If this meeting takes longer than planned, it usually means your product backlog is either poorly groomed or large enough that there just isn’t enough time during the sprint for everything you want to get done. Either way, that’s a problem you should probably solve.

Now, there are special cases where the product owner may not be present at an initial sprint planning meeting, but I’ve never come across one that didn’t eventually end up with the product owner getting dragged into it. When their absence is intentional or if they won’t ever need to attend these meetings in the future because everyone else knows what needs to get done and doesn’t require their input, you’re either working on something too small to interest them or much larger than your team can handle. Don’t start off your relationship with your PO by frustrating them—you don’t need me to tell you how bad of an idea that is!

A common mistake made by both new ScrumMasters and inexperienced product owners in agile is to assume the PO knows nothing about the product, or any of its technical details until they’ve been in their role for a good while. This causes them to be afraid to take on the PO role upfront because they lack confidence in their ability to understand what needs doing. My advice when solicited is always that you can’t learn everything about your product during crunch time, but that’s no reason not to start being proactive with your product owner if that’s who you have.

Now remember this is just an example, I’m sure you all know how it goes in real life though! If The Company Is Full Of Experts Then Your Product Owner Might As Well Be A Mythical Creature Too. You may have guessed where this is going. I hope you haven’t guessed it already, because that would be depressing.

If you have a team full of experts, then your product owner is also one of those experts. Let’s take the example above with the PHP developer who has been working with MySQL for seven years. They’re experts too! The question now reduces to how much time can they spend on learning about this new role? Assuming they are successful in their current project and aren’t burned out or overworked, what happens next month when there are three projects starting at once? Will they be willing to devote the same time to understand this new role as they did before? Do you really want them doing this or should they perhaps switch back to writing code instead?

So you’ve found an expert, managed to hire them, and now they’re starting their new job. Great! But what happens when the first project they were assigned finishes? What about all those other projects? Have you planned for this transition? Have you considered what it will take for this developer to switch focus from writing code to performing business analysis or testing? Everyone thinks that hiring an expert means you can just tap them on the shoulder and say “switch!” Unfortunately, this is wishful thinking.