Zoho Sprints

Zoho Sprints is an Agile/Scrum project management tool for development teams. It supports backlog, sprints, user stories, Kanban, and progress reporting, and is suitable for small- and medium-sized software teams.

Save favorite

Get discount

Compare

Go to Zoho Sprints

Projects

Quick scan

Create a project → project backlog becomes available for adding work items.
Workspace admins are added to projects by default (per Zoho Sprints help).
Use projects to scope boards, sprints, releases, reports, and timesheets.
Decide Scrum vs Kanban style early to keep workflows consistent.

1) Purpose / Outcome

Projects are the top-level container where your agile work lives. In Zoho Sprints, creating a project unlocks the Project Backlog so you can start adding work items and running sprints/boards within a clear scope.

Use a project to separate teams, products, or streams of work.
Keep naming consistent (e.g., Mobile App, API Platform).
Decide whether to run Scrum sprints or Kanban flow for the project.
Define what “done” means at project level before people start moving items.

2) Who is this for + When to use

This tab is for anyone setting up or maintaining the working space for a team. Use it when you’re starting a new initiative, splitting a monolith into products, or reorganizing teams.

Product owner: sets scope, cadence, and backlog ownership.
Scrum master/PM: ensures workflow consistency and reporting readiness.
Team lead: aligns board statuses and WIP expectations.
Admin: verifies access, defaults, and settings match company rules.

3) Where in navigation + Related tabs

In the Zoho Sprints Knowledge Base, Projects is a top-level module alongside Backlog, Sprints, Board, Release, Timesheet, and Reports. Project setup connects directly to work item creation and sprint/board execution.

Next: Backlog (create work items) → Sprints (plan) → Board (execute).
Planning at scale: Release (group sprints) + Dashboards/Reports (track).
Operations: Users/Workspace Settings for access and defaults.

4) Mental model / Flow

Per the Zoho Sprints quickstart flow: create a project → build product backlog → pull into sprint backlog → start sprint → track on board. Projects are the boundary that keeps that flow coherent.

1
Create project
Outcome: Project appears in listing; backlog becomes available.
2
Fill project backlog
Outcome: Work items ready for planning.
3
Plan via sprints/releases
Outcome: Timeboxed or continuous delivery plan.
4
Execute on board + log time
Outcome: Visible progress, measurable throughput.

5) Objects & Terms

These are the project-level concepts you’ll see repeatedly across the docs.

Project: workspace-scoped container for agile work.
Project Backlog: the “idea pool” where work items start.
Sprint / Board: execution views tied to the project workflow.
Release: planning layer that can group sprints (per release docs).
Workspace admin: admins are added to projects by default (per project creation notes).

6) Lifecycle (State machine)

Projects typically move through a simple lifecycle: active → completed/archived. The exact labels depend on your team’s governance; the docs focus more on sprint/item lifecycle than project lifecycle.

Define when a project is considered “active” (work arriving) vs “maintenance”.
Set a rule for archiving: e.g., no active sprints + backlog triaged + reports exported.
If your org requires it, add a “handoff checklist” before archiving.
If you need an explicit project state machine in-app: Not applicable for this tool/tab (no clear state machine described in the official Projects help pages).

7) Core jobs-to-be-done

Most newbies use Projects for a small set of repeatable jobs. Treat these as your operating checklist.

Start a new initiative: create project, set defaults, invite team, seed backlog.
Split scope: move work into a dedicated project to avoid mixed reporting.
Standardize workflow: align statuses/WIP expectations before execution begins.
Maintain hygiene: periodic review of backlog, sprints, reports, and timesheets.
Close down: finish/close sprints, summarize metrics, archive project.

8) Happy path workflow #1 — Create a project that’s ready for work

Based on the official “Create and manage projects” guidance: creating a project lists it on the project page and makes the Project Backlog available so you can add work items.

Go to the Projects area and click Create.
Enter the required project details (name, basics).
Confirm members: workspace admins are added by default (verify this matches your org policy).
Click Create to finish.
Open the new project and confirm Project Backlog is available.
Add 3–5 starter work items to validate the setup.

Expected outcome: Project appears in the project listing and the Project Backlog is ready for adding work items.

9) Happy path workflow #2 — Prepare a project for consistent reporting

Reports (burndown/velocity/CFD) depend on consistent item status movement and estimation choices. Do this once per project to avoid messy charts later.

Agree on a single workflow style: Scrum sprints vs Kanban flow.
Define status meanings (e.g., what qualifies as “In Progress”).
Decide estimation style (points vs count) so reports align.
Confirm board practices (e.g., WIP limits are configured if you use them).
Run a tiny “sample sprint” with 3–5 items to test reporting views.
Document the rules in a pinned note (team agreement).

Expected outcome: The team moves items consistently, and sprint/flow reports are interpretable.

10) Decision points (A/B)

Use these decisions to avoid redesigning your setup mid-flight.

Situation	If A…	If B…
One product, multiple teams	Create one project + use swimlanes/filters to segment	Create separate projects if reporting must be isolated
Work arrives continuously	Prefer Kanban flow + WIP discipline	Use Scrum sprints if you need timeboxed commitments
Stakeholders want release dates	Use Releases to group sprints and track progress	Skip releases; track via milestones outside Sprints
Time tracking required	Enable Timesheet practices from day 1	Skip timesheets; rely on throughput/estimation for planning

11) Common mistakes (and how to avoid)

These show up frequently when teams start fast without aligning basics.

Mistake: Creating too many projects. Avoid: Start with fewer, split only when reporting or access requires it.
Mistake: No shared status meaning. Avoid: Write 1–2 lines per status and agree as a team.
Mistake: Mixing Scrum and Kanban norms. Avoid: Pick one primary mode per project.
Mistake: Reporting confusion. Avoid: Decide points vs count before the first sprint.
Mistake: Access surprises. Avoid: Verify membership rules (e.g., admins auto-added) early.

12) Practice lab (10–15 min)

Goal: create a project and prove it’s operational end-to-end (backlog → sprint/board readiness).

Create a new project named Practice — Getting Started.
Open Project Backlog and add 5 work items.
Create a sprint (or a simple flow plan) and move 3 items into it.
Open the board view and move 1 item forward by one status.
Optionally, add a small time log for that item (if Timesheet is enabled).
Write down: project scope, status meanings, and your chosen estimation style.

Verify you did it right: You can see the project in the listing, view its backlog, and observe at least one status change on the board without confusion.

Official docs links

Users

Quick scan

Users + roles determine who can create projects/sprints, edit items, and view reports.
Project membership affects day-to-day collaboration (assignment, boards, notifications).
Standardize role expectations before inviting the whole org.
If the docs don’t specify a permission matrix for your plan, document your own rules.

1) Purpose / Outcome

Users define who participates in your workspace and projects. The goal is simple: the right people can create, update, and track work without accidental changes or blocked workflows.

Invite only the roles you need for delivery first.
Separate “decision makers” from “doers” via access rules.
Ensure assignees exist before you start sprint planning.
Confirm notification expectations so updates don’t get missed.

2) Who is this for + When to use

Use this when onboarding a new team, adding external collaborators, or tightening control for production projects. This matters most before the first sprint starts.

Workspace admin: owns invites, access, and governance.
Project lead: validates project membership and assignments.
Team member: updates items, logs time, participates in meetings.
Stakeholder: may need read-only access to boards/reports.

3) Where in navigation + Related tabs

In the Zoho Sprints Knowledge Base, Users is a top-level module next to Projects and Workspace Settings. Treat it as a prerequisite for clean backlog assignment and accurate reports.

Related: Projects (membership), Board (who can move items), Timesheet (who can log/approve), Reports (who can view).
Governance: Workspace Settings / Security & Compliance (policy).

4) Mental model / Flow

Think in layers: workspace users → project membership → item assignment and activity. If someone can’t see or update a thing, check these layers in order.

1
Add user to workspace
Outcome: user exists in the system.
2
Grant role / access scope
Outcome: user has allowed actions.
3
Add to project
Outcome: user can participate in that project.
4
Assign items + notify
Outcome: work flows without blockers.

5) Objects & Terms

Common terms you’ll use when discussing access and onboarding.

Workspace user: someone invited into the workspace.
Project member: a workspace user added to a specific project.
Role / permission: what actions a user can perform.
Assignee: the user responsible for a work item.
Notifications / feeds: how people learn about changes (see Feed and Notification module).

6) Permissions & Roles

The Knowledge Base page list shows Users as a module, but it doesn’t expose a single universal permission matrix in the same place as board/report how-tos. Follow official guidance where available; otherwise define a minimal internal matrix and iterate.

Official permission matrix: Not applicable for this tool/tab (no single consolidated permission table found in the main KB navigation list).
Start with 3 tiers: Admin (setup), Lead (planning), Member (execution).
Write down who can: create/edit sprints, change board statuses, view/export reports, approve time logs.
Test with a “least privilege” pilot before org-wide rollout.

7) Core jobs-to-be-done

Keep user management boring and repeatable. These are the jobs you’ll do most often.

Onboard: add user → add to project → assign starter work.
Offboard: remove access → reassign items → confirm no open approvals.
Adjust scope: move a user between projects without breaking reporting.
Audit: verify who can edit boards/reports before a release crunch.

8) Happy path workflow #1 — Onboard a new team member

Use this when someone joins mid-sprint and needs to start contributing today.

Add the user to the workspace (admin action).
Add the user to the right project(s).
Assign 1 small work item (low risk) to validate access.
Ask them to open the board and move the item one step (if allowed).
Ensure they can comment/attach files in item details (per item detail tabs concept).
Confirm notifications are visible (feeds/notifications).

Expected outcome: The user can see the project, work on assigned items, and receive updates.

9) Happy path workflow #2 — Offboard safely (no orphan work)

Prevent “ghost owners” that break delivery and timesheet/report accuracy.

List open work items assigned to the user and reassign them.
Check if the user has any pending approvals (e.g., timesheets if used).
Export or note key ownership areas (epics/releases if applicable).
Remove the user from the project(s) first.
Remove or deactivate workspace access (admin action).
Run a quick board filter to confirm no items remain assigned.

Expected outcome: No open items, approvals, or responsibilities remain tied to the offboarded user.

10) Decision points (A/B)

These choices impact delivery speed and accidental changes.

Situation	If A…	If B…
Stakeholder wants visibility	Grant read-only access + point them to Reports	Send periodic exports if access is restricted
Contractor joins for 2 weeks	Limit to one project + limited edit permissions	Create a separate project if data separation required
Team uses timesheets	Ensure time logging access is enabled + define approval owner	Skip time logging and focus on throughput metrics
Multiple teams share one project	Use swimlanes/filters + clear ownership rules	Split into multiple projects if conflicts recur

Common mistakes (and how to avoid)

Mistake: Adding everyone as admin. Avoid: use minimum necessary roles.
Mistake: Not adding user to the project. Avoid: verify project membership when assignment fails.
Mistake: Orphan items after offboarding. Avoid: reassign before removal.
Mistake: Notification overload. Avoid: agree what events matter (status change, mention, assignment).
Mistake: Hidden ownership rules. Avoid: write a simple role-to-action matrix.

Practice lab (10 min)

Goal: onboard a test user and validate the minimum “can deliver” permissions.

Add a test user (or use a teammate) to the workspace.
Add them to one project.
Create 1 work item and assign it to them.
Ask them to: open item details, add a comment, move status on board (if permitted).
Verify they can see sprint/release context (if your project uses those).
Document the minimal role settings that made this succeed.

Verify you did it right: The user can complete a full micro-loop (see item → update → status move) without permission errors.

Official docs links

Backlog

Quick scan

Backlog is where work items are captured, refined, and prioritized before execution.
Item details page is organized by tabs (description, comments, attachments, meetings, subitems, etc.).
Good backlog hygiene makes sprint planning and reports easier.
Refinement meetings (esp. Kanban) are used to reprioritize/remove/group work.

1) Purpose / Outcome

The backlog is your single source of truth for “possible work.” The outcome is a prioritized, well-specified set of work items that can be pulled into a sprint backlog or flowed on a board.

Capture new requests as work items immediately (don’t lose context).
Refine items so they’re “sprint-ready” (clear, small, testable).
Keep priority meaningful (top = next to build).
Use item details tabs to store evidence and decisions.

2) Who is this for + When to use

Use this tab daily if you’re a product owner or team lead, and a few times a week if you’re an individual contributor. Backlog work happens before and during sprints (as new info arrives).

Product owner: prioritizes and clarifies.
Team: adds acceptance notes, effort signals, and risks.
QA/Design: adds test notes or mockups as attachments.
PM/Scrum master: runs refinement and keeps items small.

3) Where in navigation + Related tabs

Backlog is a top-level module in the Zoho Sprints Knowledge Base and is directly referenced in the Quickstart flow (project → product backlog → sprint backlog → board).

Upstream: Projects (scope), Users (assignability).
Downstream: Sprints (planning), Board (execution), Reports (tracking).
At scale: Epics/Releases (grouping), Meetings (refinement rituals).

4) Mental model / Flow

Backlog is a funnel: capture → clarify → size → prioritize → pull into execution. If you skip steps, execution becomes noisy and reports become misleading.

1
Capture
Outcome: request becomes a trackable work item.
2
Refine
Outcome: clear description + acceptance hints + attachments.
3
Prioritize
Outcome: top items reflect near-term plan.
4
Pull
Outcome: items move to sprint backlog or active board.

5) Objects & Terms

Backlog terminology shows up across Zoho Sprints modules.

Work item: the unit of work you track.
Product backlog: master list of project work items.
Sprint backlog: curated set chosen for a sprint (per quickstart).
Item details: a tabbed page for description, comments, attachments, subitems, meetings, etc.
Backlog refinement: meeting ritual to reprioritize/remove/group/add items (described in Kanban guide).

6) Lifecycle (State machine)

Backlog items usually evolve from vague to ready to in-progress to done. Zoho Sprints focuses on board status changes for execution; your backlog “readiness” is mostly a team discipline.

Create a simple readiness tag: Draft → Refined → Sprint-ready.
Only pull Sprint-ready into sprint backlog.
Use item details tabs to prove readiness (acceptance notes, attachments, discussions).
If you need an official built-in readiness workflow: Not applicable for this tool/tab (no explicit backlog state machine found in the official KB entries referenced).

7) Core jobs-to-be-done

These jobs keep the backlog usable for planning and delivery.

Write a good item: title + context + expected behavior + links.
Break down scope: split large items into smaller independent ones.
Attach proof: specs, screenshots, meeting notes, decisions.
Reprioritize: reorder based on value and risk.
Prepare sprint input: select a set of ready items for planning.

8) Happy path workflow #1 — Turn a request into a sprint-ready item

Use the item details tabs to store what matters so the team doesn’t “re-discover” requirements mid-sprint.

Create a new work item in the project backlog.
Add context: who needs it, why it matters, and what success looks like.
In item details, add comments clarifying edge cases.
Attach supporting materials (mockups/logs) in the attachments area.
Add subitems if the work must be split for parallel work.
Mark it as ready (your team’s readiness tag/rule) and place it in the top priority band.

Expected outcome: The item can be picked up without a meeting and won’t surprise the team mid-execution.

9) Happy path workflow #2 — Run a backlog refinement loop (30–45 min)

The Kanban guide describes backlog refinement meetings as a way to reprioritize, remove obsolete items, group redundant tasks, and add new work items.

Pick the top 15–25 backlog items as the refinement batch.
Remove or archive obsolete items (document why in comments).
Group duplicates and keep one canonical item.
Split oversized items until each can fit a sprint slice.
Reprioritize based on today’s constraints and dependencies.
End by selecting a “sprint-ready” set for planning.

Expected outcome: Top backlog is clear, small, and realistically actionable.

10) Decision points (A/B)

Use these calls to keep backlog quality high.

Situation	If A…	If B…
Item is too big	Split into smaller items + subitems	Keep as epic-level tracking; don’t pull into sprint
Unclear requirements	Add questions + schedule a short meeting note in item details	Deprioritize until clarified
Competing priorities	Reorder backlog and document decision	Create separate project if priorities are unrelated
Many duplicates	Consolidate and link duplicates to the canonical item	Keep separate only if outcomes differ

Common mistakes (and how to avoid)

Mistake: Writing “todo” items without context. Avoid: add 2–3 sentences explaining purpose and outcome.
Mistake: No attachments/proof. Avoid: attach screenshots/logs early.
Mistake: Pulling unready items into sprint. Avoid: enforce a “sprint-ready” gate.
Mistake: Duplicates everywhere. Avoid: consolidate weekly.
Mistake: Refinement never happens. Avoid: schedule a recurring refinement meeting.

Practice lab (10–15 min)

Goal: build a mini-backlog and make 3 items truly sprint-ready using item details tabs.

Create 6 new backlog items (mix of features/bugs).
Pick 3 and refine them: add description, comments, and one attachment each.
Split one large item into 2–3 smaller items (or add subitems).
Run a 10-minute refinement: reorder top 6 by value.
Select 3 as “sprint-ready” and write why.

Verify you did it right: Someone else can read your top 3 items and explain what to build without asking you questions.

Official docs links

Sprints

Quick scan

You can create a sprint from Backlog; also via a global add option (per create/manage sprints).
Two creation modes: from scratch or from a template (per create/manage sprints).
You can associate a release while creating a sprint (per associate release article).
After sprint starts, items move to the scrum board (per quickstart flow).

1) Purpose / Outcome

Sprints are timeboxed planning units used to curate a set of work items for focused delivery. The outcome is a committed sprint backlog, a running board, and measurable sprint performance via reports.

Create sprints to reduce context switching.
Use sprint backlog to lock the “what” for the timebox.
Track progress on the board during the sprint.
Close the sprint to enable clean reporting (velocity/burndown/CFD).

2) Who is this for + When to use

Use this tab when planning upcoming work, starting a sprint, or improving sprint predictability. It’s most active during planning and at sprint boundaries.

Scrum master/PM: creates sprint, runs planning, ensures dates are correct.
Product owner: sets goal and priority.
Team: commits, executes, and updates statuses.
Stakeholders: consume sprint outcomes via board and reports.

3) Where in navigation + Related tabs

Sprints is a top-level module in the Zoho Sprints KB and is directly tied to Backlog (source of items), Board (execution), Release (grouping), and Reports (measurement).

Create from: Backlog (per create sprint steps begin at “Go to Backlog”).
Execute on: Board after sprint starts (per quickstart).
Measure in: Dashboards and Reports (burndown/velocity/CFD, etc.).

4) Mental model / Flow

A sprint has three phases: build the sprint backlog → run execution on board → close and learn. Keep these phases distinct to protect predictability.

1
Create sprint
Outcome: sprint container exists.
2
Curate sprint backlog
Outcome: selected items ready for work.
3
Start sprint
Outcome: items appear on board for tracking.
4
Close sprint
Outcome: reports reflect committed vs completed work.

5) Objects & Terms

These sprint concepts are referenced across official help pages.

Sprint backlog: curated set of work items for the sprint (quickstart).
Template: reuse an existing sprint structure (create/manage sprints mentions templates).
Release association: choose a release while creating a sprint (associate release article).
Estimation points: used for burndown/velocity views (reports docs).

6) Lifecycle (State machine)

Sprints commonly move through a simple lifecycle: planned → active → completed/closed. Your board and reports become meaningful when the team respects these boundaries.

Planned: sprint exists, backlog is curated, but execution hasn’t started.
Active: sprint started; work items are tracked on the board.
Completed: sprint closed; reports summarize outcomes.
Exact UI labels may vary: follow what your workspace shows; the docs emphasize the behavior (start moves items to board; close enables reporting).

7) Core jobs-to-be-done

These are the repeatable sprint jobs that keep delivery consistent.

Create sprint: from scratch or via template.
Select items: pull from product backlog to sprint backlog (quickstart).
Associate release: link sprint to release when planning (optional).
Run sprint: update statuses on the board daily.
Review metrics: use burndown/velocity/CFD after (reports module).

8) Happy path workflow #1 — Create a sprint (from scratch)

This mirrors the official “Create and manage sprints” flow: open project → go to Backlog → create sprint.

Open the required project.
Go to Backlog.
Click Create to open the sprint creation form.
Enter sprint details (name, dates, goal fields as available).
Optionally choose from scratch or template (if your UI offers it).
Click Create to save.

Expected outcome: A new sprint exists and is ready for you to curate sprint backlog items.

9) Happy path workflow #2 — Create a sprint and associate it with a release

The official “Associate release while creating new sprint” steps show you can select a release in the sprint creation form.

Open the required project.
Go to Backlog and click Create.
Enter sprint details.
Select the required Release to associate with the sprint.
Click Create.
Verify the sprint now appears under that release’s tracking views.

Expected outcome: Sprint is created and linked to a release for cross-sprint tracking.

10) Decision points (A/B)

These are the sprint choices that influence predictability and reporting.

Situation	If A…	If B…
Recurring sprint structure	Use a sprint template to reuse structure	Create from scratch if scope varies wildly
Stakeholders track releases	Associate sprint with a release	Skip release association for internal-only work
Team changes mid-sprint	Adjust commitment carefully + document in comments	Keep scope stable; move changes to backlog
Reporting uses points	Ensure estimation points are used consistently	Use count-based reporting if points aren’t adopted

Common mistakes (and how to avoid)

Mistake: Starting sprint without curated backlog. Avoid: finalize selection before start date.
Mistake: Scope churn daily. Avoid: push changes back to product backlog.
Mistake: Status misuse. Avoid: agree what each status means on the board.
Mistake: Inconsistent estimation. Avoid: choose points or count and stick to it.
Mistake: Not closing sprints. Avoid: close on time to keep reports accurate.

Practice lab (10–15 min)

Goal: create a sprint, associate it to a release (optional), and prove it will show meaningful reports later.

Create a sprint in a practice project from Backlog.
Add 5 work items into sprint backlog.
(Optional) Associate the sprint with a release during creation.
Start the sprint and move 2 items across one status on the board.
Close 1 item fully to create real “done” data.
Open a sprint report view (e.g., burndown/CFD) after some movement exists.

Verify you did it right: The sprint exists, items are trackable on the board, and reports can reflect at least one change in status or completion.

Official docs links

Board

Quick scan

Board is where active sprint work items are viewed, updated, and tracked (per quickstart).
WIP limits can be set for statuses; defined in Project Settings (per manage items on board).
Swimlanes reorganize/group items; Kanban guide describes swimlane types and usage.
Board discipline directly affects reports like CFD (status-based tracking).

1) Purpose / Outcome

The board is your real-time execution view. The outcome is simple: everyone sees what’s in progress, what’s blocked, and what’s done—without needing a meeting.

Use statuses to represent real workflow steps (not vague feelings).
Move cards daily to reflect reality.
Use WIP limits to prevent overload in a status lane.
Use swimlanes to group work by user/criteria when needed.

2) Who is this for + When to use

Use the board multiple times per day during an active sprint or continuous flow. It’s the central place for standups, status checks, and quick rebalancing.

Team members: move items, update details, add comments/attachments.
Lead: watches WIP and unblocks items.
Scrum master: facilitates daily review and flow improvements.
Stakeholders: view progress without interrupting the team.

3) Where in navigation + Related tabs

Board is a top-level module in the KB and is the execution step after starting a sprint (quickstart). It’s also the source of truth for status-based reports like CFD.

Feeds from: Sprints (active sprint backlog) and Backlog (items pulled in).
Drives: Reports (CFD uses item statuses).
Governed by: Project Settings (WIP limits are defined there).

4) Mental model / Flow

A board is a workflow visualization: columns = statuses; cards = work items; movement = progress. If movement is inaccurate, your team’s “truth” becomes unreliable.

1
Start sprint / activate flow
Outcome: items appear on the board.
2
Pull work
Outcome: assignees start items deliberately.
3
Move statuses
Outcome: board reflects real progress.
4
Enforce WIP
Outcome: bottlenecks become visible.

5) Objects & Terms

Board terminology to align on before your first sprint.

Status/Column: workflow step (To Do / In Progress / Done, etc.).
WIP limit: min/max limit per status (manage items on board).
Swimlane: grouped view of items; Kanban docs describe swimlane options.
CFD: cumulative flow diagram tracks status progress over time.

6) Lifecycle (State machine)

On the board, work items transition across statuses. Reports like CFD assume statuses are meaningful and used consistently.

Define allowed transitions (e.g., don’t jump from To Do to Done without evidence).
Use comments/attachments in item details when a transition needs justification.
If you use WIP limits, treat them as a flow control tool—not a “score”.
Official status transition rules per project: Not applicable for this tool/tab (no universal status transition matrix in the referenced board help pages).

7) Core jobs-to-be-done

These are the board actions that matter most for delivery and visibility.

Update status: move cards as work changes.
Limit overload: set WIP limits and respond to breaches.
Group view: use swimlanes to focus (by user, etc.).
Spot blockers: identify stuck cards and escalate early.
Keep history: log decisions in item details so context doesn’t vanish.

8) Happy path workflow #1 — Configure and use WIP limits

The board help notes you can set WIP limits per status and that this is defined in Project Settings.

Open the project and go to Project Settings.
Find the board/status configuration area (where WIP is defined).
For the In Progress status, set a reasonable min/max.
Save settings and return to the board.
During daily check, if lane exceeds max, stop pulling new work.
Swarm to move items forward until WIP returns to healthy range.

Expected outcome: The team avoids overloading a status lane and bottlenecks become visible early.

9) Happy path workflow #2 — Use swimlanes to focus a daily review

Kanban guidance describes swimlanes as a filtered/reorganized board structure. Community tips also show choosing swimlanes from the board UI.

Open the board for the active sprint/flow.
Enable Swimlane from the board controls (typically top/right).
Select a swimlane type relevant to the day (e.g., by user).
Scan for stuck items per lane (no movement, no comments).
Pick 1–2 blockers and assign next actions in comments.
Turn off swimlanes to return to the default view when done.

Expected outcome: Daily review is faster and more actionable because the board is grouped logically.

10) Decision points (A/B)

These choices keep your board signal clean.

Situation	If A…	If B…
Lane exceeds WIP max	Stop pulling; swarm to unblock	Increase WIP only if capacity truly increased
Items are hard to scan	Use swimlanes + filters for grouping	Split into separate projects/boards if fundamentally different
Status meanings drift	Re-define statuses and communicate the rules	Add a “Blocked” convention if that’s the real issue
Reports look wrong	Audit status movement discipline	Switch report to count-based if points are inconsistent

Common mistakes (and how to avoid)

Mistake: Moving cards late. Avoid: move when work changes, not at end of day.
Mistake: WIP limits ignored. Avoid: treat breaches as a team event.
Mistake: Too many statuses. Avoid: keep workflow simple and meaningful.
Mistake: No notes on blockers. Avoid: comment the next action and owner.
Mistake: Swimlanes used randomly. Avoid: standardize when to use them (daily review, triage).

Practice lab (10–15 min)

Goal: make the board visibly useful for a small team, with one WIP rule and one swimlane habit.

Pick an active sprint (or create a tiny one) with 5 items.
Set a WIP max for In Progress to 2.
Move 3 items into In Progress and observe the limit breach.
Pull one item forward (toward Done) to get under the limit.
Enable swimlane by user and conduct a 5-minute review.
Write a one-line team agreement: when WIP breaches, what do you do?

Verify you did it right: The board makes overload obvious and your team can correct it using WIP + focused review.

Official docs links

Release

Quick scan

Releases help plan and manage releases (KB module description).
You can associate a sprint with a release during sprint creation.
Release board provides a column view of sprints with their work items aligned below (release board article).
Use releases when stakeholders care about shipping versions across multiple sprints.

1) Purpose / Outcome

Releases group multiple sprints and help you track progress toward a version or milestone. The outcome is release-level visibility that complements sprint-level execution.

Use releases to communicate “what ships together.”
Track progress across several sprints in one view.
Reduce stakeholder confusion when work spans multiple sprints.
Align reporting and board scanning around release scope.

2) Who is this for + When to use

Use releases when you have a roadmap milestone, version update, or bundle of features with an external deadline. This is especially helpful in multi-sprint delivery.

Product/PM: defines release scope and dates.
Team leads: map sprints to release outcomes.
Stakeholders: review release progress without digging into each sprint.
QA/Release manager: coordinates readiness and cutover checks.

3) Where in navigation + Related tabs

Release is a top-level KB module. It integrates most tightly with Sprints (association at creation) and Board (execution). Reports and timesheets provide supporting signals.

Linked from: Sprints (associate release while creating a sprint).
Viewed in: Release Board (progress across sprints).
Measured by: Reports (sprint performance still matters inside release).

4) Mental model / Flow

A release is a portfolio slice: define scope → attach sprints → track progress → finalize. Don’t treat releases as a duplicate of a sprint; it’s a wrapper for multiple sprints.

1
Define release
Outcome: a release container exists.
2
Associate sprints
Outcome: sprints mapped to release.
3
Track via release board
Outcome: progress visible across sprints.
4
Close out
Outcome: release summary and learnings captured.

5) Objects & Terms

Key release concepts mentioned in official release pages.

Release: planned bundle of work across time.
Release board: column view of all sprints with work items aligned below (release board article).
Sprint association: selecting a release in sprint creation form (associate release article).
Filters: release board supports filtering to view items (release board article mentions filters).

6) Lifecycle (State machine)

Releases generally progress from planned → in progress → shipped/closed. The official docs emphasize tracking progress through the release board rather than prescribing a strict state machine.

Define “planned” when scope exists but execution is not started.
Define “in progress” when at least one associated sprint is active.
Define “shipped” when release criteria and checks are done.
If you need built-in release states in Zoho Sprints: Not applicable for this tool/tab (no explicit release state machine found in the referenced release help pages).

7) Core jobs-to-be-done

Keep releases simple: define, attach, track, communicate.

Create release: define version/milestone and scope.
Associate sprints: link new sprints at creation time.
Track progress: use release board to see items across sprints.
Communicate status: summarize what’s at risk and what’s shipped.
Retrospect: capture learnings across the whole release, not only per sprint.

8) Happy path workflow #1 — Associate sprints to a release while planning

Official steps show selecting a release when creating a sprint from Backlog.

Open the project and go to Backlog.
Click Create to open sprint creation.
Enter sprint details.
Select the target Release in the form.
Click Create.
Confirm the sprint appears under the release’s tracking context.

Expected outcome: Your plan ties sprint execution to a release milestone automatically.

9) Happy path workflow #2 — Use the release board to spot risk

The release board is designed to track progress of work items across all sprints in a release and supports filters.

Open the release and navigate to the Release Board.
Scan columns to see each sprint’s work items aligned below.
Apply filters to focus on high-priority or at-risk items.
Identify sprints with heavy “in-progress” load or many blockers.
Click into item details to confirm next actions are documented.
Publish a short release status note: what’s on track vs at risk.

Expected outcome: You can explain release health in 2 minutes using a single view.

10) Decision points (A/B)

These choices keep release planning useful (not bureaucracy).

Situation	If A…	If B…
Work spans 3+ sprints	Create a release and associate sprints	Skip release if it’s truly internal and short-lived
Stakeholders need a single view	Use release board as the default status artifact	Use sprint boards only if scope is tiny
Scope keeps changing	Freeze a minimal release scope + push extras to next release	Delay release creation until priorities stabilize
Multiple products share one release date	Create separate releases per product	Create one release only if reporting requirements allow mixing

Common mistakes (and how to avoid)

Mistake: Treating release as sprint #0. Avoid: use it only for multi-sprint visibility.
Mistake: Not associating sprints. Avoid: link at sprint creation time.
Mistake: No scope definition. Avoid: list what’s in/out explicitly.
Mistake: Ignoring release board filters. Avoid: filter for risk and priority weekly.
Mistake: No closeout. Avoid: capture what shipped + what slipped.

Practice lab (10–15 min)

Goal: create a small release, associate two sprints, and validate the release board tells a coherent story.

Create a release named Practice v0.1.
Create Sprint A and associate it to the release during creation.
Create Sprint B and associate it as well.
Add 3 items to Sprint A and 3 items to Sprint B.
Open the release board and verify you can see both sprints and their items aligned.
Apply a filter (priority/assignee if available) to demonstrate focused risk scanning.

Verify you did it right: One view shows progress across multiple sprints and you can identify risk quickly.

Official docs links

Timesheet

Quick scan

Timesheet module helps track billable/non-billable hours and approve time logs (Zoho Sprints site page).
Timesheet reports summarize logged hours and provide insights (About timesheet + timesheet report pages).
Decide early: are you tracking time for billing, forecasting, or just learning?
Time data is only useful if logging is consistent and review happens.

1) Purpose / Outcome

Timesheet lets your team record hours spent on work and separate billable vs non-billable time. The outcome is better visibility into effort, approvals (if used), and reports for future planning.

Track time per work item to understand cost/effort.
Use billable vs non-billable for client work separation.
Review logs weekly to keep data clean.
Use reports to spot overrun patterns and planning mistakes.

2) Who is this for + When to use

Use this when your org requires time tracking or when you want accurate effort data to improve planning. It’s most useful with a routine (daily logging + weekly review).

Team members: log time regularly.
Lead/Manager: reviews and approves logs (if your plan uses approvals).
Finance/Operations: uses billable reporting.
PM: compares time patterns to estimation and delivery speed.

3) Where in navigation + Related tabs

Timesheet is a top-level KB module and connects naturally to Board (work execution), Reports (timesheet reports), and Users (who can log/approve).

Related: Dashboards and Reports → Timesheet Reports.
Inputs: work items and activities during sprints/board flow.
Governance: roles/permissions (if approvals are enforced).

4) Mental model / Flow

Timesheet data is only valuable if it follows a loop: log → review → approve (optional) → report → improve. Don’t log time just to “store numbers.”

1
Log time
Outcome: hours captured per item/category.
2
Review
Outcome: obvious mistakes corrected early.
3
Approve (if used)
Outcome: trusted dataset for billing/reporting.
4
Report
Outcome: insights that change planning or behavior.

5) Objects & Terms

Timesheet concepts referenced in official Zoho Sprints materials.

Billable / non-billable: categorized hours (Zoho Sprints Timesheet page).
Time log approvals: single-click approvals are highlighted (Zoho Sprints Timesheet page).
Timesheet reports: multiple reports to track hours logged (timesheet report KB article).
Timesheet module: tracks duration to improve team efficiency (Zoho Sprints Timesheet page).

6) Permissions & Roles

Some orgs need approvals; others only need personal logging. If your plan/workspace supports approvals, define who approves and on what cadence.

Detailed permission matrix for timesheet approvals: Not applicable for this tool/tab (no consolidated permission table found in the referenced timesheet KB pages).
Define an owner for timesheet review (team lead/manager).
Decide minimum logging frequency (daily recommended if required).
Write a rule for late entries (e.g., within 48 hours).

7) Core jobs-to-be-done

Timesheet is about consistency. Keep the jobs small and repeatable.

Log time: record hours against work items or categories.
Split billable/non-billable: keep finance reporting clean.
Review weekly: fix duplicates, missing days, and wrong categories.
Approve (if used): sign off so reports are trustworthy.
Use reports: compare logged time to sprint outcomes and expectations.

8) Happy path workflow #1 — Daily time logging routine

A lightweight routine prevents end-of-week memory gaps.

At end of day, list the 2–4 work items you touched.
Log time for each item in the Timesheet module.
Mark entries as billable/non-billable correctly.
Add a short note if the work was unusual (rework, incident).
Check total hours look plausible before saving.
Repeat daily for consistent data quality.

Expected outcome: Timesheet reflects real effort with minimal correction later.

9) Happy path workflow #2 — Weekly timesheet review + insights

The KB notes timesheet reports provide insights for future planning. Weekly review turns logs into learning.

Open timesheet reports for the week.
Scan for missing days or unusually high totals.
Verify billable/non-billable splits for accuracy.
Identify top time-consuming work items/categories.
Write 1–2 action notes (e.g., reduce rework, improve estimation, adjust WIP).
If approvals exist, approve/lock the week after review.

Expected outcome: You can explain where time went and adjust planning or process.

10) Decision points (A/B)

Pick a model that matches why you track time.

Situation	If A…	If B…
Client billing required	Enforce billable categorization + approvals	Skip approvals only if finance accepts trust-based logs
Internal product team	Track time for learning (not policing)	Skip timesheets; focus on throughput metrics
People forget to log	Daily 5-minute ritual + reminders	Weekly batch logging (lower accuracy)
Too much admin overhead	Log only on key items/categories	Full item-level logs if you need exact costing

Common mistakes (and how to avoid)

Mistake: Logging everything on Friday. Avoid: daily logging.
Mistake: No categories. Avoid: at least billable vs non-billable.
Mistake: No review. Avoid: weekly 10-minute audit.
Mistake: Using timesheets to punish. Avoid: use data for planning and improvement.
Mistake: Ignoring reports. Avoid: connect time insights to backlog/sprint decisions.

Practice lab (10–15 min)

Goal: create a small dataset and read one insight from a timesheet report.

Pick 3 work items you worked on recently (or create 3 sample items).
Log 15–30 minutes for each (mix billable/non-billable).
Open the timesheet report view.
Confirm the totals match what you entered.
Write one insight: which category consumed the most time and why?
Decide one adjustment (e.g., reduce WIP, refine backlog items earlier).

Verify you did it right: A report displays the hours you logged and you can state one actionable learning.

Official docs links

Dashboards and Reports

Quick scan

Reports analyze sprint performance quantitatively and help predictions/corrective measures (About report).
Sprint reports include velocity, burndown, burnup, CFD, latency (About report).
Burndown viewing steps: Report module → View by Sprint Report → Report type Burndown (Burndown chart article).
CFD tracks progress of work items by status on the sprint board (CFD article).

1) Purpose / Outcome

Dashboards and Reports turn board activity into insight. The outcome is better forecasting, earlier detection of bottlenecks, and measurable improvement in estimation and flow.

Use reports to learn, not to blame.
Compare committed vs completed work (velocity).
Track remaining work trend over time (burndown).
Analyze status flow health (CFD).

2) Who is this for + When to use

Use reports during sprint planning, mid-sprint check-ins, and retrospectives. Leaders use them for trend visibility; teams use them for process tuning.

Team: mid-sprint flow checks and retro learning.
Scrum master/PM: planning and predictability improvements.
Leads: capacity and bottleneck tracking.
Stakeholders: high-level progress and risk signals.

3) Where in navigation + Related tabs

Reports are a top-level KB module and rely on data generated in Sprints, Board, and Timesheet. If execution data is inconsistent, reports will mislead.

Inputs: sprint status movement (board), closed sprints, estimation points.
Related: Timesheet Reports for time-tracking insights.
Best pairing: use reports alongside sprint retrospectives.

4) Mental model / Flow

Reports are a feedback loop: execute consistently → collect data → visualize → decide → change behavior. The loop breaks if statuses/estimations aren’t disciplined.

1
Execute
Outcome: statuses and completions reflect reality.
2
Measure
Outcome: report lines show real trends.
3
Interpret
Outcome: identify bottlenecks or estimation drift.
4
Improve
Outcome: process changes reduce waste next sprint.

5) Objects & Terms

Official sprint report types called out in the KB.

Velocity report: compares committed vs completed estimation points (velocity chart article).
Burndown chart: trend of remaining work; supports view by points or count (burndown chart article).
CFD: shows progress by status; status-driven (CFD article).
Latency: mentioned as a sprint report type (About report).

6) Lifecycle (State machine)

Reports usually depend on sprint lifecycle states (planned/active/completed) and work item status transitions. Treat “closing sprints” as a critical step so reports summarize the correct window.

Only compare velocity across closed/completed sprints.
Interpret CFD only if statuses are used consistently on the board.
When changing workflow statuses, note the date—trend comparisons may shift.
If you need a single official report lifecycle spec: Not applicable for this tool/tab (reports docs describe report types and viewing, not a unified lifecycle spec).

7) Core jobs-to-be-done

These are the report jobs that improve delivery, fast.

View burndown: check if the trend matches expected progress.
Review velocity: compare committed vs completed over closed sprints.
Use CFD: spot bottlenecks where work piles up in a status.
Share insights: summarize in sprint retro notes.
Adjust planning: change scope, WIP, or refinement based on findings.

8) Happy path workflow #1 — View a sprint burndown chart

Official steps: go to Report module, View by Sprint Report, select Burndown, then choose point/count view.

Go to the Report module.
Select View by as Sprint Report.
Select Report type as Burndown.
Confirm axes interpretation (X = date, Y = estimation points) as described.
Switch between point vs count view if needed.
Capture one observation: are you above/below the ideal line?

Expected outcome: You can see ideal vs actual trend and detect early risk in the sprint.

9) Happy path workflow #2 — Use CFD to find a bottleneck

The CFD tracks progress by item status on the sprint board. You’ll use it to see where work accumulates.

Open the Cumulative Flow Diagram (CFD) report for a sprint.
Identify status bands that are growing over time.
Map the growing band to a real workflow step (e.g., review/testing).
Check the board for WIP breaches or blocked items in that status.
Decide an action: reduce intake, add capacity, or simplify the step.
Re-check CFD after 2–3 days for improvement.

Expected outcome: You can name the bottleneck status and take a concrete action to reduce it.

10) Decision points (A/B)

Reports can confuse teams if used without context. Make these calls explicitly.

Situation	If A…	If B…
Team uses estimation points	Use velocity + point-based burndown	Use count-based views until points stabilize
Board statuses changed recently	Annotate the change date; interpret trends carefully	Delay comparing across old/new periods
Stakeholders want progress	Share a simple burndown snapshot + explanation	Share release board for multi-sprint scope
Data seems wrong	Audit status movement and sprint closure habits	Pause reporting until discipline improves

Common mistakes (and how to avoid)

Mistake: Treating reports as performance reviews. Avoid: use them for process improvement.
Mistake: Changing statuses mid-sprint casually. Avoid: change at sprint boundaries when possible.
Mistake: Not closing sprints. Avoid: close consistently to get comparable velocity.
Mistake: Overfitting to a single chart. Avoid: use burndown + CFD together.
Mistake: Ignoring underlying behavior. Avoid: fix board discipline before “fixing charts”.

Practice lab (10–15 min)

Goal: generate just enough activity to make burndown and CFD meaningful.

Pick a sprint with at least 5 items (or create a practice sprint).
Ensure items have estimation points (or choose count-based view).
Move 2 items forward by one status each day for 2 days (or simulate with a quick movement).
Close at least 1 item to create “done” signal.
View burndown and record one risk observation.
View CFD and identify one status that looks like a bottleneck.

Verify you did it right: Both charts show non-flat change and you can explain what happened on the board that caused it.

Official docs links

Workspace Settings

Quick scan

Workspace Settings is a top-level KB module used to configure workspace-level behavior.
Board WIP limits are defined in Project Settings (board help), which is usually governed by workspace/project admin policies.
Set defaults early: roles, landing pages, and consistency rules to reduce friction.
If a setting isn’t documented clearly for your plan, treat it as “Not applicable” and don’t invent behavior.

1) Purpose / Outcome

Workspace Settings is where you define the guardrails and defaults that apply across projects. The outcome is consistency: fewer surprises, fewer permission issues, and cleaner reporting.

Set workspace-wide conventions (naming, roles, defaults).
Choose what users see first (landing preferences if available).
Ensure settings support your chosen delivery mode (Scrum/Kanban).
Reduce per-project “reinvention” by documenting defaults.

2) Who is this for + When to use

This is mainly for admins and team leads. Use it during initial setup, when adding many projects, or after recurring process issues (like WIP overload or inconsistent reporting).

Workspace admin: owns global settings and governance.
Project lead: aligns project-level settings to workspace rules.
Security/compliance: checks policy alignment (see Security & Compliance module).
Ops: validates integrations and admin workflows (if used).

3) Where in navigation + Related tabs

Workspace Settings appears as a top-level KB module alongside Customization, Layout and Rules, Data Administration, and Security & Compliance.

Related: Projects (defaults applied), Users (roles), Board (WIP via project settings), Reports (data consistency).
Adjacent governance: Customization / Layout and Rules for fields and forms.

4) Mental model / Flow

Workspace settings should be treated like product configuration: define intent → set defaults → test with a pilot project → roll out.

1
Define intent
Outcome: clarity on what you’re optimizing for.
2
Set defaults
Outcome: consistent starting state for projects/users.
3
Pilot
Outcome: validate settings in one project.
4
Roll out
Outcome: apply across teams with minimal disruption.

5) Objects & Terms

Workspace-level concepts that often connect into other modules.

Landing preferences: global view can be set as landing page via profile customization (global view article note, related to settings).
Project settings: where WIP limits are defined (board article).
Defaults: templates, conventions, and cross-project rules you standardize.
Governance: roles and access expectations.

6) State machine / Lifecycle

Settings changes have a lifecycle: proposed → tested → applied → audited. This is an internal governance lifecycle rather than an in-app state machine.

Propose changes with a clear reason (e.g., WIP overload, inconsistent reports).
Test in a pilot project for 1 sprint cycle.
Roll out with a short changelog and what behavior will differ.
Audit after 2 weeks to confirm improvement.

7) Core jobs-to-be-done

Keep workspace setting work focused on stability and clarity.

Set governance defaults: who can create projects/sprints, who approves time.
Standardize board rules: WIP strategy and status definitions guidance.
Reduce friction: pick defaults that fit most teams.
Support reporting: ensure consistent estimation/status usage expectations.
Document: write “how we use Zoho Sprints here” in one page.

8) Happy path workflow #1 — Set a workspace baseline (pilot-first)

This is a safe approach when docs are distributed across modules and you want to avoid breaking teams.

List your baseline decisions: Scrum vs Kanban, estimation style, WIP philosophy.
Choose one pilot project and apply the baseline settings there.
Configure project settings needed for board discipline (e.g., WIP limits).
Run one sprint (or one week of flow) with the pilot team.
Check reports (burndown/CFD) for interpretability.
Publish the baseline as a short internal standard.

Expected outcome: You have a tested baseline that new projects can follow without chaos.

9) Happy path workflow #2 — Make Global View the default landing page (if desired)

The Global View article notes you can set Global View as your landing page via Profile Customization under Settings. Use this to give users a consolidated starting view.

Open Global View and confirm it shows useful default views.
Go to Settings → Profile Customization (as referenced in the Global View note).
Set Global View as landing page.
Ask 1–2 users to validate the new landing experience.
Document when to use Global View vs project pages.
Roll out the recommendation to the workspace.

Expected outcome: Users start with a consolidated view and navigate to work faster.

10) Decision points (A/B)

Make these workspace choices explicit to reduce confusion.

Situation	If A…	If B…
Many new users joining	Standardize landing page + simple baseline rules	Let teams self-configure (risk: inconsistency)
Teams report WIP overload	Adopt WIP limit guidance + enforce in pilot projects	Skip WIP and focus on refinement discipline
Reports are hard to compare	Standardize estimation (points vs count)	Allow mixed methods (expect weaker cross-team comparisons)
Need governance	Define a role matrix and ownership	Keep informal (risk: permissions surprises)

Common mistakes (and how to avoid)

Mistake: Changing rules weekly. Avoid: pilot → rollout cadence.
Mistake: No documented baseline. Avoid: write a 1-page standard.
Mistake: Over-configuring early. Avoid: start minimal and iterate.
Mistake: Ignoring user experience. Avoid: validate landing/navigation with real users.
Mistake: Treating settings as “set and forget.” Avoid: audit quarterly.

Practice lab (10–15 min)

Goal: define one workspace baseline and validate it in one pilot project without breaking workflows.

Write 3 baseline rules: estimation style, status meaning, WIP approach.
Pick a pilot project and configure project settings accordingly (e.g., WIP limit).
Run a mini sprint with 5 items and move statuses consistently.
Open a report (burndown/CFD) and check if it matches reality.
Adjust baseline rules once (max) based on pilot learning.
Publish the baseline to your team.

Verify you did it right: A new team member can join the pilot project and follow the baseline without asking “how do we use this?”

Your favorites

Projects

1) Purpose / Outcome

2) Who is this for + When to use

3) Where in navigation + Related tabs

4) Mental model / Flow

5) Objects & Terms

6) Lifecycle (State machine)

7) Core jobs-to-be-done

8) Happy path workflow #1 — Create a project that’s ready for work

9) Happy path workflow #2 — Prepare a project for consistent reporting

10) Decision points (A/B)

11) Common mistakes (and how to avoid)

12) Practice lab (10–15 min)

Official docs links

Users

1) Purpose / Outcome

2) Who is this for + When to use

3) Where in navigation + Related tabs

4) Mental model / Flow

5) Objects & Terms

6) Permissions & Roles

7) Core jobs-to-be-done

8) Happy path workflow #1 — Onboard a new team member

9) Happy path workflow #2 — Offboard safely (no orphan work)

10) Decision points (A/B)

Common mistakes (and how to avoid)

Practice lab (10 min)

Official docs links

Backlog

1) Purpose / Outcome

2) Who is this for + When to use

3) Where in navigation + Related tabs

4) Mental model / Flow

5) Objects & Terms

6) Lifecycle (State machine)

7) Core jobs-to-be-done

8) Happy path workflow #1 — Turn a request into a sprint-ready item

9) Happy path workflow #2 — Run a backlog refinement loop (30–45 min)

10) Decision points (A/B)

Common mistakes (and how to avoid)

Practice lab (10–15 min)

Official docs links

Sprints

1) Purpose / Outcome

2) Who is this for + When to use

3) Where in navigation + Related tabs

4) Mental model / Flow

5) Objects & Terms

6) Lifecycle (State machine)

7) Core jobs-to-be-done

8) Happy path workflow #1 — Create a sprint (from scratch)

9) Happy path workflow #2 — Create a sprint and associate it with a release

10) Decision points (A/B)

Common mistakes (and how to avoid)

Practice lab (10–15 min)

Official docs links

Board

1) Purpose / Outcome

2) Who is this for + When to use

3) Where in navigation + Related tabs

4) Mental model / Flow

5) Objects & Terms

6) Lifecycle (State machine)

7) Core jobs-to-be-done

8) Happy path workflow #1 — Configure and use WIP limits

9) Happy path workflow #2 — Use swimlanes to focus a daily review

10) Decision points (A/B)

Common mistakes (and how to avoid)

Practice lab (10–15 min)

Official docs links

Release

1) Purpose / Outcome

2) Who is this for + When to use

3) Where in navigation + Related tabs

4) Mental model / Flow

5) Objects & Terms

6) Lifecycle (State machine)

7) Core jobs-to-be-done

8) Happy path workflow #1 — Associate sprints to a release while planning