As a developer / designer / manager it certainly is exciting to be the ninja super hero developing an exciting product. Smashing 🚩out features and seeing progress quicklyyy 🚩. I see a few red flags already…
Fortunately we have some concept tools to help with maintaining high quality process and a happy team running smoothly. There is this concept of P1 — or the 1st in Priority and P2 — the 2nd in Priority, P3, P4 and so on. A good example of P1 could be the hot-fix tickets — the critical bug fixes.A fairly simple idea, but let’s see what we could do with it.
Using P1/P2 distinction could help do 3 things:
— keep the teams happy — by providing clarity in priorities
— maintain the process of high quality — by not clutter the ‘to-do’ list with low-value items
— and as a result — lead to an excellent end product too 🙌,
Let’s say your team is already that awesome and uses the P1/P2 distinction. But is it misused and no longer the tool to keep high quality structure in place ? Has it instead become a bit of a spanking rod to pressure others in the team by dressing any task with the importance of ‘it is a P1!! 👻😱’ ? Did it suffered from scope creep ?
An example of P1/P2 misuse 🚩could look like : disregarding the reasons for versioning the tickets by immediate or wider members of team: noting distinct P1(hot-fix) , P2 , P3 tickets, only to pile it all as P1s later on.Followed by asking other devs to drop it like it’s hot anything they might be in the middle of in order to deliver ‘the new critical changes’…
Can you sense already how this is not a good process, how the product could suffer and the unhappiness of the team by just reading that tiny example?
What to consider when setting P1s and P2s ? How to make full use of them as the tool to guide and maintain high quality process => progress => results within the team?
— 1 . Consider the time / team resources
You now have MANY tickets to go through. But only some can be executed. Picking each one look at:
— The Time — Do we need to take into account the ‘hidden’ time needed for 1. testing 2. deployment and 3. any ‘in case something goes wrong’ cases? And generally is the task(s) too tall for the time available ?
— The Team — throw in a bit of empathy here — Are developers light on the ground ? Is it fair to push n number of P1 requests to the number of available devs ? Do they have other pre-scheduled activities ? (learning time, technical debt, team sessions etc. or just a ‘seas fire’ time after intense period of development work).
After considering the time and team resource — only the precious few tickets should now be given the P1 status.
— 2. Consider High vs. Low value
when distinguishing P1 (or the hot-fixes) and drawing a reasonable line– see if the quality is maintained using some high value indicators :
- Objective vs. Subjective. Is it P1 because I feel it is personally or because it is agreed as a team ? Is it a hot-fix or a nice-to-have ?
- Quality vs. Quantity* . Sticking to the few mutually agreed P1s and P2/P3 distinctions for tickets and avoiding the temptation of stacking all in one pile as P1s ☹️. Less is more.
- Receiving vs. Giving. Probably the most overlooked distinction. Next to expressing opinions check to — Improve the quality of listening within the team. Hearing the reasons for assigning P1/P2 statuses and versioning the tickets for a later release .
- V1.1 vs. V1.0 . Can it be versioned and released in due course (next 2–3 days ) to avoid compromising the release to production now ?
*Not having clear P1s can lead to rapid context switching — Poor understanding of the problem leads to poor solving of the problem /half fixing it / creating temporary patches
— 3. Being mindful we are not so headstrong focusing only on the End product
We are also working with 1. time resource available 2. teammates who are humans* and 3. software. These three combined bring about the quality of the end product.
*humans tend to want to have a lunch breaks
….Hopefully all of the above is a useful reminder that we have conceptual tools available for playing the game of building a high-quality product sustainably and within an awesome product team 👏
