Tasks
Last updated
Last updated
Your board is now ready to be populated with your different tasks. Each task should be the indivisible parts of a goal or initiative. Tasks should usually take more than an hour but less than a week to complete. As a new task is discovered it should be written down following the template and protocols you set up within your team. When created tasks should be added to your task board in a future iteration or on the backlog, as once you start an iteration, its tasks should be locked in so your engineers are not continually shifting focus.
Now that your project management tool is fully set up, creating a task is trivial, but it's important to understand the different elements of a task before we should how to use them.
Field | Description |
---|---|
In the iteration that you want to assign the task to click Add item. Generally, new tasks should either be put it in the next iteration if you need to discuss it as a team or the No Iteration group. You can always add the item to any iteration, then change the Iteration field as needed. Give it a succinct title.
Press the enter key to create the item.
Click on the item to open a text editor for it. Use the Description field to enter in any useful details.
While still in the text editor, choose Convert to issue in the bottom right. Find your tasks repository to add it to.
Back on the task board, add the owner (Assignees).
Add the Status.
Add the Story Points/Dev Days (more on estimating those later).
The Iteration should already be set, but update it if needed.
Use the Completion History field as explained above. For brand new tasks, there will be nothing to add to this field at this time.
Add a user story (Milestone), if one exists.
If any, add the Labels.
The Linked Pull Requests will automatically be added as you link pull requests to this task (an example of how to do that is here. You just need to reference it in the description of the pull request).
Most project management tools make it easy to share a task (on Slack, email, etc.). Simply click on the task, and copy the URL. Note that only those that have permission to view the task will be able to see it, and only those that have edit access will be able to edit it.
Use this space to link to the design mocks or leave any technical details that could be useful for the future code reviewer or the developer who will be fulfilling this task.
Who is responsible for fulfilling the task.
Blocked: the task cannot be worked on due to a dependency on a person or another task needing to be fulfilled first. You should seek to eliminate all blockers ASAP.
Todo (or no status): no one is currently working on it.
In Progress: currently being worked on.
In Review: a pull/merge request is submitted for review or a document has finished its first draft and is posted for review.
In Verify: a request is pulled/merged into the main branch and pushed to your development/beta environment, waiting for release testing.
Passed Verify: the task has been validated in your test environment and is ready for production release.
Released (or archived): the task is released to production or otherwise completely resolved (see "done-done").
The iteration this task is currently assigned to. This can change during your iteration planning meetings.
The total estimated time this task will take. It can be updated each iteration as the owner better understands what needs to be accomplished, but generally, you should practice getting it right the first time. The more accurate your estimates are, the more likely you'll be able to predict what will get done in an iteration. We'll go over how to do task estimation later.
A log of the owner's best guesses on how far along the task is going from "In Progress" to "In Verify" stages as a percentage.
Generally, a task shouldn't be >50% complete if it is still untested and shouldn't be >90% if it isn't merged/pulled into the main branch.
I highly recommend keeping a completion history in a format like so: 40->90->100
. Where the latest number is the completion percentage at the end of the current iteration. Any previous number is the previous iteration's historical completion percentage.
This will become relevant when you'll use the completion history to determine the velocity of the team each iteration, which I discuss later.
The user story that is associated with this task.
Any labels associated with this task.
Any pull/merge requests for this task. Usually, this linking is done in the pull/merge request itself rather than done on the task board.