Definition of Priority Codes ( P0, P1, P2, P3, P4 ) in Technical Development


I thought this topic is clear, but I’ve run into this again very recently. Since so much conflicting information is going around, let’s iterate once again on what the priority codes should mean. I’m drawing this originally from Jira definitions¬† – I think that’s where i saw it first, and it is the most sensible.

  • P0 – the work stops, site is down
  • P1 – unblock someone else, required to be done before other things
  • P2 – ordinary flow of work
  • P3 – nice to have, but not required
  • P4 – informational only

I recently saw another definition coming from a more “senior” individual, and it almost made sense, until it didn’t. At which time I stopped and re-evaluated the definitions for myself, once again. The faulty definition was:

  • (DO NOT USE)
  • P0 – the work stops
  • P1 – the task affects customers
  • P2 – the task affects customers, but there is a non-technical workaround solution
  • P3 – the task doesn’t affect customers
  • P4 – informational / never used
  • (DO NOT USE)

The problem with the faulty definition is that everything is P1, and nothing can really be escalated to P0. P4 is completely useless, and junior PM’s and developers would usually create P3’s (the default in Jira), positioning themselves for a need to clarify or shift priorities, etc.

Another thing to note. The priority definitions are technical. They aren’t written with customers in mind – there are multiple layers between devs and customers, and the priority codes are for developers more than anyone else.

The default code is P2. If the work doesn’t need to be done, save the resources and time and don’t do it; change the priority to P3. If there is a change that a task needs to be done sooner rather than later, bump it to P1. And the P4 is effectively never used, because informational stuff resides in wikis and other communication channels..

80/20

80% stress, 20% relax

This came up in Financial Times today. We aren’t Millenials, we’re Generation Burnout. We work too hard for too little, and do ourselves a disfavor by not seeing the forest for the trees. What’s the goal, anyway?

I say, leave some of your time (and money) unallocated. I say, if the problem is that we work too hard and spread ourselves too thin, let’s stop doing that. Cut yourself some slack, and have time and resources that are unallocated. This helps you cope with stress, AND allows you to effectively deal with instantaneous things that come up. If you have free time, you don’t have to schedule every little thing to be done later, you can just do it now.

Overall, look at the 80/20 rule, it’s quite interesting.

Cadence

Word of the day: cadence

It does not quite refer to my little pony, it’s more of a corporate cultural term.

You can also say “velocity”, you can say “agility” to mean the same concept.

It’s how quickly and effectively you get stuff done. If the sprint is 2 weeks and you pack two sprint’s worth of work into one, that’s high cadence.

If you are able to bring teammembers together to solve a challenging challenge, it’s cadence.

You say, “we like the increased cadence this fiscal quarter.”

It generally refers to productivity. It is one of the highest states to aspire for.

5 ways of finding a career match


To correct what I’ve said yesterday, the 5 ways of finding a career match are:
* live fit (career choices, location, compensation, company size)
* technology fit (candidate’s skills align and candidate has the necessary skills)
* cultural fit (candidate’s acceptance of the company’s management style, situational judgement test, personality test)
* personal fit (do I want to work with him? does he want to work in this team?)
* other factors (a blanket category for red flags and whatever you cannot disclose)

On Pair Programming

And why you shouldn’t do it. Teamwork is great. But arranged marriage isn’t. Managers, what are the requirements for keeping your workforce happy?

Marketing

Let’s talk about the mechanisms of getting business

Let’s talk specifically about software development by small independent shops such as myself.

Live Systems

Everything changes. And change works – life itself has proven that.

In technology, you would think that since computers are very good at repeating something very exactly over and over again, things in the digital world sometimes wouldn’t change… But they do. They have to. There is somethign called digital rot – everything rots if it doesn’t change. Relationships rot (try not talking to a close friend for a week), tools rot (who uses myspace anymore?), and if a digital offering doesn’t undergo continuous change, it gets left behind and dies off. So you have to change, and your products and services have to evolve, or be left to “die.”

What twitch.tv teaches us also is that a good media service has to be updated very regularly. Preferably every day. If something is not happening in a channel for a day, it’ll start losing popularity. So you have to continue innovating, continue generating content, and be more varied and precisely match what current trends are set by the market. It’s a hard job, but it’s the only way to survive (and prosper).

The good news is that if you are very new, if you’re just starting out, the continuous change aspect of things doesn’t disadvantage you, on the contrary! As something new on the field, your product/service has room to grow, you haven’t figured everything out so there is very much room for change, and change is often good. So it’s a natural way to level the playing field: the newcomers have this edge over the old-timers, in that the newcomers will necessarily change.

Corporate Goals

Let me talk about why any company exists (summary of the book, The Goal)

The purpose of a company is to make money.

(Another purpose is to improve lives of people some way or another, although this is much secondary to the first goal.)