​Prioritisation: A Very Difficult Conversation

‘Prioritisation’ is a concept that product owners and business stakeholders often have issues about. I asked myself why and came up with only one answer - “Fear of not getting what they wished for in their product.” 

Afraid to prioritise?

Let me give you an example. In traditional ways of building software, each party in the value chain has a specific role and plays their part only at certain points in the software development lifecycle without much collaboration. The business is usually involved in the beginning as they are the ones with the idea and the money to fund it and at the end to own and sell the product. IT who comes in between, is a black box to the business, as IT and business act as two different entities altogether even if they both work for the same organisation, from my experience. 

History proves that products built this way rarely meet the budget and the timelines and the requirements aren’t even half of what the business wanted. This adds a lot of uncertainty and distrust in a business stakeholder’s mind, hence the thinking “I shall tell you everything I want/need at the beginning itself so that when the product is built, it at least covers half of its features in the budget and the time I asked for”.

Hence ‘prioritisation’ is usually a taboo and not an encouraged conversation.

Why prioritise?

Let’s say you are hosting your daughter’s birthday party and as it’s her first, you want it to be a memorable one. So, you start planning months in advance and have every detail down to its ‘t’. The ‘d day’ arrives and things don’t go as planned. Murphy’s law right?

Your sister who offered to help with decorations and baking the cake, can’t make it in time as she had to cater to some important work. Your parents’ flight is delayed which means they cannot lend a hand in cooking.

What do you do then? You don’t just panic and do nothing but figure out the best way to host this party right? Wouldn’t you start figuring out what is an absolute must for this party to be a success? Let’s list it down, shall we:

• Birthday cake
• Birthday decorations - only in the living room as that’s where the guests will be
• Snacks as children love something to munch on
• Cartoons on cable tv
• Ice cream

And everything else like decorating the whole house, preparing a full blown meal, hosting games etc could probably be done if time permits.

So what did you actually do now? Prioritise right?

Just like in our personal lives we think of what is of utmost importance in crunch situations and do that first; why not apply the same concept or principle in our professional lives?

How to prioritise?

So, I thought I will share my experience on how I have approached this and how it has helped the stakeholders I have worked with. 

One way to start your prioritisation process, is to use the above three-step model approach. 

First, you need to 'Discover' what the problems are, who is facing them and which of these should be solved. This is followed by 'Define' where you figure out how to solve the problems and come up with a plan. Finally, in 'Deliver', you actually solve the problem. 

And you need to prioritise at every point in the lifecycle!

Let's dig a bit deeper in to each of the three steps. 

1. Discover

First understand what the business offers - for example - banking services, retail products etc. Then I, along with my team, seek to understand who their customers are and have an actual conversation with representative of customers to understand their needs and problems. Consolidate these findings and present it back to the stakeholders without adding your own interpretation. This is when the fun begins.

As a product owner, you would want to jump to solve everything now to keep your customers happy. Wouldn't you?

This is what I usually say: “It’s a great thing to solve world hunger but wouldn’t you first start with your community, then your town and so on and so forth? Start somewhere small and then expand the initiative?”

So this is where our first prioritisation begins.

I start with asking who is their most prized customer.  It is often difficult to answer this question so you can ask pointed questions such as: 

Which customers can you not afford to lose?

Which of your customers would you lose sleep over and run helter skelter to get things done?

There lies your answer. 

Now, once you have figured out the prized customers, we need to figure which of their problems need to be solved. I use my simple three bucket rule -

1. Will the customer leave if you don't solve this problem now?
2. Will the customer be fine living with this problem for now but will leave eventually if you haven't solved it?
3. Will the customer be fine living with this problem and not leave if you haven't solved it?

The above should give the business and the team an understanding of what the burning areas are.

One of the clients I tried this with had most of their customers' problems in the first bucket. I honestly felt terrible for their customers and also overwhelmed as to where do we start? So, we tried this next exercise to help prioritise further. We chose three key business parameters that the stakeholders needed to further prioritise. These parameters will be very specific to the business you are working with. In our example we chose the following three:

By solving this problem, will it

1. Generate revenue for you?
2. Save costs?
3. Delight the customer?

We asked the stakeholders to then vote on each of these parameters for each problem. We then had clear winners! We chose the top 5 problems that had the highest votes.

2. Define

‘Define’ is the stage where you start discussing the details of how to solve these problems and plan the way forward. There are various ways to dig into these conversations. Some of the mechanisms I have used include: 

• Business vision
• Business model 
• User journeys and business processes
• Value stream mapping etc

This will help us expose the nature of the problems and then we brainstorm different ways to solve these problems to arrive at a solution.

We then break down this solution into smaller pieces of requirements. Depending on the scope of the project there can be very few to very large number of requirements. The reality is there will be some that are more critical than the others and this is where our next level of prioritisation happens. There are various ways to achieve this. I have usually used the simple 'MoSCoW' method:

1. Must Have
2. Should Have
3. Could have
4. Won't Have or Nice to Have

Photo: Alexey Kljatov - Flickr

It is again very difficult for product owners or business stakeholders to prioritise this as they are afraid that anything marked lower priority will never be done. This is addressed through iterative delivery which I will get to in a bit. Now to help them prioritise, I use real life examples such as these:

"If there was a fire in your apartment, what are the essential things you would grab while getting out? Apart from your family of course"

Then comes the time to estimate the effort of solving these problems and hence arrive at the timeline and costs. This information can be used by the stakeholders to further prioritise the scope as usually timeline and costs are the constraints we all work with.

I always find it useful to use Jim Highsmith's (@jimhighsmith) excellent concept of the "agile triangle”.  And thanks to my colleague Helen Macqueen (@dramacqueen) who introduced me to the concept of using 'Constraints' part of the triangle to prioritise effectively.

If you look at the 'Constraints' triangle of the agile triangle, two of the constraints are similar. Any guesses on which of these and why? 

Often people say, time and money because time is money. Well yes, but I look at time and money as finite resources. One might argue, money isn't an issue but you wouldn't want to spend all your money on one project right? And the same goes with time.

Scope on the other hand is infinite. There is always a list of things the business would like for their customers or themselves, isn't it?

So, I use this information to help the business prioritise further. Usually the stakeholders already have a set budget and timeline. So I ask them to provide us with this information upfront. Then I ask them to choose the scope based on the estimates the team has given, to slot it into the timeline and budget they have provided for. Let's take an example here:

Business has set these constraints:

• Budget: $100,000
• Timeline: 3 months

The team has estimated the scope, has information on the people (not resources!) that can work on it and hence the timeline and cost:

• Scope: 100 story points
• Team: 1 Dev, 1QA
• Cost to finish the defined scope given the number and type of people: $150,000
• Timeline: 6 months

The business can clearly see that, the scope that they prioritised isn't fitting into the constraints they have set. So, it is their responsibility to slot the highest value scope into the budget and timeline they have and the ball is in their court now.

So, this gives an opportunity for the business to work with the team to prioritise the most valuable scope that will solve their customers' problems and also doesn't pressurise the team to bow down to business' whims, as is the case in many organisations!

3. Deliver

As you can see we work in an iterative and collaborative fashion to deliver the scope decided in 'Define'. It is advisable to have a dedicated business representative someone like a product owner in the delivery team, so that any decisions to be made are taken right away without waiting and wasting time. This gives the business an opportunity to have a sense of what's happening on the ground on a day to day basis, which leads to better and timely decision making and a better product delivery.

This also helps the business prioritise regularly. For example, scope for an iteration is usually planned in the previous iteration. If status quo changes in an iteration due to delays like unavailability of people, environments etc, business along with the product owner can quickly look at the product backlog and decide what can be achieved given the constraints. This level of prioritisation in my experience happens everyday!

So, prioritisation happens at every stage of the product lifecycle. There is no start or end to it rather it becomes part and parcel of product delivery. Prioritising frequently helps the business set the direction with the delivery team to cater to the most burning issues or most valuable requirements for the customer. This in turn helps reduce their fear or completely removes their fear of not getting what they wished for in the product because of their immense involvement every step of the way.

In a nutshell prioritisation helps the business in building what’s most valuable to keep the product relevant and keep their customers satisfied and delighted.