Webinar Recap: Backlog Refinement Q&A

With Backlog Refinement, you can address many challenges teams face, like unpredictable delivery cadence. However, a lot of people still have questions around this (unofficial) Scrum event. This webinar will help clear things up!

In this webinar, Reese Schmit and Brian O’Fallon tackle your questions on Backlog Refinement, like:

• Why is there so little structure around Backlog Refinement?
• How do I sell Backlog Refinement to my team?
• When does Refinement begin? Is it continuous?

See below for our full webinar recording and transcription.

 

Transcription

Introduction

Brian: Hi there, my name is Brion O’Fallon. I am an Agile Coach here at Agile Velocity. I have been in the software world for about 20 years, and I have been doing Agile for about 10 years. I was in a small company that was acquired, and I was a Project Manager who was told to become a ScrumMaster. I did that and fell in love with it. For the last 10 years, I have been in all different kinds of Agile roles, including ScrumMaster, Product Owner, Manager, and more recently, an external coach who goes in and helps clients implement different Agile methodologies.

Reese: Hi, I am Reese Schmit, and I’m also an Agile Coach here at Agile Velocity. I’ve been in software somewhere around 15 years. Most of that has been in some form of Agile, W-agile, Scrum-erfall, “We do Sprints so we are Agile!” type of environment. In that time, I have worn many many hats: everything from QA to Tech Writer, UX Designer to finally ScrumMaster about 7 years ago. Since then, I have been coaching teams. I counted this morning, and I am somewhere around 50 teams give or take.

So in that time, I have seen many Backlog Refinements–a lot of good ones and a lot not so good ones. Hopefully, we can share some of the wisdom that we’ve gained over the past few years to help you guys get your Backlog Refinements back on track. So without further ado, Brian Fallon please take us away!

Brian: Before we jump into some of the tips, tricks, and common patterns we see out there in the field, I’d like to like to give a little context to what Backlog Refinement is really all about. At its core Backlog Refinement is a conversation between the Product Owner, who has a vision for the product and some specific requests of what they want the team to do, and the team who is actually going to be implementing it. We ask the Product Owner to come into Backlog Refinement with a clear vision of where they are trying to take the product and some specific “what” style requests. We need to have conversations about value and the requests of the team.  When the team can interact with the Product Owner and come to a common understanding with them, the team will also get a sense of how big the project is, and they can give the Product Owner that information, so the Product Owner can make an informed decision about what should be prioritized.

Reese: One of the things we see a lot is that Backlog Refinement is treated as a spectator sport. Everyone comes in, sits down, and it’s the Product Owner’s show from there on out. One of the things that we can do as a team to get really prepared for Backlog Grooming is… to be prepared. Honestly, go through the backlogs top few items and dig in. Whether that is thinking of questions, digging into the code, or going and talking to the rest of your team about the top items. That’s going to set you up for a really really collaborative Backlog Refinement.

Product Owner can set their team up for success by either sending out an email saying “these are the top things that are going to be in contention for Backlog Refinement”. If you are using something like Jira, you can set up some designation in there. Making sure your team has the opportunity to look forward is going to make Backlog Refinement successful for everyone.

Brian: It goes without saying that the Product Owner has to be prepared, but the team having context before going in can really help with that collaborative interaction.

Reese: If you walk into a book club and only one person has read the book, it is not going to be a great conversation, so really come in prepared.

Brian: The next thing that kills that conversation is having only one person driving the conversation. That can mean everything from a very Product Owner, presentation-centric way of doing things, but another one that we see a lot is one person who’s driving the tool. If you’re using Jira and you have one person with a keyboard in front of them, entering in all of the notes, and scrolling through the screens it’s almost impossible for the conversation to remain collaborative. Everyone just ends up staring at that one person as they struggle to find the right button or type up the last note. We really don’t want to have just one person driving. We need it to be a collaborative discussion.

Reese: One way you can do that is to give everybody a pad of post-it notes and a sharpie. When you are talking about acceptance criteria and people are asking questions, anyone can write it down. One of the best ways I have found to up-level your Backlog Refinement is to turn the TV off. If everyone is co-located, you can just turn it off. When you sit in front of a big TV in one of those comfy conference room chairs, you probably lean back and relax. That doesn’t create collaboration. Everyone needs to be up, engaged, and actually on their feet.

Write out the user stories on post-its and bring them in. Then the Product Owner is able to get everyone on their feet to look at the user stories collaboratively. You can even put up a white sheets of paper so that people can scribble out little mocks which creates a really awesome environment for the whole team to get engaged.

Brian: If you do use a tool, which almost everybody does nowadays, print out those user stories. Put them on the wall and have everyone go around with a pad of post-its and put up the acceptance criteria as you come to a shared understanding.

Brian: When we go through backlog items, we’ve noticed a couple things that are problematic. If the stories are not vertically sliced, that is going to make it very difficult to have a value-based “why are we doing this” discussion.

For example, if the item is giving a new, fun capability to users, it’s really easy to get behind the value we’re delivering. If the item is “insert database table here…add two columns… insert trigger.”, it is near impossible to get excited about it. This also makes it difficult to bring your whole mind and creativity to solving the problem, because you have really been presented with a component task.

Reese: The other thing I see a lot is that backlog items are too small. We want big meaty valuable things. Do you laugh when Scrum books say “about four to six items in the backlog for the Sprint?” No, that’s real, that’s a goal, those are big meaty things for the whole team to work together and collaborate on. When you are in Backlog Refinement, you are having a meaty rich discussion digging deep into “Why this thing is going on and what you can accomplish”, rather than “That button goes to there.”

Brian: It is hard to remain vertically sliced when we get so small. I know that you’ll get a lot of advice to slice backlog items as small as possible, and that may be an end state. but it’s hard, at first, to conceptualize something that small and still keep it vertically sliced. We’d rather you keep it vertically sliced and a little bit bigger.

Results: It looks like about 50% of you guys are at 3-5 Items.

Brian: If you are getting through fewer items than you want to, there are a few patterns Reese and I have seen out there. The first one is when the team wants to dive way too far into what’s being requested. And I know that that sounds a little at odds with what we were just saying a minute ago. We’re trying to have this rich conversation where the Product Owner is laying out the value and getting the team excited about the goal, but I have seen that sometimes teams get caught up in asking very detailed questions that aren’t related to the point. We’re trying to understand the value and the goal not rattle on minor points that need to be figured out as we get into the Sprint. The consequence of that is the discussion goes on too long, you lose people, and the engagement slips away. We want to have that discussion as long as it takes to make sure that we are all on the same page about the value of it, what we are trying to do, and the intent of the story. Once we are there, let’s cut the conversation off.

Reese: I’ve seen people trying to get answers to a lot of questions that are not going to change the size. We might want to have those answers before we start working because while it is pretty critical but it’s not going to change the size of the item

Brian: There will be other opportunities to talk about the details. As long as we can get to the intent of it and we can understand how to size it, we are giving enough information back to our Product Owner so they can make a great, value-based decision about priority.

Reese: We also see people digging into the “how”. If you are tasking out your stories in Backlog Refinement, then you are digging way too deep in the “how”. Save that for Sprint Planning, when you’re really about to dig in and start doing the work. I just had a conversation with a team this past week, and we were talking about how we pull ourselves back up. I used this analogy of cooking:

Reese: Have you ever cooked dinner for yourself?

Brian: Yeah

Reese: Have you cooked dinner for your family? Is that bigger or smaller than cooking for yourself?

Brian: Way bigger

Reese: Have you cooked dinner for a dinner party, say 75 people?

Brian: Oh yeah

Reese: How about a big backyard BBQ, bigger or smaller than the dinner party?

Brian: Much Bigger!

Reese: Did we talk about recipes? Did we talk about what food you are going to bring? We didn’t have to go to the store or do any of those things but you know whether it is bigger or smaller. We are not experts on cooking, but we are asking people who are experts at building software to size things bigger or smaller. So really digging into that how is not necessary to understand whether it’s bigger or smaller than the story that we just talked about.

Brian: What we’re really going for is just enough planning to give the Product Owner the information they need to prioritize. There will be more opportunities as a technical team to dig into the tasks required to do that job, but we don’t have to do it right off the bat.

Questions & Answers

Reese: We’re going to jump into a few questions from our CSM & CSPO alumni to give you guys a few minutes to put your questions in.

All other the meetings are very defined in Agile/Scrum (day, time, length) Why is there so little structure around Backlog Refinement?

Reese: It is not an official Scrum ceremony.

Brian: Yeah, it’s a little bit shocking because it will show up in every class you will ever attend on Scrum, but it’s really not an official event. Scrum is great at picking up things in the prioritized backlog, defining how we execute on them, and how to refine our product and process but it is pretty silent about how things get into the product backlog.

Reese: It says you need to spend up to 10% of your time preparing for the Sprint ahead but it doesn’t say how. So while it’s not official, it is a best practice to do a separate Backlog Refinement, outside of Sprint Planning. We know that we’re not very good at just coming in, being revealed a backlog, being told what it is for the very first time, and then committing and figure out how to do it all in one meeting. Separating that by a few days is going to give the team a much higher chance of success in their Sprint.

When does grooming session occur in a Sprint?

Brian: It should be during the Sprint. We recommend that it happen a couple days or more in front of Sprint Planning. This will give folks time to think it over, do some exploration, or give the product owner a chance to get clarifying questions hashed out so that you are ready to go by the time you hit Sprint Planning.

Reese: Some teams will do it on the off week of their Sprint Planning (for two-week Sprints). So, every Wednesday at 9 am we know we have a to be prepared for a meeting, whether it’s Backlog Refinement or Sprint Planning.

Who’s responsible for grooming?

Brian: The Product Owner is responsible for making sure there is a groomed backlog, but Backlog Refinement is a participatory event that the whole team–Product Owner, ScrumMaster, and everyone–should work on collaboratively. It is the Product Owner’s responsibility to make sure it happens but it is the whole team’s responsibility to join in and collaborate on it.  

What’s the difference between a Backlog “Refinement” and a Backlog “Grooming”?

Brian: New name for the same thing. It had cultural implications in some countries that were not positive so as the industry has migrated, we have shifted to calling it Backlog Refinement.

What if you have remote workers? How can you incorporate them into the meeting in an active way? What is the best way to enhance participation in a virtual conference?

Reese: Anything that you can do to create more of a collaborative environment for your remote folks is going to create a lot more success.

You could use some sort of online collaboration software like Google Docs or BoardThing. Anything that you can do to have everyone be able to input information. If one person is remote, sometimes it is better for the collaborative environment if everyone acts like they are remote. Meaning everyone has a keyboard to be able to input things so the whole room is not looking at a whiteboard while the speaker is behind all their backs and they are trying to collaborate with the one person on the phone.

Face-to-face communication is very important and any online collaboration software that you can use to do this will make a huge impact. We like to use Zoom and a conference room camera for our company meetings so that we can always see each other’s faces. I did this the other day with three people who were on the phone, and we were able to use a whiteboard. We got a really good camera and made sure that everybody could see our board. We wrote really big on the sticky notes, and when we were reading something off we would make sure to hold the sticky note up to the camera so that they could see. Through this tactic, everybody was really able to engage.

Brian: Another thing I’ve done, is sometimes the ScrumMaster, who probably isn’t as active in this meeting, will act as a scribe and make post-its on the behalf of the remote team members. That only works if there are one or two remote team members though. If everyone is distributed, then you should use an online tool.

Why not do a little bit of refinement every day?

Reese: That can absolutely work. I’ve had teams who spend 15-30 minutes after stand up every single day refining the new things that are coming into their backlog. They were doing Kanban, so it worked really well for them to have a continuous refinement process. If that is something the teams want to do, do what works for you guys. Do something, try it, retro on it, and make sure that you are updating it to fit your team’s way of working.

What are the “other opportunities” for the team to dig into the “technical how” of a task ahead of planning?

Brian: When we say Backlog Refinement is specific around creating a shared understanding of the value and intent of the story, and that it is not a place to go into the technical how, that doesn’t mean the team can’t go off and do some investigation.

I would caution you though. Digging into the technical how of a task ahead of planning makes me concerned that perhaps your stories are not vertically sized. If you need to resolve a technical approach in order to properly size something, that is legitimate. It shouldn’t happen too often but sometimes you will get a situation where, in order to be honest, you have to tell the Product Owner “I don’t know how big it is because I don’t know if we know how to do this.”

There are ways of resolving that, like spikes that you might do to look at a technology but just be careful. It sounds like potentially you are asking should we task out ahead of time and please don’t because you never know if that story that you think you are being helpful on and tasking out is actually going to be prioritized at the top of the backlog. Once you get into a groove, you’ll often times find that backlog gets tweaked, revised, and re-prioritized right up until the very end of the Sprint. Resist the temptation. Do the tasking in Sprint Planning.

Reese: Don’t always rely on putting a spike in the next Sprint. Then you have to wait to do the work until the following Sprint. Make sure you’re leaving a little bit of time between Backlog Refinement and the new Sprint so you’re not always booked up right into the very end of the Sprint.

As a ScrumMaster with a new or absent Product Owner, what is the first baby step I can take with coaching my new Product Owner on how to start refining without getting vacant stares?

Reese: You’ve got an opportunity to really help this person to become a really great Product Owner for that team. There are tons of books that they can read. (Mike Cohn’s User Stories Applied; Roman Pichler’s work, including his books and an amazing blog). You can also send them to a Certified Product Owner class that will give them a great foundation.

Absent of all of those things, just help them to really identify the who, the what, and the why on those things that are needed to get this feature or product out the door. This is going to be super helpful. Helping coach them to build a backlog, vertically slice stories, not be focused on technical specifications, and not translating a requirements document into user stories will help guide the Product Owner to build that backlog.

Would you incorporate your MVP’s in your backlog? What percentage?

Reese: Your backlog should definitely reflect the MVPs. I’m actually going to break MVP down a little bit. If we’re talking MVP in like the Eric Ries/The Lean Startup sense, in that we’re building the smallest thing that we can possibly build in order to learn something, absolutely. Your backlog should be made up of those experiments, and once you have determined what to build, that experiment has been proven, and you know which direction you should be going in, then your backlog is full of validated backlog items. You can now–with much more confidence–that these are the things that we can do to be successful with this product.

What should a PO do when a Sprint fails?

Brian: I bring that up in a Backlog Refinement meeting only because there are a few common reasons that Sprints usually fail: there was something inadequate in the backlog going into it or there were technical implementation questions that came up along the way. That is really worth digging into in your Retrospective to understand if there was something about the way the stories were understood or formed that might indicate a procedural improvement that you want to do in the next Sprint. In the case of a failed Sprint, Product Owners, be brave and transparent about it.

Is the PO aware of tech debt?

Reese: Technical debt is the corners we cut on the way to launching something. If we are going to have a mainatabale product in the market, then we should shore those corners up. We might have needed to get somewhere fast to learn something but we don’t want to keep that out there forever. If you start incurring too much technical debt, your velocity will eventually get to zero as the team swims in that spaghetti or pool of bubblegum and duct tape (which is the best way I have heard raging technical debt described).

The Product Owner should absolutely be aware of that, but it is the team’s responsibility to bring that up. In that time between Backlog Refinement and Sprint Planning, the team should go look in the code and see what is in there. If there is some technical debt that they need to shore up, then they should bring it up. That may end up being a separate backlog item or it may be a task inside of the story.

Could you explain a bit more on the 2 different types of definition of ready?

Brian: When we are looking at our stories in Backlog Refinement we are really trying to get the stories to a “ready” state, that the team could pull it in. One exception is if we understand the intent and the size of a story, but it is missing a particular item–like text that needs to be approved by legal or compliance. It is okay to say this story is going to be a 5, and we understand the intent, but please note that it is not ready. It needs that final component before we can pull it into the Sprint. Definition of Ready should be prominently displayed in your room when you are going through Refinement. Take lessons you have learned from prior problems and incorporate them into your Definition of Ready.

Reese: I have had teams use two Definitions of Ready, one was their gate into Sprint Planning. They also had a Definition of Ready when coming into Grooming. They did this for two reasons: to make sure the stories were ready for them to talk about and also as a barrier to the team, making sure they weren’t hyper groomed. The Product Owner wanted to make sure every single thought was addressed, and it didn’t leave a lot of room for the team to be innovative and bring their brains.

What if you are acting as both the ScrumMaster and the Product Owner? (I know it’s taboo, but sometimes it’s a reality.) How would that work in a backlog refinement?

Brian: It is a real challenge. During Backlog Refinement, you are supposed to be facilitating a meaty discussion around what the story is all about. However, as a ScrumMaster, you are also supposed to be enforcing the process that makes sure the team is being honest and open about how big the effort is. It will be very hard to keep both of those hats on simultaneously and not find yourself swayed to pushing the team into making smaller sized estimates in order to facilitate moving down your backlog.

Just how much should you fear a failed Sprint? How do you define a failed Sprint? Should a “failed Sprint” be celebrated as a learning opportunity?

Brian: The fear is that if your organization doesn’t allow people to stretch and fail or that you are going to sandbag. If you are going to suffer consequences of not completing your forecast, then any smart, quantitatively sophisticated person is going to make sure that they put enough of a buffer in there that it doesn’t go bad. I agree that failed Sprint can be learning opportunity. I wouldn’t even call it a failed Sprint! To be honest, that seems a little extreme. The lingo implies that if you are 10% off it is a failure, and it is not. It is a learning opportunity like you said.

Reese: You should dig into those things in Retro. Find out what happened–maybe we brought in things that weren’t quite ready.  That may be an opportunity to create a Definition of Ready. Maybe, as a team, we didn’t take any time to dig into the code before the Sprint. We know that you’re going to discover things during the Sprint, we just don’t want it to be a catastrophic discovery. We want small things along the way. 

Brian: But you will have those catastrophic discoveries. And when you do, I really hope that your organization can change the way it looked at it and learn something. When you go to a Sprint Review, don’t look at it as a demo of delivered items on a commitment. Look at it as a learning opportunity.

What are ways to win hearts and minds when the team is actively contradicting the best practices of Backlog Refinement? (Insisting on digging into the how, writing tasks instead of stories, etc.)

Reese: Mostly, we see that happen when there is a misunderstanding of what the intent of Backlog Refinement is. It’s important to show the value. Show them it is possible to size things without digging too deep into the “how”. Try doing an activity with the team where they are sizing a lot of items at once and not digging into them. Show them how it can be done, and they can start seeing the value.

Should stories be assigned in Backlog Refinement?

Brian: No, they shouldn’t be assigned in Refinement.They shouldn’t be assigned in Sprint Planning. What we are doing here is having a team understanding. It is a team forecast of what they can do. Don’t assign it to a single individual or else folks who aren’t assigned to that story won’t stay actively engaged.