Using ClickUp

If you haven't already read the guide on our workflow, please read that first.

ClickUp is the tool we use to implement our workflow, and is where we track and manage our work that goes on within the software team. It helps give us an overview of who is working on what and whether we are progressing in terms of achieving our goals. The following is how we are currently planning to use ClickUp throughout the year, but this will almost certainly change as we discover what works and what doesn't. If at any point you feel the workflow or how we do things in ClickUp isn't ideal, please do not hesitate to bring that up. This is meant to help us not hinder us, and everyone has an equal say in how we do things. If anything in this guide could be changed and made better definitely let us know.

Projects

Projects in ClickUp are organized in the "Projects" folder, as indicated in the screenshot. Within this folder are lists (the ClickUp term for a collection of tasks) which represent individual projects. Click on the projects folder icon to see the tasks in every project at once, or click on individual projects to see only the tasks for those projects.

You can choose to view projects in either list view or in board view, whichever you choose is up to you. Please do not change the settings for these views, as they are set up specifically for our workflow and any changes you make will affect everyone else. On that note, please do not change the settings for basically anything in ClickUp, as the entire ClickUp is set up in a way specifically for our use.

Each project should contain a Project Manager and Description field so that other people not directly involved can get a quick overview. Unfortunately, as we don't have the paid version of ClickUp, we can't make use of the feature where people can be assigned to lists, so we instead have to manually type in the name of whoever is responsible for the project.

Project Template:

• Project Manager
• Description

Tasks

Tasks in ClickUp are organized under each project. They always have a current state they are in to signify the progress of the task. All tasks start their lives in the "Backlog" state, from which they can move into the other states. Viewing the tasks in the board view may help visualize things a bit clearer.

This is the lifecycle of a task (proceed in order from top to bottom):

• Backlog: All tasks start in this state. Being in the backlog means the task has not been selected to be accomplished in a sprint, and is on the backburner for the time being.
• Sprint Backlog: When tasks are selected to be accomplished in the current sprint, they are put in the "Sprint Backlog" state. Being in this state means they are intended to be worked on in the current sprint, but they are not being actively worked on (yet).
• In Progress: Tasks in the current sprint backlog should be moved into this state when they are actively being worked on.
• In Review: Tasks should be in this state when another team member should look over the work completed and see if it's fit for being moved to the "Closed" state.
• Closed: Tasks should be moved to this state when they are considered done. The definition of done will be dependent upon the specified deliverable for that task.

Each task should contain a Deliverable field (this is important so it is clear to those working on the task what this task is expected to accomplish).

Task Template:

• Deliverable (definition of when this task is considered complete and can be moved to the "Closed" state)

Subtasks

Subtasks in ClickUp are organized within tasks. Again, because we don't have the paid version of ClickUp, it's not possible to change the different states available for subtasks, and as a result they have the same states as for tasks, as listed above. Because subtasks are such small components of work, the numerous states used for tasks are rather overkill, and the only states that are important when considering subtasks are the "Backlog" and "Closed" states. All subtasks start in the "Backlog" state, and move to the "Closed" state when done (these are such small components of work that specifying a deliverable is overkill; use your best judgement). Once all of the subtasks within a task are in the "Closed state" and the deliverable of the task is met, the entire task itself can be moved to the "Closed" state.

If within your subteam you feel there is indeed a good reason to use the states other than "Backlog" and "Closed", feel free to use them, there is no restriction on doing so. Just remember the most important thing is to change the states of the subtasks to the "Closed" state when done.

Assigning people to tasks and subtasks

Using the person assigning feature on ClickUp is incredibly useful, as this lets people quickly see who is responsible for what. It's also nice as it lets you filter only tasks and subtasks relevant to you, meaning you can quickly see what you yourself need to work on.

Ideally every subtask that is being worked on in a given sprint is assigned to someone. If it's a simple task that doesn't need such granular assignment, feel free to have the entire task assigned to someone. We strongly encourage people to take initiative on tasks/subtasks and assign them to themselves, rather than project managers or others assigning people to tasks. At the end of the day, how the assignments are handled isn't so important as much as just having a clear person who is responsible for the task/subtask.