Team Genius Audio · Let’s Get Real About Product Backlog Refinement – Team Genius Audio TGA002

Summary

Your team’s proficiency in Product Backlog Refinement impacts every aspect of your team experience and your product flow.

Getting this activity to a smooth experience is hard. It is easier though when avoiding some common issues, the biggest of which I’m addressing in this episode.

• Refine enough work for ~1.5 delivery cycles (a.k.a. Sprints) finely
• Refine coarsely the work for the following ~2 delivery cycles (a.k.a. Sprints)
• Review your Sprint Goals and your progress on your Product Roadmap
• Establish some way of forecasting your delivery rate
• Refinement is a whole-team activity, and it is a natural part of product development
• Refinement not only is the space for ideas for solutions to existing user needs, and ideas for potential future user needs
• Refinement is also the space for the team to build a shared product understanding.

Full Transcript

“Hello, my name is George. Thank you very much for tuning in. 

I come to you from a background of about 20 years of teamwork in digital product development. The first 10 were pre-modern working practices. The last 10 or the second 10 have helped me to learn more and more, year by year, about things like scrum frameworks like scrum and other delivery approaches. 

How does Product Backlog Refinement fit into your Scrum practice?

When it comes to our work in teams, there is one activity in the Scrum framework that is not an event, is actually officially called an activity and it’s very, very important. If you’ve ever talked to me about Scrum and your practice, it has definitely come up and I’ve got quite a few stories to share.

One of them is when we were working across two teams on a very, very ambitious initiative together with a client and we were structured in a way where we had to do refinement for both teams at the same time. That meant we needed to include almost 20 people in it. No matter how good you are at facilitation, it’s going to be a challenge. There were certain issues that we really were unable to iron out due to how we were structured as teams and we were trying to change that and ultimately it happened, but not for a few months.

 

It was really, really challenging so that was probably the one activity that was filled and filled with learning opportunities…

…I got to contribute a lot, I got to learn a lot from other contributions of other people on the initiative but we all knew that it didn’t have to be that hard. 

Depending on how your team is structured that in itself can have a big impact on the work that you need to do in order to in your minds and in your sketches and designs create the product before you are ready to come together in a sprint and bring it to the world. A different story was when we worked in a very small team and we literally only had one developer, one designer and one user experience designer. So one visual designer, one user experience designer with a product owner and me as Scrum master and that was it. You can probably guess that refinement was pretty smooth and pretty straight forward. The most important thing is that we did it. 

Firstly, let’s go back and work out what is the purpose of Product Backlog Refinement?

It is the activity that is necessary for the team to come up with the solutions for the user needs that we’ve identified that we want to serve, aka features or whatever you might want to call it. But there is something that we need to create that solves a need of the user or addresses a want of the user and we need to create something. So Product Backlog Refinement is the place where as a team, we’re working that out and we’re figuring out what’s the ideal way to do that. Not necessarily the best way, we will never find that but the ideal way for right now and right then based on the information that we have available. It is a very, very natural part of product development. 

Product development is not just sitting down and creating code or creating visual artifacts or whatever else might be required in your practice.

The thinking about it, the ideas about it, the alignment around the ideas, the exchanging of different ideas and coming out with something that’s even better as a combination of different ideas, that is what is required in order to create that. That is, also, if we think about the realms where the product exists is where we still have a lower cost of change. Cost of change is the highest when the user has experienced your product, not even the product itself, is when the user has experienced the product. That experience is very hard to change. If we ship a suboptimal product and the customer or the user uses that, that will be a difficult experience to come with a great sensation afterwards. 

Most people talk about how to change and they talk about the product once it’s created in code, I talk about the product experience, the customer experience. 

That’s when it’s the hardest to change. Shortly followed by when it’s out there and shipped and in the hands of the users of course. Before that, where does the product exist? It exists in code artifacts, it exists in your product backlog, in visual sketches, in visual designs, everything that is documented in any sort of way, anything that has been materialized or manifested if you will, outside of the minds of the team. So then before that is through the conversation that a team is having and before that is in the ideas of the team members. So in the ideas of the team members that is the lowest cost of change shortly followed by when the team is going through Product Backlog Refinement and collaborating together in order to come up with what they want to create.

So it’s not only a natural part of the product but is also necessary because that’s where we still have a reasonably low cost of change if we want to react to new information or we want to change our minds or through the collaboration the team comes up with an even simpler solution in order to create the same effect. It is one of our agile principles. Simplicity, the art of minimizing work not done. I think we’ve covered the basis around the purpose of Product Backlog Refinement. The impact of practicing ever better the product refinement can be felt in literally every single Scrum event out there.

 

If your Product Backlog Refinement is going well and you have a tidy nicely flowing product backlog item creation flow and refinement flow…

…then you will notice that in the sprint planning because you can actually do proper planning that is enjoyable and effective and you won’t have to spend any time in the beginning to remind everybody on what the items were and finding out that they actually need to split them down more or whatever it might be required all of which are things that aren’t part of planning. So your planning will go smoothly, your daily Scrum will go smoothly because all the items are as clear as they need to be in order to start the work in earnest. Therefore the flow of creation will go better and you will have a better sprint review because you’re able to ship items, to create items more smoothly and with that you will also have a better sprint retrospective because you actually have more successes to draw on and to inspire you to go further that will motivate you as a team, right? So, good Product Backlog Refinement can be felt everywhere else in your Scrum practice. 

 

Then after that, where are we going to go? We’re going to go to when you might have Product Backlog Refinement? Now, there is no one way to answer that question. It can go from a little bit every day to larger chunks of time. The one thing that I would steer you away from is to have one large block of Product Backlog Refinement somewhere in the sprint. Usually it takes up too much cognitive capacity and is a very draining activity. So trying to do it all in one go, I haven’t seen that working, it’s usually a one time attempt and everybody thinks it’s just too painful, let’s not do it this way, let’s split it up in at least two sessions. So in my experimentation, I found that one large block doesn’t really work. It also doesn’t make much sense because you have very little opportunity to react to change and to come back together as a team.

 

So I would definitely steer you away from a one sprint refinement session unless you have one day sprints…

…I suppose one Product Backlog Refinement might make sense but I’m talking about the majority of teams who have usually two weeks, I’m seeing a bit more uptake of one week sprints but in those cases, one is not enough and you might wanna split it down so that you have more opportunity to respond to change and redefine more effectively than you would with just one large chunk event. So we’ve got the frequency and the timing. I’ve worked with a few teams who just wanted to do it a little bit at a time and they would do it after the daily Scrum and stick around and refine product backlog items. 

The question that leads us to is how much Product Backlog Refinement do you need to do?

Well, it’s linking a little bit to the purpose. I actually haven’t made all that explicit. We want to get the product backlog in a state where we have enough work to pull into the next sprint and a bit. It doesn’t happen often but it happens sometimes that things change a little bit or things go very well during a sprint and the team is able to pull items into the sprint and start them although they weren’t actually originally planned to be worked on in the sprint. So it’s always good to have a few additional ready items in the bank, in the product backlog, ready to be worked on. Does that mean as soon as you’re there and you’ve got your one and a bit sprints worth of product backlog items you must stop? No.

 

Product Backlog Refinement is also an opportunity to look a little bit further ahead and start breaking down those even larger items…

…even more uncertain items that are out there, but you want to be very mindful of how much time from the team everybody is investing in order to do that, right? Because you want to continue to break items down, but there’s no need to go all the way through the product backlog if you happen to have a very long one, which isn’t really advisable anyway, but let’s say that you have a long one and there are very good reasons for it. It does not need to go to the complete end of the list, right? The product owner can be ruthless with the bottom of the product backlog outside of Product Backlog Refinement and dealing with the stakeholders who might’ve requested some items and help them see why a certain item isn’t fit for the product backlog for one reason or another. 

That hopefully gives an indication as to how much refinement to do and how you go forward. 

When it comes to participation in Product Backlog Refinement, I’ve got to experiment with a few different models. Generally speaking, it’s always the Scrum team. It is really useful for everybody in a Scrum team to be part of Product Backlog Refinement so that the collective product knowledge, holistic product knowledge, continues to evolve in the collective mind of the team as a whole. There are exceptions of course, the senior team doesn’t have to be together for everything, but for the core Product Backlog Refinement I think it’s a really good idea, it’s always been working well, in favor of the team for that to happen. But of course, if there are smaller things that need to happen from time to time when the team is coming together. So for example, some developers need to collaborate on some gnarly items a little bit more closely, more deeply with user experience designers and there are some things to work out where the whole team’s time is too much of an investment, then they will take that offline and bring it back and let the team learn what they’ve discovered. Again, that’s another reason why it’s useful to have more than one Product Backlog Refinement activities during the sprints to account for those types of things. 

I’ve got to experiment with representative models where one from each craft participates in the Product Backlog Refinement. 

It has worked okay but actually what we were aware of and what we’ve made explicit is that the fact that there was a feeling that was necessary or desired pointed to too much delivery stress and delivery load on the team. We tried to remedy that, but anyway, that’s a different story. The one thing to bear in mind with such experiments is that anything that happens in Product Backlog refinement has to be shared back to the rest of the team, so people don’t fall out of the loop of the development of this collaborative and holistic product knowledge in the joint and in the overall mind of the team. So experiment with caution, I would say. Ideally, let the whole team really work together to build up the collective knowledge of the product in their mind. 

Now, what do you do in Product Backlog Refinement is the last and biggest section. 

There are many things here, I’m only going to touch on the highlights. One key question that comes up is, do you estimate or don’t you estimate? You can experiment with both. I got to experiment with both. Both approaches have been working in those scenarios where the team estimated with story points, we use planning poker to help the team learn story points. At one point, they had aligned and calibrated their team-wide estimation using story points and came up with pretty much the same number almost for every product backlog item. At which point product backlog planning poker, aka estimation poker as I would like to rather call it, because it’s got no place in planning, but every place in refinement or in estimation. And then you just drop it, right? Because the technique has done its duty, it has fulfilled its purpose. So don’t worry about it anymore. Generally speaking, is it necessary? Is it a requirement to estimate? No, it’s not, it fulfills a purpose. You need to be aware of what the purpose is. You could as a team collectively decide not to estimate as long as you ensure that the product backlog items are small enough, right? 

Invest criteria are still very useful that each product backlog item needs to be independent, negotiable, valuable, estimatable, sized appropriately aka small and testable. Sized appropriately aka small does mean that a team should be able to turn around an item in a day or two roughly speaking, right? So you can work out what your sprint length is and if, as a team, you work on an item for a day or two that gives you a very rough indicator as to how many items you might want to break things down to, to have a reasonably good chance of completing them in a sprint in service of achieving an overarching single sprint goal. Then over time, the number of items in your sprint backlog will give you an indication of your throughput and velocity and allow it to forecast with that in lieu of using story pine. So both are definitely possible. Just be sensible about which approach you use.

If you experiment, make sure you have an actual hypothesis, how you test it, how you validate whether it’s working for you and how long that experiment is running for… 

…and break down another guideline, a guide post if you will, for break down is when you break things down, yes, of course that can be painful because there are many ways to accomplish that. I’m actually going to link the agile for all workflows for splitting items which I found very useful and all the teams I’ve got to share with found it equally useful. You want to break it down to a level where it is still meaningful and provides some value and is at the same time reasonably small enough that means something for you in your context cannot really be translated from team to team. 

You will find your own way and your own size of items. 

Just bear in mind, Product Backlog Refinement in the beginning, when you get started within your team as you might’ve noticed already is painful, it is getting better, it is so painful because what’s happening is that several minds are aligning themselves around a common shared understanding of the product and the effort and the complexities involved with your given particular context. That calibration and alignment takes time and effort. Once that is happening and once you work with some of the tips and guidelines that I’ve shared here and try them out with your team it will go smoother and smoother time and time again.

With a little bit of fun and facilitation in your Product Backlog Refinement sessions you will actually have an enjoyable event. 

I promise you if you get your Product backlog Refinement into good flow, you will feel the positive benefits and the advantageous impact across your Scrum workflow. So that was everything that I had to share on Product Backlog Refinement.

Please let me know whether you have any queries about anything that I’ve shared in here or any other tips that you might want to suggest in the comments down below. 

And with that, I would like to close this one off and thank you very much for watching. Give us a like, if you find something useful in this video and please consider subscribing so you get updates on future videos.

And with that, I would like to say goodbye. And until the next time on Team Genius Live. See you in a future video all the best for the practice with your team and goodbye.”

== end of transcript ==