14 Task Stages
Elisabeth Dickinson edited this page 2020-02-04 11:04:04 +01:00

Task management

  1. Create a task in the appropriate stage. Usually, that would be the leftmost column, but in some cases (e.g. qualified bug in the Help project) you may create the task in a different one (e.g. Bug Fixes).
  2. Use stars to define the priority of a task. In R&D projects, a star means that the task must be ready for the next SaaS.
  3. When a task should be moved to another stage (back or forth), update the kanban state (colored dot) accordingly:
    • grey = default state. The task is in progress.
    • green = ready to go. The task is ready for the next stage.
    • red = blocked. The task may have to return to the previous stage (e.g. Wrong Dev).
  4. When a task is green, drag it to the stage for which you're responsible. We are in a pull mode, not push, so tasks should be dragged from a stage on the left to your stage and not from your stage to a stage on the right.

Task stages

RD Spec

The product owner (for functional tasks) or a developer (for technical tasks) should write the specifications. The task usually comes from the RD Feedback project if it originates from feedback.

Stage responsible: product owner (PO) 🟢 Kanban states:

  • green = specs are written
  • red = specs are unclear

RD Dev

Implementation of the task by a developer. Keep the guidelines in mind.

Stage responsible: developer (BE & IN) 🟢 Kanban states:

  • green = implementation is done and tested (both with unit and exploratory tests)
  • red = help needed

RD Testing IN

Task testing is performed to ensure that the implementation didn't break anything. The testing comments are written in the pad.

Stage responsible: IN usability team 🟢 Kanban states:

  • green = all exploratory tests passed
  • red = bug(s) encountered, back to RD Dev

RD Validation BE

Quick technical review of the code to spot any big implementation issues.

Stage responsible: guru 🟢 Kanban states:

  • green = general structure of the code is correct
  • red = changes of code required

RD Testing BE

Functional testing of the task to check that it matches the specifications. It may happen that the PO changes the specs at this stage.

Stage responsible: product owner 🟢 Kanban states:

  • green = implementation meets the specifications
  • red = changes of code required

RD Review

Deep and thorough technical review to spot any issues in the code. The review comments are written on the pull request in GitHub.

Stage responsible: guru 🟢 Kanban states:

  • green = task has been merged
    • Add a tag of the targeted SaaS (always saasxx.x).
    • Add the migration tag to warn migration team that there are some scripts to write.
  • red = dev is wrong

RD Deployed (folded)

Deployed tasks. If the task doesn't require a release note (e.g. bugfixes) and has been merged (green in the previous stage), you can push it in this stage yourself.

Stage responsible: the product owner (customer of the task)

Cancelled (folded)

When tasks are not validated or aborted, they are cancelled and not deleted. A reason for the cancellation should be given in the chatter.