Tasktop how-to: Create tasks with style
Thursday, February 26th, 2009| Applies to: | Tasktop Pro, Tasktop Starter, and Mylyn |
| Level: | Intermediate |
| Summary: | Learn how to create tasks with good style, speeding your personal workflow and facilitating collaboration |
Tasks are a vehicle for communication. Tasks that you create may be completed by others, and next month you might resume tasks that you create today. Whether communicating with others or with your future self, your style of communication will affect its clarity. A task you create named do the coding, while possibly meaningful when you created it, will not be clear in three weeks when you resume it. To assist you in creating tasks with style, we present the following guidelines and tips. These guidelines improve communication while also improving more technical task qualities such as searchability. If you have other naming patterns that you are using, please consider commenting on this post, as we are always iterating on these guidelines based on our understanding of task usage.
Naming tasks
Naming tasks is a surprisingly important step in task creation, as it affects a variety of task qualities. A carefully named task is straightforward to search for and, once found, easy to begin or resume work on because it is easy to understand. Follow these guidelines to create well-named tasks:
- Start with a verb, follow with the object(s): Most task names naturally consist of a verb and one or more objects (nouns). If you consistently order these components of the task name then it is easier to scan each name, to search task names, and to categorize tasks.
Example: addverb content assistobject for tasksobject 2
- Be specific: Using specific verbs and nouns when formulating a new task name will make this task easier to search for at a later time and will make the purpose of an older task easier to recall. In addition, being specific when naming tasks makes it easy for collaborators to understand your task.
Example: addverb open report buttonobject for timesheets pageobject 2 Anti-Pattern: makeverb buttonobject for pageobject 2
We provide two types of examples to make our guidelines more concrete. First we provide a list of verbs that commonly appear in task names. Note that many verbs are domain specific and so the most commonly used verbs will differ depending on your domain.
| Common tasks | write, blog, post, submit, brainstorm, update, purchase, review, improve, investigate, consider, explore | |
| Ongoing tasks | plan, manage, track, maintain | |
| Development tasks | add, integrate, support, design, document, test, refactor, fix, clean up |
We also provide examples of complete task names that follow the above guidelines:
|
Anti-patterns when naming tasks
In addition to these guidelines we have also indentified the following anti-patterns. These anti-patterns, derived from the guidelines, address common mistakes that are made when naming tasks.
- Avoid ambiguous references: During the act of naming tasks it often feels like overkill to precisely name all objects involved, and you will be tempted to create tasks like update wizard icons on the page. While it is clear at the time which page you are referring to, by the time you are able to work on that task it will require thought to recall, at best wasting time, at worst creating an incorrect product.
- Avoid adverbs: Avoid starting task names with adverbs like “quickly” or “carefully”, since they are often related to planning or priority information and not to the goal of the task.
- Avoid names and dates: Tasks are decomposed into separate fields, such as “Due Date” or “Assigned To”, so that tasks can be presented according to their properties. For instance, tasks with overdue deadlines can be shown as red. Do not include information that belongs in other task fields in the name, including collaborator names, due dates, and project names. The task named implement refresh with Todd will become inconsistent if you change your CC field to include John instead of Todd.
- Omit common verbs: Bug reports are traditionally named with a summary of a problem. For example, tasks losing scheduled date after restart. In this sense, all defect reports are implicitly prefixed with some variant of a verb like “fix”. Since the verb could be the same for all bugs, there is not much value in adding it.
Following all of these guidelines and tips when naming tasks will lead to increased output that both yourself and your collaborators will appreciate. While it can be difficult to appreciate these guidelines in the abstract, concrete tasks that break these guidelines serve as an enlightening illustration. Here’s an example that breaks the guidelines and tips for naming tasks:
|
Scoping tasks
Other providers of task management systems (e.g., CollabNet, 43 Folders) agree that tasks should be reasonably sized, usually defined in terms of the estimated time to complete a task. These providers recommend avoiding tasks that are too small (e.g., type a method header), because you will spend too much time tracking every detail, or too large (e.g., implement the product), because you are likely to become overwhelmed or lost. We avoid more precise scoping rules because we have found that following our task naming guidelines, especially “be specific”, naturally leads to well-scoped tasks.
Describing tasks
Although naming a task is the most important aspect of creating a task, there are several other task fields that can be completed during task creation. Here we provide a table with recommended content for several important fields:
| Description | Use this field to elaborate on the summary. It should begin by using prose to describe the goal of the task, a relevant use case, or even steps to reproduce a bug. We find three sentences or less is usually sufficient. Other task information, such as stack traces, pointers to reference material, or long email threads are good candidates for comments, as they would cause the description to become too long, pushing other relevant task information off of the screen. | |
| Time | When tasks are meant to be completed at some point in a given time window, as in agile processes, use the “milestone” field (or equivalent). When tasks must be completed before a specific date (e.g., filing your taxes), use the “due date” field. | |
| Priority | This field specifies how important the task is to the success of the company, product, etc. It is important that this field is set with some thought, as task priority is used to highlight the most important tasks in the Task List. Consider reserving the highest priority for tasks that must be completed ASAP. |
Giving tasks a good home
When using Tasktop, you can choose to either create local tasks (on your machine only) or shared tasks (on a server, shared with others). If you are the only person involved in the entire lifecycle of a task, create a local task. If any collaboration is involved, e.g., input from others, the task forms a part of a product release cycle, it should be a shared task. Don’t worry if you’re not sure at task creation time where your task should live as it is easy to move between local and shared tasks using Tasktop’s “Send To” action in the Task List.
When using shared tasks collaboration is simple; you can add collaborators to a task and track task communication on the task comment thread. Collaborators can use a variety of repositories so Tasktop offers several Tasktop Certified Connectors (i.e., that connect Tasktop to the repository). To begin sharing tasks browse and download Tasktop Certified Connectors.
|
|
During the course of a project you and your team could create hundreds or even thousands of tasks. If your team follows these task creation guidelines you will save time searching for old tasks, remembering the goal of an existing task, and interpreting a task someone else has assigned to you. You and your team will understand the benefits of working with your task management system, instead of against it, as you begin creating tasks with style.
