Set up a Scrum or Kanban board with a workflow, issue types, WIP limits and a backlog in a free tool.
Why it matters
Agile teams can run on sticky notes, and many great teams start that way. But once a team is distributed, works with other teams or needs history and reports, it moves to a tool. Jira, made by Atlassian, is the most common in software companies; others include Azure Boards, Linear, Trello, GitHub Projects, Asana and monday.com. Analysts, designers and project managers are often the people who set up and maintain the board, so knowing how to configure one well is a practical, hireable skill.
The concepts every tool shares
Whatever the tool, you will meet the same ideas, though the names vary:
| Concept | Jira name | What it is |
|---|---|---|
| Work item | Issue (work item in newer versions) | A card: story, task, bug, epic |
| Item types | Issue types | Epic, Story, Task, Bug, Sub-task |
| Workflow | Workflow | The statuses an item passes through and the allowed moves |
| Board | Board | Columns mapped to workflow statuses |
| Backlog | Backlog | The ordered list of items not yet in a sprint |
| Sprint | Sprint | A timebox with selected items (Scrum boards) |
| Fields | Fields | Story points, assignee, priority, labels, due date |
| Filters | JQL filters | Saved searches that decide what a board shows |
Scrum board or Kanban board?
Most tools offer both templates:
- A Scrum board has a backlog view, sprints you start and complete, and sprint reports such as burndown and velocity.
- A Kanban board shows continuous flow with WIP limits per column and reports such as the cumulative flow diagram and cycle-time (control) charts.
Pick the one that matches how the team works, not the one with more features.
Designing the workflow
The workflow is the most important decision and the most commonly overcomplicated one. Start from how work really moves, as you did when building a Kanban board by hand:
To Do -> In Progress -> In Review -> Testing -> Done
Guidelines:
- Keep it short. Five to seven statuses is plenty. Every extra status is a place for work to wait.
- Each status should mean a real state, with a clear entry rule: "In Review = pull request opened".
- Show waiting explicitly if it matters ("Waiting for customer"), so it is not mistaken for active work.
- Map statuses to columns and set WIP limits on the active columns.
- Make "Done" match the Definition of Done.
Worked setup: Northside Sports Centre
The team sets up a free Jira Cloud site (the free plan has a user limit; check current terms on Atlassian's site) with a Scrum template:
- Create the project from the Scrum template, key
NSC, so items are numbered NSC-1, NSC-2 and so on. - Issue types: keep Epic, Story, Bug and Task; turn off anything the team will not use.
- Workflow: To Do, In Progress, In Review, Testing, Done.
- Board columns match the statuses; WIP limits of 4 for In Progress and 2 each for In Review and Testing.
- Epics: "Court booking", "Class booking", "Payments".
- Backlog: enter the refined stories with story points and acceptance criteria in the description, link each to its epic and order them.
- Start sprint 1 with the Sprint Goal written in the sprint's goal field.
- Quick filters for "Bugs only" and "Assigned to me".
Writing good items in a tool
- Title: short and specific, written from the user's view: "Member cancels a court booking".
- Description: the user story, acceptance criteria (Given/When/Then), links to designs.
- One item, one outcome: do not bury three changes in one ticket.
- Link related items (blocks / is blocked by) so dependencies show up.
- Comment, do not overwrite, so the history of decisions stays visible.
Reports to look at
- Sprint report / burndown: progress within a sprint.
- Velocity chart: completed points over recent sprints.
- Cumulative flow diagram: bands for each status over time; a widening band shows a bottleneck.
- Control chart (cycle time): how long items take, with outliers.
These are the metrics from the previous lesson, drawn for you, if the workflow and data are clean.
Common mistakes
- Too many statuses and mandatory fields, so people avoid updating the tool.
- The board does not match reality: work happens in chat and the board is updated on Friday.
- Using the tool to monitor individuals rather than the flow of work.
- Copying another team's configuration without asking whether it fits.
- Forgetting to clean up: stale items at the bottom of the backlog nobody will ever do. Archive them.
Quick recap
- All agile tools share items, types, workflows, boards, backlogs, sprints, fields and filters.
- Choose a Scrum or Kanban board to match how the team works.
- Keep the workflow short and real, with WIP limits and a Done that matches the Definition of Done.
- Clean data gives you useful reports; a cluttered tool gets ignored.
Try it
Open the Do tab and set up a board in a free tool.