Prioritizing is more than answering ‘What needs to be done first’

Determining the priorities is one of the most difficult things in Agile. When you start, it may sound really simple. You find out what needs to be finished first or what the company asks for the most and give those the highest priority. And that is how you should not prioritize.

When you determine the priority, a lot of things are important. In general, I would divide the most important ones into two groups: time and impact.

Time

When you look at the time, you should not only look at the time it needs to be finished. But also the time it will take. If the company wants a job that takes 1 week in 2 months, that’s important to pick up. I don’t disagree. A job that is needed in 6 months seems not worth looking at. Until you realize that that job will take 5 months to finish.

And then we have the circumstances that can delay something. Imagine a job takes 40 hours, but you need 5 teams to do it. Those teams need to do their work after each other, not one can work at the same time as another team. If you follow the right procedures, this means 1 sprint per team. If a sprint is two weeks, this means the job will take around ten weeks. Even if it is just 40 hours.

Another problem is external factors. If you need approval from management, work from another department, all of this might take more time. How much time does it cost in general when management needs to give approval. How much time does the other department need? And realize that very often this needs to be done before you can start working in a sprint.

When you prioritize it doesn’t only come down to the deadline. You should know how long it will really take before the job is done. And determine the margin you have between the deadline and needed time. That margin should determine the priority, not the deadline.

Impact

People reading this far might think ‘You shouldn’t have deadlines’ or ‘We don’t have deadlines’. The first one: you might be right, but it happens very often. And I’m not the person to deny what is really happening, even if it shouldn’t. About the second one: you probably mostly prioritize on ‘What the company wants the most’. Something that is also important to consider when you do have a deadline.

But what the company wants the most, is not always what they need the most. That is because they are very often focussed on ‘Which problems do we have right now’. Problems that are not happening right now, do not seem important.

OK, you have a risk that some functionality will bring the whole database down if a customer starts using it. But no customer is using it. Nice. Then comes a new customer, a very important one. And that one does want to use it. All of a sudden everything has to go away to solve this problem. It becomes a rush job. And everyone knows what the risks are when teams start rushing.

When you take the impact into consideration, you shouldn’t only look at ‘How important is it now’. Also, take into consideration ‘How big is the impact, if it happens or is needed’ and ‘How big is the chance this is going to happen or we are going to need this’ Those three combined should determine the total score of the impact.

Combining the two

When you determine the priority you should have a good overview of the mentioned time and impact for everything you want. If something takes a lot of time and has a high impact, you should give it a high priority, even if no one in the company is asking for it. If the impact is not that high, but it does have a very small time margin, it needs priority too. And of course, the most important ones are the ones that are needed very quickly and have a high impact. But always consider everything surrounding time and impact, not just the first arguments that come up.

Leave a Comment