🩴
Bare TechOps
Time and Team Management
Time and Team Management
  • Time and Team Management
  • Practical Agile Development
    • Iteration
    • Task Board
    • Labels & User Stories
    • Tasks
    • Task Estimation
    • Iteration Planning & Review
    • Velocity Tracking
    • Closing Thoughts
  • OKRs & Initiatives
    • The OKR Pipeline
    • My Recommended OKR Tools
    • Closing Thoughts
  • Effective PTO
  • Deadlines
Powered by GitBook
On this page
  • Defining a task
  • Understanding the fields
  • Creating a task
  • Sharing tasks
  1. Practical Agile Development

Tasks

PreviousLabels & User StoriesNextTask Estimation

Last updated 3 years ago

Your board is now ready to be populated with your different tasks. Each task should be the indivisible parts of a . 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.

Defining a task

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.

Understanding the fields

Field
Description
Description

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.

AssigneesMemberOwner

Who is responsible for fulfilling the task.

Status
  • 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.

Iteration

The iteration this task is currently assigned to. This can change during your iteration planning meetings.

Story PointsDev Days
Completion History

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.

User StoryMilestoneDependencies
Labels
Linked Pull RequestsLinked Merge Requests

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.

Creating a task

  • 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 ().

  • 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 . You just need to reference it in the description of the pull request).

  • In the iteration that you want to assign the task to click + Add a card. Generally, new tasks should either be put it in the next iteration if you need to discuss it as a team or the Backlog. You can always add the item to any iteration, then drag the card to a different iteration list. Give it a succinct title.

  • Click away or press the enter key to create the card. Click on the card to edit its details.

  • Use the Description field to enter in any useful details.

  • Add the owner (Members).

  • Use the Status Dictionary list as a reference to add an appropriate Cover with the correct status color (if Todo, ignore the cover).

  • Click on the Story Points Power-Up to set the story points ().

  • For completion history, I recommend either to Write a comment... that you edit each iteration with the latest completion percent (option A), or you just leave a comment for each percentage change (option B). For brand new tasks, there will be nothing to add to at this time.

  • If any, add the Labels.

  • There are Power-Ups you can add to link your card to a specific GitHub, GitLab, or other repository service for linking your pull/merge requests. Search for and add the one you need.

  • Below is an example of using each of the described features.

Sharing tasks

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.

Released (or archived): the task is released to production or otherwise completely resolved (see "").

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 later.

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 .

The that is associated with this task.

Any associated with this task.

Either ignore this field or use the Dependencies Power-Up () to link this card to a user story card.

done-done
task estimation
later
goal or initiative
more on estimating those later
here
more on estimating those later
as explained in the User Stories section
user story
labels