How can I give a good prioritisation to get everything done?
I wish, the day would have more than 24 hours.
This is my third all-nighter this week.
I have too many ideas for too less time per day.
Most of us probably have heard one or more of the quotes above. We usually feel we do not have enough or need to work overtime to accomplish everything we planned. But of course those ideas and quotes above are wishful thinking. Then a day will never have more than 24 hours. Therefore prioritisation is the key.
The myth of doing everything
Human beings are generally very bad in planning – the longer we plan, the harder it gets for us. When we plan, we usually assume the most perfect situation and having the answers to everything. Software teams give us a good indication on our ability to plan. Most of us complained at least once about their “bad estimations“.
We look at a day of 8 hours and we squeeze in, what we want to achieve. In the end we wonder, why most of the time we did not achieve this. One of the problems is our inability to plan for slack and thus not able to navigate our planning in accordance with urgent activities coming in. In the end we just do overtime in order to accomplish our plans.
The concept of flexible scope
As mentioned, the overwhelming majority of us will not be able to stretch the day to more than 24 hours. It is important, not to do everything, but the most important of what we planned. Scrum introduced the concept of flexible scope, in which we value the timebox and cost (stable team) over our plan. We rather inspect and adapt on our working software. We also discussed this in our blog article about the 10th principle of the Agile Manifesto of Software Development.
Foundations of prioritisation: Important vs. Urgent
The higher in the hierarchy you are, the more stakeholders are around you and will push for their activities. But it is first of all important to differentiate: Urgent does not always mean it is important. Customer Facing roles such as Customer Success / Client Solutions are usually the loudest when it comes to push for the agenda of their tasks. They say, the customers request them. Does this mean, they are the most important tasks?
Organisationally we can label important tasks as more strategical or tactical activities while urgent tasks are more operational activities. Both are important. Strategies set broader activities to achieve your vision. But the operations will be manageable and usually obvious activities to support this strategy. The problem is, that in our daily work and teams, it is hard to understand, what really urgent ist.
Urgent vs. perceived urgent
I usually differentiate urgent activities from perceived urgent activities. This will give you usually a good indication for your prioritisation. Focus on real urgency – not perceived urgency. The difference in those activities will be the different result. One will create happy customers and one will make customers happy. As we know from Ash Maurya’s book Scaling Lean, happy customers are more sustainable as they will refer you to their network thanks to the received value.
Instead of just reacting to an “urgent task”, I recommend to first stop a minute, breathe (;-)) and ask yourself some important question, before you sacrifice part of your (un-)planned slack time:
- Who requests that? A client? A key account? How many clients?
- Would it make the service sustainable better?
- If we do not react, would the client leave us?
- Would a client recommend us or upgrade the service, if we do react?
- What would be the impact to wait another day / week / month?
Those 5 questions are usually answered within a few second. If you cannot really expect any implications out of the received answers, it is probably a perceived urgency over a real urgent issue. Most of the time, we deal with perceived urgency.
Example: Service Level Agreememt
Most organisations who create products are having a defined approach how to deal with clients in case the product delivery fails. I have seen Service Level Agreements (SLAs) trying to cover all eventualities with up to 7 different classification of bugs. These organisations create big quality assurance and customer success teams in order to deliver their promise of the SLA. In the end nobody is not delivering new features, but everybody is just trying to please every eventuality of any customer.
I therefore recommend basically three level of incidents:
- Major Blocker: Customer cannot use a core function of the system – Suggested action: Stop everything you do and fix it immediately.
- Minor Blocker: Customer can use a core function only through a workaround – Suggested action: Work on it in your next slack time. By latest pick it up on the top of your next Sprint Backlog.
- Everything else: It goes into the product backlog and can be evaluated by PO in discussions with stakeholders (We will discuss a technique on how to prioritise your product backlog in an upcoming topic).
A member of any product company probably would agree, that most of the incidents are of the third category. Some might fall intosecond category, but the least incidents will be of first category.
But I am not in a product company
The concept also works, if you are not working in product company. The message is not to organise your urgent activities, but to focus on an agreement with your stakeholders on when you would deliver. There you will find out something astonishingly. Most stakeholders are fine with how you plan your activities as long as you are transparent about them. And of course as long as you can deliver on your promise in 80% of the cases.
Stress is mostly the result of your reaction to certain situations and not how others make you react to it. As long as you deliver on Tuesdays when you promised to deliver on Tuesday, stakeholders are fine. If you are unsure about that, then don’t promise Tuesday, but Wednesday. If you deliver in the end a day earlier, there will be nobody who will be angry about it. Prioritisation has less to do how you can make your customers happy, but how you communicate them.
