In my opinion the ability to prioritise is one of the most important skills people should try to master. The problem with prioritisation is that it is not easy. We inherently don’t like making decisions, we also don’t like making sacrifices and sometime we do not want to face the ugly truth which is we can’t have everything we want, so we use hope and bury our head in the sand and wish for good fortune to come along to magically deliver all the things we want.

One of the reasons agile processes have become so successful is that it forces us to constantly prioritise. For those that find it difficult making decisions agile processes provide a great framework without fear of retribution for safe decision making. Knowing that you can revisit your decisions and make new ones based on the latest information is incredibly empowering. Prioritisation activities become a daily activity and so we are always evaluating the most important things and moving them to the top of the list.

But how do we decide what item is more important than another? Well it is difficult to say without being specific but here are some things that I have learnt along the way.

In summary these are:

• Creating a living list and instill the evaluation of this list in your every day life
• Understand and identify Important Vs Urgent tasks
• Decide on a feature or milestone date driven release
• Decide on the minimal set of features
• Identify items of architectural significance
• Identify difficult or high risk items
• Constantly evaluate and re-evaluate
• Make sure you understand the goal (and how this might change over time)

First things first: Create a list!

I run my life using lists and I do this every day and evaluate that list all day. The first thing I do when I start my working day is write a list of things I need to do. I look at my calendar  and I review my previous days list and I make sure that today’s list contains both important and urgent items (more on this later). Any project large or small starts with personal prioritisation of individual tasks. Even if you are not working on a project I bet you still have more things to do than you have time for! The way I prioritise long-term projects and objectives differs to how I prioritise for short-term projects. For long-term objectives I like to categorise the different things that I need to achieve, I do this because I want to make sure I have a good balance of goals. For example I have a category of tasks specifically dedicated to personal development, training and mentoring, and other categories for more immediate work or personal related tasks such as demo preparation, blogging or even sorting out my tax returns! I do this because I want to make sure that I have a broad range of achievements and if, for example I didn’t specifically call out personal development activities then these activities would always gets pushed for something more urgent (again, more on this later). So if on my list I don’t have any of personal development activities then I will prioritise accordingly and raise the priority of tasks that fit into this category. This brings me to my next point on how I prioritise.

Focus and remain focused on what is Important vs Urgent

Many years ago I read about the importance of doing importance Vs urgent, I can’t remember where I read or heard this but understanding which of your tasks are important and which are urgent really helps to keep you focused and ensures that you don’t end up running around like a headless chicken doing tasks that are always urgent. Without this technique I used to prioritse tasks based on what needed to be done sooner (urgent) rather than tasks that where more aligned to the goal I wanted or needed to achieve (important). All important tasks become urgent at some stage but the truth cannot be said about urgent tasks. Not all urgent tasks are important, particularly when taken in the content of your wider goals. For example, every Friday I have a task where for 30 minutes I search and investigate the different training options available to me (I’ll write about the impressive amount of training Microsoft provides its employees in a future post). Now this task is rarely urgent (perhaps only at the my end of year review) but it is a task that is always important. It is important becomes it makes me a better person and over time means I can achieve more, over the medium term I feel happier because I am developing my individual skills. If I didn’t use this technique I would simply revert back doing tasks that needed completing that day or coming days. So when you draw up your list of tasks ask yourself which tasks are important and which are urgent and prioritise accordingly. If you are like me and find yourself feeling guilty because you are working on something that has a later due date than another task on your list, then this should help endorse your decision to work on the more important task even if its due date is some way off.

Feature or Time Driven Milestones

From a product or project release perspective decide if your milestones are time driven or feature driven. A time driven release is one where you need to ship a product by a particular date, perhaps an event where you need to showcase your product, a regulatory change coming into force or a season release such a Christmas are just some examples of a product that in under a time driven schedule. In these examples then you are going to sacrifice lower priority features to ensure that you met the release date. The release date will remain fixed but exactly what is going to ship will vary.

A feature driven release schedule then is one where you are concerned that the product meets minimum feature requirements and as soon as these feature requirements have been met then you are ready to release. Perhaps your product needs the ability to store additional information as you are integrating with another system in which case you cannot ship the product until the new fields are there and although it needs to be delivered asap (what doesn’t) the release is meaningless until the new fields are on the form.

So the next question is what about projects that are both feature and time driven. In my experience this is all projects and none of them. Business stakeholders like the rest of us don’t like making sacrifices and they will ask for all the features then want at a specific date. An experienced product or project manager will get under the skin of the project and will very quickly help educate the stakeholders and create feature or time based release plan.

For clarity a sprint is different to a release. So even though you might have a release scheduled for the 1st december does not mean you have a 6 month sprint. You sill have 2 week sprints (or whatever you have decided) but it means that you wont ship to the vast majority of your users until the 1st of December. As my sprint get closer to the release date my sprint task have less and less features and more release based tasks such as deployment plans, training guides, demo scripts etc. Try and find the right balance in your release cycle, six months is probably too long but you probably don’t want to release every few days either as you just be spending you time planning and deployment and little time on new feature development. I’m making some huge assumptions here, clearly the appropriate release schedule will be dependent on your product and specific circumstances such as deploymen tmodel (on premise, online).

Decide the minimal set of features that need to be delivered

Irrespective of how you have chosen to release the product (time driven or feature driven) you are going to need to work our what are the minimal set of features required for each feature that make up a worthwhile release. The best way to do this is to work directly with the users, see how they interact with the software will ultimately determine what it worthwhile and what is not. There are many techniques on doing this and I’ll cover this subject in a separate post. For now however, focus on the features that satisfy the most valuable aspects of the customer journey.  I run the risk of going off topic here but I want to give you a quick example. Amazon have a technique called “working backwards”, in summary they write the internal press release first and then they develop, any items that are not on the press release get dropped. Develop for the 80% not the 20%

Identify and tag items that are architecturally significant

During your sprint planning session identify features or tasks that may be architecturally significant. You may need to prioritise the architecturally significant tasks over features for the long term benefit of the product. This is an exception to the rule of user first and MVP but it is absolutely critical to get right. You need to balance creating an architecture that is so scalable and extensible that is is overly complex and difficult to maintain vs a product that needs to be rearchitected.

Identify and tag items that are high risk or difficult to deliver

Identify tasks that are going to be difficult or are high risk. Tackle them early so you have to implement remediation steps. You might need to add additional team members or implement some form of workaround and identifying these issues early will give you the time you need to work out a mitigation strategy.

Constantly evaluate and re-evaluate

Finally just because you have a list doesn’t mean you need to stick to it. Be agile, keep evaluating and reevaluating your list and feel free to make changes. If your objectives (or your projects objectives) are clear then you will find yourself less stressed and much more likely yo deliver successful projects and outcomes.

This posting is provided “AS IS” with no warranties, and confers no rights.

Next on Mark Margolis’s Blog: TBC