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
