Skip to content

Clickup

This document explains how we organize work in ClickUp and the rules that keep our workflow clear and predictable.

ClickUp is Terra’s project management tool. It’s where we track every task, define priorities, share context, and coordinate work across teams.

We use ClickUp to:

  • keep all tasks visible and organized
  • know what everyone is working on
  • track expected delivery dates
  • manage development, QA, design, and launches
  • store context, feedback, and internal communication for each task

  • Projects → Each project has an acronym (e.g., SEI, STF, REN, IA).
  • Folders → You’ll usually see the Brand & Website folder, which contains:
    • UX/UI → design tasks
    • Web Development → development tasks for active projects
    • QA + Launch → QA cycles, bug fixing, regression

This structure keeps tasks grouped logically so the whole team knows where to find them.


  • Every task must exist in a ClickUp card, even small fixes — if it’s not in ClickUp, it’s invisible to the team.
  • Naming convention: [ACRONYM] Short, action-oriented title
    Examples:
    • STF - Fix sticky header overlap on iOS
    • SEI - Service Pages - Module Text + Icons
  • Assignee → only one person
  • Due date → when that person should deliver the task
  • Priority → (only when really necessary)
  • Description → context, acceptance criteria, links, screenshots, everything it’s useful for the person asigned to the card

All cards should have one clear status. If a card doesn’t match its status, the whole project becomes harder to manage.

When a card has been created but is not yet ready to start. - Most often created by PMs and Dev leads.

When additional inputs are required to move forward. - Typically tagged here: PMs, UX/UI, Meche, Andrés.

When the card has a clear owner and is ready to begin.

When active work is being done on the card.

(Previously called Dev Testing) This is the stage for developers to check that everything is correct before moving the task forward. Commonly used by devs to thoroughly test before giving final approval. Frontend devs often use this step with BrowserStack.

When feedback has been provided and fixes or improvements are required. - A card in revision usually takes priority before moving forward. If you find an issue during review, you can leave the card in this status for another teammate to address.

When the card is considered complete and ready for manager/lead verification.

When the card is sent to the client and we are waiting for their approval before closing it. Usually the PMs are the ones tagged in this card because they’re the ones waiting for the client’s confirmation.

When the card has been fully finished. Usually closed by PMs, Andrés, or Meche. Also used when it’s an internal card.


  • Give the task a quick initial review

    • Read the description, acceptance criteria, environment, and links. Just a fast scan to understand what’s expected.
  • Ask for more information if something isn’t clear. Before starting, make sure you fully understand:

    • what needs to be done
    • where it needs to be tested (Dev / Stage / Prod)
    • any requirements, edge cases, or constraints Starting a task without clarity usually means extra time, rework, or duplicated effort.
  • Change the status to IN PROGRESS when you’re about to begin

    • You should ideally have only one task in progress at a time, unless there’s a very specific reason not to. This helps your team (and PMs) understand your focus and avoids confusion.
    • Track the card with Harvest
  • When you finish the task, assign it back and update the status. Reassign the task to your PM or the person who assigned it, and move it to the correct status. Make it easy for them to review your work by adding:

    • a final comment with all relevant links (PR, Stage/Prod URL, screenshots, notes)
    • any context they need to validate the result

Next step: Connect ClickUp with Harvest

Knowledge Check

Test your understanding of this section

Loading questions...