Skip to main content

Creating a new task

💡 Separating Work into Tasks​

Breaking down larger project goals or features into well-defined tasks is crucial for clarity, progress tracking, and effective workload management.

Here are some general principles to guide you when you're choosing what becomes a task:

  • Actionable units: Each task should represent a distinct piece of work that can be realistically accomplished by one person (or a pair, if pair programming).
  • Clear deliverables: A task should have a clear outcome or deliverable. It should be obvious what "done" looks like for that task. This is tracked via acceptance checklists.
  • Manageable size: Individual tasks should ideally be completable within a few hours to a couple of days. If a task seems like it will take more than 3-4 days, consider breaking it down further into smaller, more focused subtasks or separate tasks. Avoid both tasks that are too vague or large (e.g., "Build e-commerce system") and overly-granular tasks that could be items in a checklist (e.g., "Change button text").
  • Consider dependencies: what needs to be done before something else can start? Define tasks so that they can be worked on with minimal direct blocking dependencies on other in-progress tasks. Use ClickUp's dependency features to link tasks where necessary.
  • Assignability: A task should be clear enough that it can be assigned to a team member who can then take ownership of it.
  • Consider the workflow: Think about how work moves from concept to completion. Tasks should represent logical steps in this process. For example, a feature might move through design tasks, development tasks, QA tasks, and documentation tasks.

✏️ Naming a task​

Clear and consistent task names are essential for quick identification, especially when tasks are multi-homed across different lists or referenced in communications like Slack.

The name should be unambiguous. Team members should be able to grasp the task's essence without needing to open it immediately. Avoid jargon where possible, unless it's universally understood by the team.

Standard Formatting​

The standard format proposed for task names is:
[Project Name] - Specific Action or Goal of the Task

[Project Name]: Enclose the client or internal project name in square brackets. This provides immediate context and is crucial for multi-homing and external referencing.

Examples

[QuickBooks Training Website Redesign], [Tangible Notes Plugin], [Internal Documentation]

Specific Action or Goal: Start with an action verb (e.g., Implement, Design, Fix, Estimate, Investigate, Research, Create, Update, Review). Be concise but descriptive enough so the core objective is clear from the title alone.

Example
  • [QuickBooks Training Website Redesign] - Implement new homepage hero section
  • [Tangible Notes Plugin] - Research WordPress notes plugins

📝 Writing a description​

The task description should be written as if it were explaining the task to a person with no context on the project, because sometimes it will be! This ensures anyone, from a new team member to a stakeholder, can understand the task's purpose and requirements.

  • Be comprehensive: Include all necessary details, such as:
    • Goal: What is the overall objective of this task?
    • Background: Any relevant history or context. Why is this task needed?
    • Requirements: Specific functionalities, behaviors, or constraints.
    • Technical Notes: Suggested approaches, relevant architecture decisions, links to technical documentation (if applicable).
    • User Stories (if applicable): "As a [user role], I want [goal] so that [benefit]."
  • Visuals are Key: When describing particular bits of frontend UI or functionality that needs to be built, the task description must include exported screens, embedded designs (e.g., Figma links/embeds), or clear wireframes inline. Annotate visuals if necessary to point out specific areas of focus.
  • Formatting for Readability: Use headings, bullet points, numbered lists, bold text, and code blocks to make the description easy to scan and digest.
  • Links: Include links to related documents, other tasks, external resources, or specific Figma frames.

✅ Acceptance checklists​

Acceptance checklists are a crucial part of defining "done" and ensuring quality. They act as a final check for the assignee and a clear set of testable criteria for PMs or QA.

  • Format: "[User role] can [achieve goal]" or "Verify that [specific condition/outcome]" statements.
Example
  • "Registered user can successfully log in with correct credentials."
  • "Verify that an error message is displayed for incorrect login attempts."
  • "Free user can enroll in free lessons."
  • Purpose: These help catch missing functionality or bugs ahead of release and serve as living documentation of the required functionality for the assignee.
  • Placement: Use ClickUp's checklist feature within the task.

📎 Adding attachments​

Attach any files directly relevant to completing the task that aren't embedded in the description.

  • Examples: Design assets (SVGs, image files), data files (CSVs, JSON), detailed technical specifications if they are separate documents.
  • Naming: Use clear and descriptive filenames for attachments.

💬 Adding additional context​

Use the comments section for ongoing discussion, clarification, and updates related to the task after it has been created.

  • Purpose: Ask questions, provide updates, share interim findings, document decisions made during task execution.
  • Tagging: @mention relevant team members to notify them.
  • Threads: Use threads to keep conversations organized within a specific comment.
  • Brevity: Keep comments focused on the task at hand. For larger discussions, consider a meeting or a separate documentation space if needed, then summarize outcomes in the task.

Task fields​

Use ClickUp's task fields consistently to provide metadata and structure.

⏳ Estimate​

  • Purpose: Contains the estimate delivered to the client.
  • Updating: If a task significantly deviates from its original estimate during execution, update the estimate or leave a comment explaining the discrepancy.

🏷️ Tags​

  • Purpose: Use tags for categorization, filtering, and reporting.
  • Examples: bug, feature, chore, documentation, marketing, frontend, backend, [specific technology].

👤 Assignee​

  • Responsibility: Clearly assign tasks to one or more individuals responsible for their completion.
  • Clarity: Ensures accountability and makes it clear who to contact with questions.

↕️ Relationships​

  • Purpose: Clearly define how tasks relate to each other.
  • Types: Use "Waiting on" / "Blocking" to manage dependencies. Link "Related tasks" for context.
  • Benefit: Helps visualize workflow, identify critical paths, and prevent work from starting prematurely.

🚩 Priority​

  • Purpose: Indicates the urgency and importance of a task relative to others.
  • Usage: Use consistently based on project goals and deadlines. Ensure the team understands what each priority level (e.g., Urgent, High, Normal, Low) means in practice.

💙 Statuses​

Each task should have an estimate attached before it leaves the 🧡 Requires Estimate status and an assignee attached before it enters the 💙 In progress status.

Learn more about Tangible's default statuses here

✅ Checklists vs. subtasks​

Understanding when to use a checklist within a task versus creating separate subtasks is key for organization.

Checklists​

Use checklists for simple, small to-do items or acceptance criteria that are part of a single, larger piece of work being done by the main task assignee. They don't require separate assignees, estimates, statuses, or detailed tracking.

Example

Step-by-step reminders for a process, "Definition of Done" items, minor elements of the main task (e.g., "confirm responsive on mobile," "double-check spelling").

Subtasks​

Use subtasks for breaking down a complex parent task into more manageable, distinct pieces of work that might benefit from their own assignee, estimate, status, priority, or detailed discussion.

Example

If "Implement User Profile Feature" is a parent task, subtasks could be: "Design Profile Page UI," "Develop Profile API Endpoints," "Frontend Implementation for Profile Page," "Write Unit Tests for Profile API."

Use when a part of the main task is substantial enough to be tracked as a separate work item.