Engineering is more than just the code you type on a computer or the design you envisioned for some new machinery, engineering is a intelligent style of life that helps people become more efficient, get work done faster and achieve higher than anyone else has ever done.

In the software engineering industry, engineers usually face this dilemma of the prioritization of tasks.

Looking at the agile board, a lot of tasks seem to be of a high priority or P0 but there’s only so much time left before the deadline.

It becomes even more confusing for an entrepreneur in the software industry when there are multiple clients asking for their feature work to be done now all at the same time!

Being in many of these situations myself I thought to myself, if I were able to categorize these tasks I might be able to find the best way to prioritize these tasks and communicate more accurate release dates than before.

Any task out there in the universe falls within one or two of three categories, I encapsulated them in the following three questions:

What can be done now?

What can be done later?

What can be done in parallel?

Let’s talk about those in detail …

What can be done now?

Tasks that can be done now don’t necessarily have to be the tasks with the highest priorities, but rather tasks with the least blockers or impediments.

For instance, changing the background color of a button on a web page versus integrating with an API of an external team that don’t have their swagger published yet.

Changing the button’s color isn’t a high priority, but since the highest priority task requires e-mails and communications back and forth with an external team, then the button task qualifies as something that can be done now, it reflects progress and it doesn’t block or impede another task with higher priority.

What can be done later?

There are some tasks that can be delayed due to either it’s dependency on other tasks or having a lesser priority than other tasks.

For instance, adding a copyrights notice at the footer of a website is a task that can be done later, it comes next to creating a website in the first place, and having some content to be copyrighted!

But tasks that can be done later could turn into a high priority tasks so fast when engineers start to abandon them, they turn into this monster that we call tech debt.

Tech debt is just like credit card debt, if you don’t take care of it right away it becomes a pain to get rid of and I have seen situations when tech debt has grown out of control to the point where adding new features took two or three times as much effort as they would if the solution had a lot less tech debt.

In order for tasks that can be done later not to turn into a tech debt nightmare, they have to be treated as high priority tasks once the actual high priority tasks are done, in a queue kind of fashion, let’s say for your first sprint you have already prioritized your tasks as follows:

Sprint 1:

Task P0: API integration

Task P1: Render API data

Task P2: modularize API integration into its own library

Sprint 2:

Task P0: Implement API Post data

Task P1: Design input form

Task P2: Document modularized API library

In the scenario above, if you run out of time at Sprint 1 before task P2 is done, this task become a deliverable that needs to be done as P0 before moving forward with any other feature work, that’s because if you’re done with P0 and P1 in Sprint 2 you will end up with two tasks to finish up as tech debt and it keeps accumulating to N number of times for as long as you are working on feature deliverables.

At some point in time, the modularization of an API library that you should have done in Sprint 1 becomes an issue since everyone is writing their own API integration on their own project, which means if the API contract changes you will end up changing the code in N number of projects instead of just changing the library that encapsulated that functionality.

What can be done in parallel?

Some tasks regardless of their priority can be done in parallel, whether they can be done now or later.

For instance, kicking off a data migration while fixing a defect are things that can be done in parallel.

Identifying these tasks can help you get a lot more done in a shorter amount of time, because if you cannot identify these tasks they will end up running as a single tasks that cannot be parallelized since everything else is either impeded or also singular tasks that require 100% focus.

Another good example of tasks that can be done in parallel are the tasks that require more information and communication with other team members or clients.

You can run a full conversation around a future task while working on other tasks without any interruption or decrease of performance for any of these tasks.

These categories may have more sub-categories that I may run into the more I explore this concept, the difference that I experienced before and after categorizing my daily tasks was outstanding, especially for an engineer sometimes we might get caught on a task that might consume the majority of our time while there are other tasks out there that can be done right now, in parallel and of higher priority.

This is where engineering becomes less of just a day job and more of an intelligent lifestyle that makes us more efficient, faster and takes us to places we never imagined they even existed.