Redefine the task-assignment process to reduce uncertainty
Hi :)
I think we can split the second step on the Task Workflow. Change it from:
- Create the task. Early in the process, tasks can have a sparser description than required by the task description standard for example to create a placeholder task to include in the sprint before the task creation cut-off.
- Refine the task. This means to improve its description to match the task description standard, determine whether it's appropriate for the sprint, who should take it, who should review it, and how many story points it probably requires. To ease planning, this should be done as early as possible - but in any case, no later than the end of the Friday before the sprint start.
- Do the task. How each task is generally "done" depends on its type; see more in the sections below.
- Review the task (internal/upstream). How one reviews a task will tend to mirror how one does it. For example, discovery tasks generally don't require writing test code, so a review would also generally not require testing anything step by step, as it would be the case for a general task.
- Close the task.
To something like:
- Create: Early in the process, tasks can have a sparser description than required by the task description standard for example to create a placeholder task to include in the sprint before the task creation cut-off.
- Refine: Improve the specification and polish the ticket to match the task description standard (including story point and time estimate), determine whether it's appropriate for the sprint; optionally suggest assignee and reviewers. This should be done as early as possible - but in any case, no later than the end of the Friday before the sprint start.
- Allocate: Assign the task to someone (or yourself), including Assignee and Reviewer. Address their questions and comments.
- Do: How each task is generally "done" depends on its type; see more in the sections below.
- Review (internal/upstream): How one reviews a task will tend to mirror how one does it. For example, discovery tasks generally don't require writing test code, so a review would also generally not require testing anything step by step, as it would be the case for a general task.
- Close: When the completion criteria are met, the task can be closed.
Why?
I think it's important to have a leakage-free pipeline and clear-cut responsibility in task specification. When a task reaches Point 3, it means that it should be ready to be worked on; implying that the Reporter/Creator sufficiently specified the Task Description Standard. Imagine it's a Linux process and it's ready to be executed, only then we can allocate the memory (time) and CPU (energy) and a PID (reviewer/assignee).
Edited by Daniel Francis