What is a Task?
A task is either a...
- Problem to be solved: This is a specific issue that we are trying to address through our work. For example: “Homepage bounce rate is too high”
- Outcome to be achieved: This is something additive that we want to accomplish or implement, which is better described in the positive. For example: “Purchase and install Craft license key”
The task title in a software tool should generally reflect one of these formats. Bugs and issues typically are best stated as problems, whereas additive work is best phrased as an outcome.
The Project Manager is responsible for writing tasks based on the requirements of the client. However, Project Managers are often not experts in the work to be done, so they should get help from Strategists, Designers, and Developers in order to ensure tasks are clear.
Assignment
Tasks should stay assigned to one person (usually a designer or developer) for the lifecycle of the task instead of moving from person to person. The one person is principally accountable for Cantilever getting the work done. They are responsible for requesting required Strategic, Peer Review, and QA approvals.
Example: If Roman takes on a new task for BPC, Roman will stay assigned to that task in Asana until it is deployed. During the Approval and QA process, other people will be assigned sub-tasks for those approvals, but the main task will stay on Roman.
As a part of task clarification, PMs should add sub-tasks for any approvals they believe are required to consider the task complete. However, the assignee is also free to add additional approvals that would make them feel certain that the work is in good shape.
Task Lifecycle (Statuses)
Most tasks start with some sort of client request – either in the context of a larger project, or individually. For example, if we support a website, the client may ask for us to update WordPress.
The PM is in charge of getting that item into Asana and the Big Board when it is ready to be scheduled. The task moves through our Statuses until it is completed:
- Task Definition: The PM should evaluate the request and understand it fully. Why does the client want to update WordPress? What is the underlying need they want to address? What are the implications? When do they expect it done by? How important is it to them? All constraints should be clear. The PM should define “done” and determine what an appropriate testing plan would be for the work.
- If the PM needs help in understanding the problem we are solving or the technical details, they should lean on the rest of the team to help fill in the task. A common method would be to assign a team member a sub-task to add aspects of clarification to the task.
- Assignment: The PM should get the task into the Big Board, where it will be visible to the whole team for assignment. The PM or strategist may request that a specific team member take it on. Otherwise, it will be assigned during the Sprint meeting prior to the sprint starting. The assignee should not take on the work without agreeing to all the details, including the estimate and timeline.
- Execution: The assignee is then responsible for completing the task. When ready for review, the assignee is responsible for assigning the relevant approval sub-tasks.
- Review: Reviewers including QA people should review the work against the “Definition of Done”.
- Release: Once all approvals are Accepted, the assignee should deliver the work by deploying it or sending it to the client, per the “Definition of Done”. Once complete, the artisan can mark the task “Complete”.
Task Fields
We want all tasks to contain a standardized set of information. The strategist is the lead accountable party in making sure that each of these things is clear in each task on a project. However, the PM should help, particularly with scheduling and assignment, based on other resource constraints across the company. While there are a lot of fields here, most of them take negligible effort to specify, and they are all critical to ensure that our workflow is smooth.
| Name | Example |
|---|---|
Assignee | Sherbert the Sheep |
Due Date | 4/15/22 |
Status | “In Progress” |
Importance | “Medium” |
Problem Statement/Overview | “The client’s Wordpress site has 5 plugins with available upgrades. This presents a security risk for the site” / “The client’s Wordpress site has all its plugins fully updated, ensuring that there is no security risk from outdated plugins” |
Solution Ideas (Optional) | “You should be able to update the plugins using the WordPress control panel.” |
Definition of Done | • You have updated all the plugins on staging
• You have done a quick check to make sure that the site is working properly
• You have passed this task to QA |
Time Constraints | Our deadline field covers this, but you can also add a nice big of clarifying language, such as: “We want to launch this by Friday so please complete this on staging by Wednesday.” |
Budget Constraints | Our estimate field covers this, but you can also add a nice big of clarifying language, such as: “The client has one hour left in their budget so let’s try to spend at most 30 minutes on this.” |
Approval Sub-Tasks | Strategist Approval, QA Approval |
Blockers
Tasks can become “Blocked” when they cannot proceed before some external requirement is satisfied. For example, a task to update the about page with new headshots is blocked until the new headshots are provided. We should use some sort of indicator in our PM tools to differentiate between blocked and non-blocked tasks. In Asana we use dependencies.