Prioritisation Techniques and RICE framework for prioritising product backlogs - Agile-Lean Ireland

The talk is about prioritization techniques and RICE framework for prioritizing product backlogs. This will be a highly interactive session, so come prepared to participate and engage in the conversation.
The RICE framework can be used to prioritize features or ideas based on their importance. The higher the RICE score, the more important the feature or idea is. The RICE framework can help teams make more informed decisions about which features or ideas to work on first. It can also help teams track their progress and make sure they are working on the most important things.
The talk session will cover the following topics:

Various ways to prioritize your product backlog
What is the RICE framework?
How to use the RICE framework to prioritize product backlogs
Examples of how the RICE framework has been used in the real world
Tips for using the RICE framework effectively
The session will be of interest to anyone who is involved in/working with Agile teams and will provide participants with the tools they need to prioritize their work more effectively and make a bigger impact on their customers

Find us here: www.agileleanireland.org

Transcript

And now let me introduce our speaker of of the session today. So Nevels Nivesh is a coach, mentor, trainer, author and enterprise transformation consultant, mentoring organisation in transaction to value Dr. Approaches. Nimesh is certified enterprise coach and has helped many organisations and individuals on their transfer transformational journey. Nimesh is also authorised instructor with international consortium for Agile on 2 tracks, team facilitation and business agility Foundations, and also runs Advanced Crew Masters trainings. Knee mesh is also apologies. I. Have to let somebody in. And I'm not a multitasker. As you can see, Nimesh is has also his own Europe channel called Agile Coaching toolbox. So if you're looking for some tips. Please go there. And he regularly shares and some agile. Knowledge and experience with the community of via that Channel. So it's a huge pleasure to have nimesh sharing his knowledge today with us. So thanks very much and nimesh, feel free to ask something if I if I skip some important information.

That's great. That's great. Thank you for that introduction. Lovely introduction and. I'm I'm excited to be seeing you all here. So today's topic is is. The prioritisation techniques and will do a little bit deeper dive into one of the technique at least. So as as I was saying, you know this would be more interactive session. So as much as you can participate, do it, that would be awesome. I have some activity also lined up. We'll see how it goes but. But we try to make it more interactive rather than just flipping through slides, right? So as you can see, I have mirror board set up for us. So we'll do some collaboration there as well. So let let's let's start with the the basics first, right? If I ask you this simple question, what's the essence of agile? What would be your answer? What would be? What would be your response? In one or two words describe what is the essence of agile and if you want, you can put that in the chat box here. Give you a few seconds to. To give your input simple question, what is the essence of agile? Awesome. We got couple of responses. Great. Yeah. So so when when it comes to agile at the core of it, if you if you look at it at the core of it, it's about. Right. It is about delivering value for our customers. So so you don't have to be doing, you don't have to be using any agile framework for that matter, as long as you are focused on the value focused on the customer. I would say you are agile, you don't need to go with any particular framework. Right now, so. So our focus in agile is more about customers, more about identifying the values, more about how can we create that value and deliver that value, right. So that's that's the focus. So for that to achieve that. We are using again, you know we we are doing several different frameworks. If you want to use like you have scrum you have Kanban. You can use any of the frameworks. There are many more, right? But what is the single most important activity? That we do. To drive this value. If you look at. All the activities that we do, one of the most important activity that is done is prioritising. Right. Why prioritise? Because we want to identify what will bring the most value to the customer. Right. We want to identify what are their pain points and then we want to address those pain points. What will bring the most benefit, what will address their pain points. I didn't find all those and then prioritising accordingly. Right now the goal again is to maximise the value. Right. So we are, we are looking to prioritise, right, right, right. Things at the right time. So that we can create the most value for our customer. Now who does this prioritisation? We all know that is that is our product owner. Right. So the product owner is is doing this prioritisation. And before we go into the prioritisation techniques themselves, I I want to identify I I want to highlight two characteristics of this product owner. When when I work with the product owner I'm looking for. What we call in product owner. So we I'm looking for a teen product owner who has deep product backlog. What do I? Mean by this. So these are again. Fine, so Keane refers to. The product owner being knowledgeable. And I cannot spell while you talk. So if if I make mistake, you know what? What I mean, so firstly is knowledgeable, the product owner has to be knowledgeable about whatever business area she is represent in right about the product, about the market, about the customer. Right, the E prefers to empower. Right. My product owner has to be empowered, right? See, she may have all the knowledge about the market, about the customer, but if she's not empowered, if she's not able to make the decisions quickly, then that's not going to go well. So we want knowledgeable product owner who is empowered and the third piece is even more important. This product owner has to be engaged with the team, right? We all know an absent product owner is there recipe for disaster in agile. Right. So you, you even if you have a knowledgeable and empowered product owner, but you barely see the product owner, that's a disaster for your agile team? Right. So that's the engaged and the last piece is? About the good the product owner being good negotiator. Now we all know again product owner is working with many stakeholders, so oftentimes he might be dealing with conflicting priorities coming from all these different stakeholders that sees representing. And so in that case he should be able to do all the negotiations about the prioritisation. Before coming to the team again, the team doesn't care about how she comes to the prioritisation. Right. The team is look going to look for what's your priority and we will work on. That so so in the background behind the scene, the product owner is doing that negotiation across maybe different stakeholders, right? So that's that's my definition of a good product owner, the product owner. His skin and then she has deep product backlog. So when I say deep, I'm not talking about the the depth of the product backlog. I'm not talking about having hundred 200,000 different items in the product backlog. What we are talking about is, again different characteristics of the product backlog, right? So the first one, first characteristics is. D stands for detailed. Right. And what we mean by that, so detailed appropriately as in you know if you have 100 different items in your product backlog? We know we are not going to have all the details for all the items, right. In fact, in in Agile we don't believe in that big requirements upfront. Right. So we are not interested in that. So what we are interested in is if I have a product backlog. And has hundred different items. I don't care about the details of all the items. What I care about is if the product or says this is my priority item, I need to have the details for that we need to do the refinement on that. We need to be ready to build that. Right. So that is what we are referring to as in detailed appropriately, right, if they are prioritised then we want more details. If they are not prioritised, we don't need to worry about the details. Right. So with that, you know you will see that these. Backlog is constantly evolving, right? So that's the other aspect of it that this product backlog is continuously emerging. More details, new details will come as we do the refinement. OK. But this again, the details are coming in just in time? Just in time, as in the product owner has prioritised that item, now we need to get the details for that feature functionality. Right. So that's what we mean by just in time another term I would like to bring is the LRM as in this, this would be the last responsible moment to get those details. Anything later than this would be detrimental to the team. So again, let's stay on that. So if if the product owner has prioritised this item and we don't have the details around it, maybe we have just a single line statement on that user story, maybe the product owner has put in some acceptance criteria, let's say, is that enough for the team if their product owner is expecting that the team takes that story? Into the next print. Definitely not. That's not enough detail, right? So that is the last responsible moment if you if you want us to work on this story in the next Sprint. We need to get the details now. Right. So again, coming back to the product backlog, that characteristics is emergent product backlog. It is living, breathing document as I like to call it, it's constantly changing, evolving. Right. Along with that. Estimated appropriately is the third characteristics. Again same same concept. You know if it is prioritised, we won't estimate on that. If they are not prioritised, it's sitting at the bottom of the backlog. We don't care. No, we don't want to spend time on estimating that because we don't know whether we will work on. It or not? Right. So so that is what we refer to as the estimated appropriately. The last piece, obviously, as we talked about, is the prioritised. Right. The priority, that's the key. That's how the product owner is identifying that value is and working towards bringing that value to the customer. Right. So. So that's that's what I'm looking for as far as my product owner is concerned. And I'm looking for that keen product owner with the deep product backlog. Now, if again we are looking at the product backlog prioritisation, identifying the the the priorities and then working through those priorities to create that value, right. So it is it is an important activity that is done. By the product owner. Now there are many, many different ways to prioritise your backlog. Right, so I want to hear from you guys as to what are the different prioritises and techniques that that you have used or that you know of or that you have heard of? OK, so I'll give you a few minutes if if you all are at the computer, I would like you to use this menti.com anybody. Has used that. Great. No. OK, so if if you have used it, it's it's great if you haven't used it, it's fairly easy. You don't have to do much. What we are doing is you will go to thismenti.com and then type in this code and then it will. It will allow you to put in your inputs. Into that and this will create a nice word cloud. So I'll actually bring that up. We can see it as it is being created. So this is what we will do. We'll spend few minutes on this. You'll go to menti.com. Type in this code 15921642, right? And what you will see is. Basically something like this. And that will create a nice word cloud that I'll share on the screen as well. So I I have lined up couple of them here and I I we we saw some of these showing up on our word word cloud also. So Moscow is the one of the simplest one that we all of have heard, which is basically must have, should have, could have would have this kind of looking at the feature list and identifying what is the master versus what is something that is. Good to have, but if you don't get it, that's also fine, right? The other one. Is the Kano model again that's looking at the features from the customer's point of view as to what will excite the customer? What features will make them excited about our product, what features will? Make them look to go and buy our future versus features that are OK. I mean, if you get it, that's fine. Customer is not going to make a big deal of it. So this this is often used a lot lot. Of times used. In the marketing to identify what features to market. The other technique is value versus complexity. Right. We want to identify what will bring the value to the customer, but then you don't want to look at just the value. Also, you want to look at the complexity also or the effort involved, right? So you are looking at those two parameters, what will bring the most value and then look at the. Complexity or the effort involved, and then identify what will bring the most value with the least effort, kind of. Right. So that's the third technique. You also want to look at cost of delay. For example can can I? Can I not build this feature right now? If I don't build it, what's the cost that I'll be? I'll end up paying in terms not in terms of money, but in terms of loss, opportunity, for example. Right. So cost of delay is another good way to go about prioritising. The WSJ F is. Weighted shortest job first, so that's that's again looking at several different parameters. Cost of delay is one of those in the WSJ F This is coming from safe. The Scaled Agile framework, but again looking at multiple different parameters to identify those priorities. The bubble sort is essentially you are going through your backlog and looking at 2 items at a time. You're looking at 2 items and comparing them against each other and then kind of going about sorting them based on the value based on the other factor. So. Bubble sort is is another technique you might have heard of 2020 vision. So that's that's one of the game that you can play when it comes to prioritising. That's basically using that bubble sort. Team screening is another one by a feature. Again, another activity that you can do. Anybody else has heard of Eisenhower matrix? Alright, so Eisenhower matrix is essentially looking at. The two aspects. So first aspect is the importance. How important is this feature for the product for the customer, for the market? Right. And then the urgency. So is it urgent that we work on it? And then you can use this to even prioritise your day-to-day activities. Also your To Do List if you want to. Call it right. If I'm looking at my backlog and I'm putting them across these four quadrants right, which is the quadrant that I need to work on 1st. So this is the one that you want to work on, right? This is urgent as well as important. So we better get working on it now. So this would be again if I was the product owner. Everything in that quadrant is my highest priority. Right. So that's that's the again, you know you can use this Eisenhower matrix. To identify those priorities accordingly. Now the last one and that's what we want to dive a little bit deeper into is for the rice model. Right. So Rice again, it's not talking about the basmati rice that we all are so fond of, but it's again it's it's an acronym. Right. So rice refers to four different aspects of that prioritisation. So first one is talking about the reach. Reach as in. If you build this feature. If you build this functionality, what would be the reach of our product? Would we be able to get to bigger audience? Right. Ohh so so again you know it's in essence you're looking at the market segment or the size? Of the market. Right. If I build this feature and deliver this feature, Oh my God, we will be reaching 80% of our customers versus hey they we build this feature, it's probably going to be of interest to maybe 10% of our customer. Right. So that's what this REACH refers to. Now I is the impact. Impact as in what's the impact on our customer, what is the impact on our customers experience with the product, what's the impact on our bottom line, right? So you can look at different aspects of that impact, but in a sense, you're looking at the impact that is created by. This feature functionality. OK. So that's the second aspect we want to be looking at when it comes to to using this rice. C refers to the confidence. As to what is, what is our confidence level on building this functionality, what's the confidence level of our as our numbers that we are using here for the REACH and impact and all that, right? So it's looking at basically the level of. Confidence that we as a team we as an organisation have in these numbers in building and delivering this product for the future. The last piece. Refers to effort. And as to what's the effort involved? And if it is easy, obviously we can get that out the door quickly if it is harder, then it's going to take more time, more effort. So we definitely want to look at effort as one of the aspect when it comes to prioritisation. And so these are the four elements, these are the four components of rice and then you are using the formula. So we are looking at the reach. OK, you're still seeing the screen, right? Just want to confirm. Yeah. OK, great. Yeah.

Yes, yes we do.

Reach impact, then confidence. You are bringing all that. You're going to multiply those and then divide it by the effort. Right. This gives you some number that's referred. To as rise. Simple formula. Looking at all these four different aspects. Obviously effort is the denominator denominator here, right? So what? Does that mean? If the effort is low, then my rise score is going to go high. Right. If the effort is more. Then my rice core is going to go low in a sense that will force the item to bubble up to the. The list of our backlog items, right? So the low effort items and if it is creating bigger impact, we definitely want to tackle that first, right? So it will automatically bubble up those items to the top of our backlog. So let's let's look at one example. And if you want to follow through, I'm going to put the link in the chat so you can definitely open that up on your side. This is a Google worksheet. And I have shared it with everybody. This is what we are going to do here. So let's bring that up. So let's assume that we we are a financial services company and we are looking to build. Some new functionality for our customer. Right. Let's let's say let's say we are, we are looking to build a credit card functionality so that the users can pay using credit card. Alright, so the story or the product backlog item says the retail customer wants to pay for their purchases using Visa or MasterCard.

Right.

So that they can get the product in their hands quickly and start using it. Right. If we go through the rice we are we are looking at it as you know, what's the rate first of all? In this case, we are saying that if we deliver the. This looking at the data that we have about our transactions from the past looks like it's probably going to allow us to reach 80% of our customers. So 80% of the transactions are handled using MasterCard or Visa. So that's the reach. OK, so you can you can I, I so there are there are multiple different ways to look at this you can look at the reach as in you know low, medium, high and you can score it that way. So for example if it is low you can put a score of 1, I maybe 5. You can come up with your score to keep things simple, I like to use the scale of 0 like 1 to 100 or zero to 100. Let's say right? That makes things easier. So in this case we are saying that 80% of our transactions will be impacted by this. Sorry, the will be our reach will be 80% of transactions. Right. Obviously that has a bigger impact on our bottom line. So that's why we have a score of 90 here. OK. Again, zero to 100 or if that is the scale 100 mean big, big impact? Versus 0 being no impact at all, right? So in this case, we are saying that. If we build. And deliver this functionality. The impact would be huge. So that's why we have a we we have a score of 90 here. What about the confidence? Can we build this? What about the confidence that we have all the information that we need? Right here. Let's assume that the team has done some work in the past with these networks. The MasterCard and Visa and all that, right? So the team is pretty confident about building and delivering this functionality. So in that case, our confidence level is pretty high on this. Right. So that's why we have a score of 90. You may say I have a score of 10, let's say. If this is something new. The team says, hey, we have not done this in the past. We don't know how Visa and MasterCard works. We will have to identify how we connect from our network to their network and exchange data, exchange the transaction status and things like that. In that case, my confidence is pretty low. Right. Massive effort because we have to talk to these two networks and get the API's and things like that. The security and all the different aspects, so the effort level is huge here and that is why I have a score of 90. Right. So then if we apply that formula again, remember reach. Into impact into confidence, divided by the effort. That's the that's the formula. That's that gives you the score of 800. I'm just showing you this one particular feature functionality. Just to walk you through as to how you use it. Now, if you have more like if this was my product backlog and we have all these different stories, we will do the same thing for all those items. Right. And then basically you are going to look at this rise score? To identify what is the item that will create the most impact. What would be the highest priority right? Higher the rice score, the higher the priority. I'll pause here. Any questions, concerns, thoughts from any of you? Alright, related to the.

Sorry, related to the effort, is this. Also this is an absolute well in the meaning of mandates that needs to be taken into account for the development or should it be also a relative amount from zero to 100 for example in which all the PBIS are compared to.

Yeah. So you are not looking at the? And our words again, you know, we don't want to go into all those details as to how much of an effort exactly right. This is kind of a ballpark, so we are we, we can say the the scale of you know low. 3rd to like Low, Medium, High, Extra high effort. Right. So in this case, basically in 90s, somewhere in that extra high effort I'm saying. Right. So you can define your own scale that way, but the only thing I would say is be consistent with that. Once you decide the scale, use the same scale for every item that you have on your product backlog.

Sure. Alright. Thanks.

Any other question? Alright, if no question, I'm looking at the time also. So I I wanted to do this exercise, but we'll probably skip that or let's say if we have time, we'll come back to this. But this is essentially how you are going to use rice. To help you identify the right priorities.

We we actually understand the concept. So thanks so much because of.

Yeah, from your explanation is.

A very good, logical and very interesting. I love it.

Great. So let's, let's talk about why we want to use this. Method if to prioritise, So what are the benefits and what are the shortcomings? Any any any thoughts on that? What are the benefits here of using rice?

Trying to objectivist it.

What is that? Yep. Great. Thank you. Yeah. So definitely this will help you in in kind of neutralise the biases. Right. If I'm biassed toward a particular feature functionality, you know tendencies, the priority will be impacted. My buyers on that as a product owner, right? Because I love working in that particular business area, so I'm going to prioritise that higher. So with this rice model, you are actually. Eliminating those biases impacting your priority. So that's the first benefit. Right. You are also to some extent you are also using. Data-driven decision. Right, you are using different data points to come to this rise score. So this is more more quantitative decision making. If you want to call it right. And and we we know nowadays. Every decision is kind of data-driven because we have so much of data information available very easily. So definitely use that data-driven approach to even identify your priorities. Right. So so data-driven decisions, that's another benefit of it, I would say. Now with that. I also want to highlight the OR or caution that since this is data-driven decision, obviously your decision will be only as good as your data. Right, so the data is in, you know the the scores that you're putting for reach impact, confidence level, all that will impact obviously the rise score. So if your data is bad as we know, garbage in, garbage out. Right. So if your data is bad, your this is on your priority will be wrong as well. So that's the other piece. To some extent. The other piece is the dependency. So if you if you notice the rice. Formula doesn't talk about dependencies. Right. So you may you may be wondering, hey, we are not even considering dependencies. And that is bad because we know everything that we do in today's world has dependencies, has many different tentacles across different stories, different products, different teams, right. So we definitely cannot ignore that. But in a in another way, if you look at it, it is considered and. When I asked the effort. Right. What are you going to do? You are obviously going to look at those dependencies right? At least think about it as to. Am I going to be interacting with one system multiple systems? Am I going to be dependent on multiple teams and all that will kind of get reflected in the effort? If you have to interact with multiple teams and multiple products and multiple systems, obviously you'll say hey, this is a very high effort. So in a way, rice takes into consideration the dependencies aspect also. It's not direct, it's kind of indirectly baked into our decision making. Makes sense, sorry. Sorry guys, my son is calling.

So yeah, these these are.

These are the benefits, you know, it's obviously Objectivist in our decision making. It's based on the data. So put in some effort into data. So that's other piece. This formula does it in fact forces the product management. To do some exploration. That's another piece that I like about this. It's not that we are pulling some numbers out of thin air. I when I when I asked them, hey, what's the reach? You know they will have to do some exploration, right. They'll have to do some background research if you want. To call it. And then come to a conclusion as to what is the reach. So in other words, these forces us to do some exploration, which is good and the exploration is good here. So these are, I would say these are some of the again I'm looking at the time. So with the limited time we have. These these are the these are the benefits I would say of using rice. OK. Objective objective wises the decision are based on the data. It also considers the dependencies, it forces the product management to do some exploration before we get to that score.

Right.

So that's that's what I wanted to share with you today. We have about 10 minutes left. I wanted to leave some time. For any questions that you may have. I'll definitely answer those and then.

Would anybody have any questions? No, hang on.

Sorry, I think I at least I have one.

Yeah, companies still be rice. If you've got large.

I didn't get the question.

Each height, if you have a large product backlog, would you start doing it for each item on that backlog?

If you if you have, if you have a large backlog, would you do that exercise for every item in the backlog?

So initially like you know, when we talk about the the prioritisation it it it happens in multiple levels. Also if you notice. Now when we are using this rice, we are not at the story level. This is more like epics and features that that's a different topic altogether. But these are. Like big chunks of work that the product owner has identified and then you are doing this. So I would say yes, you would want to do this, right? Score for all the items those big chunks on your backlog. And as to what what epics should we should work on, what features we should work on at a high level, you definitely want to do this rise score for every item on there. You won't be doing that for every story on your backlog. That would be too much detail. So long story I gave you a long answer, but the the quick answer is yes, you would want to go through all the product backlog items at the epic and feature level.

OK. Thank you.

So we have we have another question on the chart, how do you use rice across multiple product teams to ensure consistency to the rise score by different peers?

OK, great question. Great question. Yeah, so. So here like there are two variations of this, right, so we have multiple teams working on one product. So that's one scenario right here. The product is like 1 product but then we have multiple teams involved so we may have multiple product owners involved. In this case, right? So how do we make sure that there is a consistency? The other scenario that you are talking about in this is you have multiple products. And across those multiple products, multiple teams involve even bigger number of teams, right? Both both, both scenarios can be tackled by kind of quote UN quote. Standardising these these scores as to hey. When we talk about reach, you are going to use this scale of zero to 100. As in, if it is a low reach. Then you're going to say anywhere from 1 to 20. Let's say if it is very high reach, then it will be a four of 8200. So you're giving them some guidelines, some standard laid out as to how to use those those scale. So that will have to be done by your if you have a centre of excellence, for example, agile centre centre of excellence, who creates all the templates and worksheets and all that, they would come out with these quote UN quote standard and that will be conveyed to every. Product owner in the organisation. So that's one way you can make sure that the score that we come up with is is using the same scale. OK, hope that answers your question. Alright. Any any other question?

Yeah, you good. Thank you. So I guess, yes. Any any more questions, you can either speak up, unmute yourself and speak up or you know, type it into the chart. And I will read it. Are you going once going twice? OK, so I think we can wrap up. So thanks very much everybody for joining today. This is the reminder and last session before the summer, we'll kick off again in September, but we are taking a break for to enjoy the. And thanks very much nimesh for joining us today and sharing the topic. Great questions everybody who asked them and thanks very much for clarifying things for us. And we have another tool in our toolbox, Azure toolbox. So that's all what we want and.

Mark versus Mark present.

If you have any more questions, please feel free to UM linked with image on LinkedIn or follow his YouTube channel. Nimesh again, thanks very much for the time it's you know we we appreciate you took time to off your out of your calendar to to be here with us.

No problem, no play. It's it's pleasure. So let me know if I can be of any help on this as well as in the future. As I said earlier.

Lovely. Lovely. OK. So we'll be in touch. Bye bye.