I come up with these all day long. They come along with a bunch of whenever tweaks. The trick is identifying which is which and making a strong case so that other people buy into the same prioritization. And then being right...
This is good, but unless you're a minimal team of one or two (or even if you are), sometimes the best thing is to get a bunch of tweaks (say 5-10) done in a week or two, because it makes users feel like you care, and they might add up to a considerable improvement in satisfaction/delight although individually each is insignificant. In other words: polish can't wait forever.
if you deliver a couple of quick tweaks that the users want in the next week, that can buy you some time to do more behind the scenes refactoring/tech debt cleanup.
I think that the boxes on the "importance" scale are not very well named. I would personally use something like Critical, Important and Nice-to-have; or maybe a variation of the good old MoSCoW (Must, Should, Could; the "Won'ts" can be omitted for obvious reasons.
That being said, I can imagine each team having their own definition and levels of importance, with the names that are meaningful within their particular context.
It seems like this is a lot of the strategy behind pitching things as epics. If tweaks interact to produce considerable satisfaction / delight, then bundling them together keeps focus on what big thing happens when they're all completed..!
As someone pointed out, this is a variation of the Urgent/Important matrix.
I've found that there is a next step / additional dimension that can be very useful as well:
Once you have what's in the important row, ask people what they would want to work on.
Assuming everyone is qualified for the tasks, I've found that giving something urgent/important to someone who wants to work on it vs someone who doesn't DRAMATICALLY improves the odds of it getting done quickly.
This being HN, someone will say: "But what about things nobody wants to work on". Great question!
The answer is to either:
- Have everyone take turns e.g. doing support for the team on a rotation
- Make trades vs the future e.g. "I know you don't want to do this now. If you do it though, I guarantee you get first choice on what you want to work on next."
I find it difficult to understand the opposition between Urgent and important, I could understand for example an opposition between difficult and beneficial.
But urgent and important sound somewhat like synonyms. Something urgent must be the most important.
You are right that urgency is related to value (same as important), but also to time.
One way to look at it is that urgent things are those whose value is soon going to be accelerating quite a lot (even infinitely), either up or down. Important things are things whose value is high, irrespective of rate of change.
Example: Fix the hole now or the boat sinks: urgent (currently you have a boat that is completely functional: that's going to change). Arrive to the intended port and not a wrong one: important (if you make a mistake, you may need to spend several days travelling back. Sure, the longer you keep navigating in a wrong direction the more fuel and time you lose, but it is not super-urgent).
ok this seems the most sensible - from a project management / IT viewpoint - expression of the issue.
I was going to say I still don't think I would find a x,y graph with x being urgency and y being importance useful for determining what I would work on but now I can theoreticaly see it, urgent issues that are more important get worked on sooner than urgent issues that are less important.
I do think however if someone told me that, as others having suggested here, winning a contest was urgent but 0 on importance than I would say it was also 0 on urgency.
All that said I think the graph would be not especially useful in practice, because in working on things we know the kind of urgency that determines what gets worked on and it almost forces us to prioritize issues higher.
Logins not working, people can't complete purchase, GDPR fines coming next week unless we fix.
Stuff that is urgent in almost every meaningful IT scenario is also, at the time, the most important.
To me, urgency means the time to do it is now/soon. And importance means we should do it.
Urgency and importance both affect prioritization. Something that is urgent and important should usually be done first. Something urgent and not important needs to be done soon or not at all --- and both are valid choices. Something important and not urgent is likely to be delayed, at least until it is urgent. Something neither important nor urgent may be delayed or dropped --- again, both are valid choices.
I guess I understand it in theory but I guess I am also just a different person - if something is urgent but not at all important it will always be dropped. To me that would be the only valid choice.
I can't help but think that anything that is urgent but only a little important is in fact really important, because things that are a little important need to be done, and the urgent thing must be done now.
Urgent and a little important must be done now.
Urgent and unimportant must be dropped and it is a waste of time in endless meetings to even discuss it.
Not necessarily. Imagine a scenario where the team would like to submit their project to some kind of a competition, and the submission deadline is nearing. If they submit, they could win an award that could increase the project's visibility and potentially sales; but it's not guaranteed, and the project is already doing well enough on its own.
So, that task of submitting to the competition is definitely urgent, but at best nice-to-have.
A couple more examples of urgent but not important:
- Buying a pumpkin for Halloween: the stores are going to sell out of pumpkins and Halloween is going to pass, so it is urgent to buy a pumpkin while there are still pumpkins.
- Commenting on a controversy on social media: very quickly, the attention will move on to the next thing and you will lose the opportunity to comment on this thing.
>* Assuming you're not a 911 dispatcher or other on-duty call-center type of employee.
Or a programmer, or working on technical projects with some sort of scrum-like workflow in, in which case I believe an urgent issue is an issue that is important.
I believe a lot of people on HN fall into one of those two groups.
Sure theoretically you can still come up with issues that are urgent but not as important as less urgent issues but not in a way that really fits how the terms are used in a lot of our works.
It's important that we transition off the platform in a year or we will pay 50 thousand dollars a month in fines, but it's urgent we solve the login issue.
Yeah sure but we're going to work on the urgent issue because right now, in this moment in time, the urgent issue is more important than the issue that has a year to be fixed.
Everyone's given you examples of urgent/unimportant. Here's an example of Important/not-urgent:
You are successfully selling a product at a profit. You have identified an inefficiency in how the product is made; if you fix it, you increase your net margins by 50%.
That's super important, as you're leaving a lot of money on the table! However, whether that inefficiency is fixed immediately or somewhere down the road makes little difference in terms of the payout once it is fixed.
It means you make a lot less money. Urgent usually implies a nonlinearity in the cost of not doing it. Important means a large absolute cost of not doing it.
Something can be urgent, but it doesn't matter if you don't do it.
Something can be important but not urgent - it doesn't matter if you do it later, but it's important that you do it at some point (but you maybe don't need to do it right away).
Something can be urgent and important - if you don't do it now, bad stuff will happen.
"Important (but not Urgent)" is most people's weak quadrant.
All those biggish things that you want to do some day, that you need to do some day, that might change your life... BUT right now (for looong values of "right now") there's something else to do.
This is where you want to break down hazy targets into multiple more-concrete steps, so that you can opportunistically make piecewise progress.
Exercising today is important, because it contributes to my long-term goals, but it isn’t urgent – I can do it this morning, tonight, or even delay it a few days if need be.
Buying food for dinner tonight is urgent, because without it I can’t eat tonight. It’s not important, however, in that even in the worst-case scenario where I miss a meal, nothing bad happens.
Paying my rent is both important and urgent, in that it’s time-sensitive and has substantial consequences if I fail to do so.
I struggled with this for years (decades, actually) and used similar reasoning as the sibling comments. And it doesn’t work.
Funnily enough the solution is very simple, but you need to have a list of goals you want to reach. Everything that helps you get closer to fulfilling your goals is important, everything else is unimportant.
There should be a special place in hell for people who come up with 2-axis, 4 quadrant categorization of things and a VIP entrance for those making trivial modifications on them and branding it the Magic Way (TM).
Most of these processes are garbage-in-garbage out.
Since these are designed to help a team deliver the best bang-for-the-buck at a given point in time, I've found proper assessment of actual urgency and importance are the biggest success factors.
Can't express the number of times that an urgent or important need that was identified was addressed by my team, with nary any impact.
This system makes sense on a fundamentals level, but something to also consider is the synergy principle (1+1=3) where some tasks, when coupled together, could potentially be bumped from optimizer to game changer (or bumped from tweak).
Great visuals though, made the system super easy to comprehend.
I think some of the comments that are writing this off as not very useful are missing a point. Almost all businesses prioritising finite resource should be using some form of CD3/WSJF; but it's very hard to communicate why to stakeholders without diving into some math and graphs that some people have a hard time understanding.
This looks like a really good way of getting people to practice cost-of-delay based prioritisation in a structured, reproducible way that doesn't involve formulas or maths.
The magic trick is to have a singular queue, and/or a singular stakeholder representative.
When you have disparate independent stakeholders who each have their own value/urgency models, these things start to fall apart.
I've frequently worked in large orgs with far more internal stakeholders than devs, which meant that at any given time, only 50% of stakeholders were having any of their tasks actively worked on. You can play games to try and mask that, but end of the day it is reality.
So then the game they all play is making sure they are one of the stakeholders with active tasks at all times. Which then turns into competitive escalatory MAD. Which mostly turns into management by squeakiest wheel, because if you don't take care of badguyX, he is going to tell his bosses boss you are an idiot, so it's easier just to keep the queue of badguyX active then piss them off and then still have to do their work after all the fight. No manager wants to admit falling into this game, but they very very often do.
I'd also point out in these situations, the tie breaker / decision maker is far more senior of a person than someone who is going to go through some sort of quantitative process vs "using their judgement" (aka gut).
Not saying I have an answer, but am saying the post is solving a simpler version of the actual problem.
the solution is obviously to always work on multiple tasks simultaneously. how often you need to switch depends on the granularity of the report. if your report is daily you touch each task once a day. if it is hourly, you switch through all tasks every hour. the pomodoro method has you taking a break every 30 minutes, so two tasks each hour are possible without cutting time on each task to short.
i am not entirely serious. but as an independent contractor with multiple customers, working on tasks for different clients every day or every week is not unrealistic.
very true. but when you are in the situation with more projects than developers, each project will have to wait either way. can't get around that. it either takes 2 weeks because the developer works on multiple projects at the same time, or it takes 2 weeks because the project spends most of the time waiting in the queue.
the end result is the same. so it really doesn't matter.
the benefit if the queue system is that you get to focus on one project at a time. the benefit of the paralell system is that you don't waste waiting times that may occur when during the development you need something from someone else and have to wait for their response.
which is better depends on the specific project and how the stakeholders communicate.
I'm so glad that I just stumbled across this comment. I'm a career military officer who has served on big, upper-echelon staffs that were stunningly disorganized and dysfunctional. You nailed it with this description of how things really work.
I always said that people were busy - there was a frenzy activity - but nothing ever got done until someone very senior (i.e the commanding general or one of his deputy commanders) stepped in, like you said, and made a decision from his gut that a particular thing needed to get done, and then everybody would actively work on that one thing and nobody's work would be blocked. Eventually I realized that the game for stakeholders was all about getting their things into a decision briefing for the commander to make that happen.
46 comments
[ 1.4 ms ] story [ 112 ms ] threadThe interesting part is that it's allegedly a trick to get people to stop conflating the two, or cheating.
I also split the task into two sections, i think we traditionally use impact and cost/difficulty.
Then we stack ranked ideas using a horizontal wall. Once for impact. Once for difficulty. Then after the fact I correlated the outcome into a matrix.
It’s like the difference between having humans estimate volume (hard and error prone) versus estimating length (much more likely to be accurate).
The exercise was less painful to implement and the results seemed more accurate.
Another way to look at it:
if you deliver a couple of quick tweaks that the users want in the next week, that can buy you some time to do more behind the scenes refactoring/tech debt cleanup.
That being said, I can imagine each team having their own definition and levels of importance, with the names that are meaningful within their particular context.
I've found that there is a next step / additional dimension that can be very useful as well:
Once you have what's in the important row, ask people what they would want to work on.
Assuming everyone is qualified for the tasks, I've found that giving something urgent/important to someone who wants to work on it vs someone who doesn't DRAMATICALLY improves the odds of it getting done quickly.
This being HN, someone will say: "But what about things nobody wants to work on". Great question!
The answer is to either:
- Have everyone take turns e.g. doing support for the team on a rotation
- Make trades vs the future e.g. "I know you don't want to do this now. If you do it though, I guarantee you get first choice on what you want to work on next."
But urgent and important sound somewhat like synonyms. Something urgent must be the most important.
One way to look at it is that urgent things are those whose value is soon going to be accelerating quite a lot (even infinitely), either up or down. Important things are things whose value is high, irrespective of rate of change.
Example: Fix the hole now or the boat sinks: urgent (currently you have a boat that is completely functional: that's going to change). Arrive to the intended port and not a wrong one: important (if you make a mistake, you may need to spend several days travelling back. Sure, the longer you keep navigating in a wrong direction the more fuel and time you lose, but it is not super-urgent).
I was going to say I still don't think I would find a x,y graph with x being urgency and y being importance useful for determining what I would work on but now I can theoreticaly see it, urgent issues that are more important get worked on sooner than urgent issues that are less important.
I do think however if someone told me that, as others having suggested here, winning a contest was urgent but 0 on importance than I would say it was also 0 on urgency.
All that said I think the graph would be not especially useful in practice, because in working on things we know the kind of urgency that determines what gets worked on and it almost forces us to prioritize issues higher.
Logins not working, people can't complete purchase, GDPR fines coming next week unless we fix.
Stuff that is urgent in almost every meaningful IT scenario is also, at the time, the most important.
Urgency and importance both affect prioritization. Something that is urgent and important should usually be done first. Something urgent and not important needs to be done soon or not at all --- and both are valid choices. Something important and not urgent is likely to be delayed, at least until it is urgent. Something neither important nor urgent may be delayed or dropped --- again, both are valid choices.
Urgent and a little important must be done now.
Urgent and unimportant must be dropped and it is a waste of time in endless meetings to even discuss it.
Not necessarily. Imagine a scenario where the team would like to submit their project to some kind of a competition, and the submission deadline is nearing. If they submit, they could win an award that could increase the project's visibility and potentially sales; but it's not guaranteed, and the project is already doing well enough on its own.
So, that task of submitting to the competition is definitely urgent, but at best nice-to-have.
- Buying a pumpkin for Halloween: the stores are going to sell out of pumpkins and Halloween is going to pass, so it is urgent to buy a pumpkin while there are still pumpkins.
- Commenting on a controversy on social media: very quickly, the attention will move on to the next thing and you will lose the opportunity to comment on this thing.
No. Answering a ringing phone is urgent. Answering a ringing phone is not important (usually*).
Opening a certified letter from the IRS is important. Opening a certified letter from the IRS is not urgent.
Urgency communicates the time-sensitivity of a task. Importance communicates the value of a task.
* Assuming you're not a 911 dispatcher or other on-duty call-center type of employee.
Or a programmer, or working on technical projects with some sort of scrum-like workflow in, in which case I believe an urgent issue is an issue that is important.
I believe a lot of people on HN fall into one of those two groups.
Sure theoretically you can still come up with issues that are urgent but not as important as less urgent issues but not in a way that really fits how the terms are used in a lot of our works.
It's important that we transition off the platform in a year or we will pay 50 thousand dollars a month in fines, but it's urgent we solve the login issue.
Yeah sure but we're going to work on the urgent issue because right now, in this moment in time, the urgent issue is more important than the issue that has a year to be fixed.
You are successfully selling a product at a profit. You have identified an inefficiency in how the product is made; if you fix it, you increase your net margins by 50%.
That's super important, as you're leaving a lot of money on the table! However, whether that inefficiency is fixed immediately or somewhere down the road makes little difference in terms of the payout once it is fixed.
Something can be important but not urgent - it doesn't matter if you do it later, but it's important that you do it at some point (but you maybe don't need to do it right away).
Something can be urgent and important - if you don't do it now, bad stuff will happen.
All those biggish things that you want to do some day, that you need to do some day, that might change your life... BUT right now (for looong values of "right now") there's something else to do.
This is where you want to break down hazy targets into multiple more-concrete steps, so that you can opportunistically make piecewise progress.
Buying food for dinner tonight is urgent, because without it I can’t eat tonight. It’s not important, however, in that even in the worst-case scenario where I miss a meal, nothing bad happens.
Paying my rent is both important and urgent, in that it’s time-sensitive and has substantial consequences if I fail to do so.
Funnily enough the solution is very simple, but you need to have a list of goals you want to reach. Everything that helps you get closer to fulfilling your goals is important, everything else is unimportant.
Just have ChatGPT figure this out for you, given a nicely engineered prompt :)
Since these are designed to help a team deliver the best bang-for-the-buck at a given point in time, I've found proper assessment of actual urgency and importance are the biggest success factors.
Can't express the number of times that an urgent or important need that was identified was addressed by my team, with nary any impact.
Great visuals though, made the system super easy to comprehend.
This looks like a really good way of getting people to practice cost-of-delay based prioritisation in a structured, reproducible way that doesn't involve formulas or maths.
When you have disparate independent stakeholders who each have their own value/urgency models, these things start to fall apart.
I've frequently worked in large orgs with far more internal stakeholders than devs, which meant that at any given time, only 50% of stakeholders were having any of their tasks actively worked on. You can play games to try and mask that, but end of the day it is reality.
So then the game they all play is making sure they are one of the stakeholders with active tasks at all times. Which then turns into competitive escalatory MAD. Which mostly turns into management by squeakiest wheel, because if you don't take care of badguyX, he is going to tell his bosses boss you are an idiot, so it's easier just to keep the queue of badguyX active then piss them off and then still have to do their work after all the fight. No manager wants to admit falling into this game, but they very very often do.
I'd also point out in these situations, the tie breaker / decision maker is far more senior of a person than someone who is going to go through some sort of quantitative process vs "using their judgement" (aka gut).
Not saying I have an answer, but am saying the post is solving a simpler version of the actual problem.
i am not entirely serious. but as an independent contractor with multiple customers, working on tasks for different clients every day or every week is not unrealistic.
so every task now takes 2 weeks duration because it will get approx 2 days of effort in that window.
then the next side effect is any remotely challenging task gets avoided because the duration of a 1 week task becomes 5 weeks and.... forget it.
the end result is the same. so it really doesn't matter.
the benefit if the queue system is that you get to focus on one project at a time. the benefit of the paralell system is that you don't waste waiting times that may occur when during the development you need something from someone else and have to wait for their response.
which is better depends on the specific project and how the stakeholders communicate.
I always said that people were busy - there was a frenzy activity - but nothing ever got done until someone very senior (i.e the commanding general or one of his deputy commanders) stepped in, like you said, and made a decision from his gut that a particular thing needed to get done, and then everybody would actively work on that one thing and nobody's work would be blocked. Eventually I realized that the game for stakeholders was all about getting their things into a decision briefing for the commander to make that happen.