This article is part of our project management methodology series.
In a certain way, the health of your task list mirrors the health of your team’s productivity. Considering this, there is a good way and a bad way to write the items in your task list. In this article, we explore both.
We are all familiar with this scenario: We start our workday as we open our team’s task list and our eyes pop in front of something reading “Upgrade website”, “X integration”, “Write an article”.
We scratch our heads wondering what actually needs to be done, who’s doing what, and where to start?
Not to mention all those deserted tasks you wrote weeks ago. How likely would you remember what you were supposed to do with those back then?
Now, let’s see what’s behind this mess, and if there is a way to handle it.
Vague Task Descriptions
Example: “Anchor links on blog”
Ok, what? What do you do with this?
Admit it, when writing your tasks, as most of us, you usually devote just enough effort to make shorthand text that serves you to jog your memory.
But, by the time you get your hands on it, the memory has past. When you’re not clear and specific, you can’t tell if you’re moving in any direction at all.
Using general terms in task descriptions may save time in the short run, but is not best in the long run.
What often happens is that a certain task waits to be tackled in the future. The person later reading the task may not remember what the task was about, or could be a different person entirely.
Most importantly, if your tasks are not defined to result in a deliverable, you are not thinking clearly enough about what you really need to do.
So, here’s how you can make it more specific (later, we will show you how to be precise)
“Insert anchor links to subtitles in the X blog article”
Now, imagine you assign something like “Fix Split view bug” to your teammate or even worse this gets assigned to you. What bug? What to do with it and when? How important is it?
The assumption is the mother of all mistakes.
You may expect people in your team to be instinctual and vigilant, but it doesn’t make them capable of reading other people’s minds.
Here’s how you can make it easier for your teammate to precisely understand the task at hand:
Fix this bug: “When a user adds an email as a task in Split View, 2 tasks are created instead of one” Priority: Urgent
Oversimplifying Complex Task’s
Example: “Write blog content”
Content about what? Where to start?
The vague description is not the only problem. It’s about the underlying nuance. Usually, it happens that these shorthand and unclear tasks are actually big enough to be comprised of several subtasks. And be sure those will hit as you’re getting closer to a deadline.
It’s the same pain with some personal tasks like “Clean the garage”. This ain’t a simple task, it’s a project. Once you realize it, bet you’ll actively avoid starting work on it.
So to say “write blog content” is surely multistep; as it requires topic research, drafts, peer review, editing, and eventually publishing.
So, a better way to breaking down such tasks could be to say:
“Blog request: Write an article about how to write better task descriptions.”
- “Draft the article storyline”
- “Review the article draft with John to add improvements”
- “Email Mike the designer to request visuals for the article”
- “Edit the article to prepare it for publishing”
At the end of a day, it is important to take responsibility for writing tasks in a way that serves you and your team.
Responsibility comes with taking the ownership over the tasks you commit to do, and everything should fit with your team’s goals.
This means everybody on the team understands why they are doing what they are doing, and how their individual tasks contribute to the big picture.
If tasks are written in a lazy and imprudent way, it’s likely that team members will execute them that way. It’s like team members playing with hammer and nails.
Hey John, what have you accomplished today? Oh, I hit 3 nails. Way to go John! and why was that important for our business? Well, why should I know? Others asked me to do it, and I did it.
You get the message, don’t be like John.
How to Write Better Task Descriptions
First, define the purpose by asking “Why?” You need to know where you’re going before plotting the course. Answering this question establishes a successful outcome, sets the constraints, and focuses your efforts.
Next, start with the end in mind. To figure out how to do something, visualize the end result.
Then, you can start articulating tasks. You have thought through your task to a point where you can envision their execution. At this point, you will be able to define your next actions.
Each task needs:
- A clear deliverable
- A verb to describes the action performed
- Specific details such as due date, responsibilities
- A context around timelines, effort, priority, and type of work…
What we find as a good reference point for practicality is the agile approach to writing tasks.
As an example, this approach suggests describing project deliverables as User Stories, that can be easily broken into Tasks.
A User Story stands as a clear deliverable, an incremental value put in the user perspective.
For writing it, use a template: As a <type of user>, I want <to perform an action> so that I can <achieve some goal/benefit/value>
On the other hand, a task is an action step taken by the team, required to be done in order to make a complete deliverable.
So let’s go through the example:
Start with the business reason: Since people are getting out of the habit of shopping by foot, we will need to bring our products closer to them. For this purpose, we want to build a website for an online shopping, where people will be able to buy our products in an easy way.
When visualizing the end result, we come up with some User Stories or general tasks:
- As a buyer, I want to register on the website to access the online shop.
- As a buyer, I want to see a list of products to choose from the list.
- As a buyer, I would like to read a product description to aid my purchasing decision.
Once we know what the end result should be, we will think through how we to accomplish it, and start defining the next actions – our tasks.
As an example, to deliver the item: “As a buyer I would like to read a product description to aid my purchasing decision”, you will likely need some of the following tasks:
- Draft text for female shirts product descriptions.
- Review text for female shirts product description with Susan from the marketing team.
- Draft mockups for product list page, show where to place visual and text details.
- Schedule product photo shoot with Jane, the photographer
- Implement “click to read more” function so the buyer can read the product description
- Test “click the read more” function to verify responsiveness
In review, a well-written task has four specific components.
Keeping the end in mind is paramount to knowing what the next action will be. These are the deliverables to complete. Describing them in this way helps to closely identify your priorities.
Tasks As Action Steps
Using verbs indicates that an action must be completed. To keep it simple, construct the task in a form: “verb the noun with the object to accomplish”. This way, you get a better-defined task with clear objectives from beginning and to end.If your tasks are written in a lazy and imprudent way, it’s likely that you'll execute them that way.Click To Tweet
It also enables you to stay on track and know what comes next. This also ensures a distinction is made between single, and multi-step tasks.
Put simply, there are verbs to suggest a single physical next action, and there are verbs that suggest a desired outcome with more than one step. Here are few examples:
Multistep: Finalize, Organize, Design, Implement, Install…
Single step: Draft, Call, Email, Review, Edit, Look into…
Certain tasks can appear larger when you start to think of all the steps to finish it. Breaking these down into simpler tasks makes them less burdensome complete.
Provide Specific Details
Providing enough details to make tasks trackable, but so much to make your team lost can present a challenge. This is where you address “who is involved?”, “when?”, “how?”, and “to achieve what?”.
Being able to understand where and why each other work fits into the bigger picture can be incredibly helpful for all your team members. This starts by adding deeper meaning to the tasks.
Make sure to include the time frame, so everyone can understand when something needs to be done. Prioritize tasks in a clear way that describes which are most important. Specify the type of the work, or to which project certain tasks are referring.
Altogether, being clear on the overall context helps your team to estimate and decide how much effort certain tasks will require and how to handle them.
Writing tasks is not mastered overnight. It takes practice to get it right. And so it takes some time, but it also saves a lot more of it. The trick is that tasks can be made easier long before they are undertaken, simply by framing and defining them properly, in the right-sized units.
Failing to do this is a primary cause of miscommunication happening further down the line. Make sure task descriptions are thought through and take the time to make the tasks clear for everybody on your team and “do-able” for yourself.
Hope we managed to shed some light on how to write proper task descriptions. Try applying some of the tips from above and let us know if those worked for you.
In the meantime, help us share it with the rest of the teams out there!