Tasktop how-to: Create tasks with style
, 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.


February 26th, 2009 at 7:14 pm
“…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…” - this is a direct consequence of the present limitation of Mylyn’s Task List view that does not allow custom task categorization, nor allow to search trough the task descriptions.
February 27th, 2009 at 11:31 am
Eugene’s comment raises an important point for task management systems. The underlying question being how much of a task should be structured (e.g., the priority, owner, and due date fields) versus how much should be represented in natural language. Our task schema has evolved to be quite generic, and to allow connectors to specify it further (e.g., how Rally adds Agile concepts in its connector). But no matter how that schema evolves, we believe that there will always be a role for natural language in describing tasks and this set of best practices is meant to give you guidance in this unstructured part of the task.
For users interested in categorization, your options are currently to use either the task repositories’ mechanism and queries (e.g., keywords in Bugzilla) or to use categories, which can be used to tag both local and repository tasks. For users that want to search the task description you can use the “Task Search” dialog and search all tasks on a certain server. Users that wish to find a local task can use the instant summary search that the Task List provides, but note that this searches the summary and not the description.
March 17th, 2009 at 7:31 pm
David, I believe you are missing the point. Server side keywords or Task List categories are perfect example what I was referring too - they bot are too limited. Compare it for example with delicious bookmarks where you can create multi dimensional categories and apply multiple categories or even intersection of categories to individual tasks. This would be a very powerful feature and also very easy to implement.
March 18th, 2009 at 3:33 pm
This particular feature has been requested by others [https://bugs.eclipse.org/bugs/show_bug.cgi?id=165391] and has been considered. I can imagine how it would be useful, but it does add complexity. For example, it would be easy to get into a mode where instead of a simple monocline grouping [http://wiki.eclipse.org/Mylyn/UI_Design#Avoid_Hierarchies] the user has a single task scattered across multiple containers. Between that, and the relatively low interest in this feature the Mylyn committers have decided not to add this feature yet.
However, there is a work-around for this that is supported by several repositories. When using Bugzilla, for instance, you can create queries for specific keywords, which allows you to group tasks in the task list just as tagging would. Trac also supports querying by keywords. I would encourage Tasktop and Mylyn users interested in this feature to try using the workaround and comment on the above bug if you find that this feature would significantly improve your workflow.