Priority Inflation
Stakeholders believe their requests are the most important. That's just a quirk of human nature.
"I just got off the phone with an angry client, and we need to focus on reworking the dashboard!"
"We had a sales call with a big potential customer. We need to add Sharepoint support ASAP."
Teams have ways of channeling their priorities. There's a roadmap and a backlog. There are planning sessions to decide what to build next.
But often, in "fast-paced environments," we notice this rhythm is not enough. We'll plan an iteration on Monday, only to get hit with an urgent customer support ticket on Wednesday.
The default priority levels in most project management tools are Low, Medium, and High. That's a terrible system relying on gut feeling. It asks the reporter to weigh their request in the larger scheme of things and come up with an objectively reasonable level. That's not how human minds work. People suffer from recency bias. What we've encountered today seems more important than what we already had on the plan. Of course, they are going to bump the level.
Priority inflation happens when there is no price to pay for Urgent. When stakeholders are outsiders who can ask for stuff without being impacted themselves.
When it comes to priority, there are indeed three levels:
Chaotic urgent: Something happened. The server has crashed, and thousands of users are impacted. Drop everything and fix this now. Plans be damned!
Controlled urgent: Something came up that can't wait for our regular planning cycle. Finish what you are doing now and start working on the issue. The plan will be impacted in the next planning session.
Planned: There's an idea that we might want to build. Let's review it during our regular planning cycle and see if it makes the list.
In a perfect world, everything is Planned. We don't live in a perfect world. Urgent happens.
When Toyota revolutionized the manufacturing world, it developed the concept of an Andon cord. There was a cable above each workstation, and the entire factory floor stopped if a worker pulled that cord. The idea is that when one workstation encounters quality issues, the root cause is always upstream. It doesn't make sense to keep producing faulty parts until we've figured out what's happening. This puts a lot of power in a worker's hands, but it's a system that's hardly abused. You don't want to be the one to stop the factory floor for no good reason.
Urgent issues in a software development environment require a similar Andon cord: an all-hands meeting with the stakeholders and team. The one who sets the priority as Urgent pulls the cord and calls the meeting.
For chaotic urgent, that's always the right thing to do. Drop everything and get together now. Nobody in their right mind would keep building features over getting the crashed system back online.
But for controlled urgent, you would be surprised how often these things can just be planned.