How_to_use_this_Agile_template

📖 How to use this template

A working Scrum setup, not just a list of columns.

Duplicate this project into your own organization (dropdown next to the project name, then Duplicate)
Read section 1 to see how the pieces fit together
Work through the Day one checklist in section 10

Come back for the rest when something starts hurting.

1. How this template is organized

Five things sit at the root of this project, plus a release milestone. Each has one job.

Section	What lives here	Who touches it
🔄 Ceremonies	Five recurring meetings with agendas	Scrum Master
📋 Product Backlog	Refined work, grouped into epics, ordered by value	Product Owner
🐞 Defects	Bugs awaiting triage or a sprint slot	Whoever triages
📥 Intake	Raw feedback and ideas. Nothing committed to.	Anyone
🚀 Release	Milestone markers on the timeline	Product Owner

How work moves

📥 Intake  →  Backlog Refinement  →  📋 Product Backlog  →  Sprint  →  Done

An idea starts as raw input. Refinement turns it into a story with acceptance criteria and a size. Planning pulls it into a sprint. The sprint finishes it or sends it back.

The separation between Intake and Backlog is the point. Most messy backlogs are messy because someone dropped raw feedback straight into the work queue and nobody ever pruned it.

The ways to slice work

Different mechanisms for different questions, so they never fight each other:

Question	Mechanism
What theme does this belong to?	The Epic field, and the epic it sits under
Which platform does this touch?	The Component field — Web, iOS, Android, Desktop, Backend
Which sprint is it in?	A tag — `Sprint 1`, `Sprint 2`, `Sprint 3`
How big is it?	The Story Points field
How much does it matter?	The Business Value field (MoSCoW)

Component is a field, not a section. Earlier versions of this template filed work under Websites / iOS / Android / Desktop. That looks tidy and quietly breaks Agile: a backlog organized by team silo cannot be ordered by value, which is the one property a product backlog must have. The platform information still exists — it just stopped running the show.

The workflow statuses

Backlog → Ready → In Progress → In Review → In QA → Done

Plus Won't Do, a completed variant for work you consciously decline. Use it. A silent no teaches nobody.

Blocked is a tag, not a status, because blocking is orthogonal to progress — a story can be blocked while sitting in QA. Tag it Blocked, name the blocker, give it an owner.

The views to use

View	Good for
List	The backlog. Ordering, refinement, bulk edits
Board	The sprint. Group by Status for a kanban board, or by Assignee for load
Timeline	Releases and dependencies (Professional plan or higher)
Sublists	Saved slices — the current sprint, the retro board

2. Agile & Scrum glossary

The frame

Agile is a set of values, not a process. Deliver working software often, respond to change, favor collaboration over contract negotiation.

Scrum is the most common process built on those values. Fixed-length sprints, three accountabilities, five ceremonies. This template is Scrum-shaped.

Kanban is the other common one: continuous flow, no sprints, limits on work in progress. If you run Kanban, keep the statuses in this template, drop the sprint tags, and add WIP limits.

The artifacts

Term	What it means	In Quire
Epic	A large body of work sharing a theme. Spans several sprints	A parent task under 📋 Product Backlog, plus the `Epic` field
User story	A small, valuable, testable slice described from the user's point of view	A task under an epic
Task / subtask	A unit of actionable work. Not necessarily user-visible	A subtask under a story
Product Backlog	Every refined item, ordered by value. Owned by one person	The 📋 Product Backlog section
Sprint Backlog	The subset the team committed to this sprint	Tasks tagged `Sprint N`
Increment	The working, shippable output of a sprint	Everything at `Done` that meets the Definition of Done
Spike	Timeboxed research. Deliverable is an answer, not a feature	A task tagged `Spike`
Technical debt	Shortcuts taken earlier that now slow you down	A task tagged `Tech Debt`

Correcting a common mistake: an epic is not the same thing as a project. An epic lives inside a product and shares its backlog with other epics. Treating each epic as its own project is how teams end up with five backlogs and no way to say what matters most across them.

The events

Term	Cadence	Timebox (2-week sprint)
Sprint	The container	1–4 weeks. Two is standard
Sprint Planning	Start of each sprint	2 hours
Daily Standup	Every working day	15 minutes
Backlog Refinement	Weekly	1 hour
Sprint Review	End of each sprint	1 hour
Sprint Retrospective	End of each sprint	1 hour

All five exist as recurring tasks under 🔄 Ceremonies, each with a full agenda.

Correcting a common mistake: the daily standup covers yesterday and today. Not last week and next week. A daily ceremony framed in weekly terms is just a status meeting held five times too often, and it is the fastest way to make standups feel pointless.

The people

Term	Owns
Product Owner	The what and why. The backlog
Scrum Master	The how well. The process
Development Team	The how. The delivery
Stakeholder	Nothing in the process. Attends the review

Correcting a common mistake: there is no Project Manager role in Scrum, and user stories are not written by one. The Product Owner owns the backlog; stories are written collaboratively during refinement.

The measurements

Term	Means
Story points	Relative effort — volume, complexity, and uncertainty combined. Not hours
Velocity	Completed points per sprint. A forecasting input, never a target
Burndown	Remaining work against days left in the sprint
Cycle time	How long a story takes from In Progress to Done
WIP	Items in flight right now. Lower is faster
Capacity	Hours the team actually has this sprint, after holidays and support duty

The agreements

Term	Means
Definition of Ready	The gate before a story may enter a sprint — section 5
Definition of Done	The gate before anything is called finished — section 6
Acceptance criteria	Per-story pass/fail conditions, written Given / When / Then
Sprint goal	One sentence describing what the sprint achieves
Working agreement	How the team has agreed to work — core hours, review turnaround, and so on

3. Who does what

Three accountabilities. Not three job titles — one person can hold more than one, and a large team can have several people behind one.

Product Owner

Owns: the what and the why. One person, not a committee.

Writes and orders the Product Backlog
Decides what enters a sprint and what gets declined
Says no, out loud, with a reason
Represents the customer inside the team and the team outside it
Accepts or rejects finished work against acceptance criteria

Anti-patterns:

Absent Product Owner. Ships requirements by email, never attends refinement, then rejects at review. The team burns a sprint learning what was actually wanted.
Product Owner by committee. Four stakeholders all reorder the backlog. Nothing is ever the top priority.
Product Owner who also assigns tasks. Owning what does not include owning how. The moment the Product Owner allocates work, the team stops owning delivery.

Scrum Master

Owns: the how well. A facilitator, not a manager. Nobody reports to the Scrum Master.

Runs the ceremonies and defends the timeboxes
Removes blockers the team cannot remove alone
Shields the team from mid-sprint scope changes
Coaches the team toward better practice, including the uncomfortable parts

Anti-patterns:

Scrum Master as project manager. Assigns tasks, chases status, reports upward. This is the most common failure and it kills team ownership within two sprints.
Scrum Master as meeting scheduler. Books the ceremonies, facilitates none of them, removes no blockers.
Scrum Master who is also the team's line manager. People will not raise real problems in a retro run by the person who writes their review.

Development Team

Owns: the how and the delivery. Cross-functional — design, engineering, QA, whatever it takes to get to Done. Typically 3–9 people.

Estimates the work. Nobody estimates on the team's behalf
Decides how much fits in a sprint
Self-organizes: pulls work rather than receiving assignments
Holds the Definition of Done

Anti-patterns:

Component teams pretending to be one team. "The backend team" and "the frontend team" inside one Scrum team means every story needs a handoff and nothing finishes inside a sprint.
A team that accepts a capacity number from outside. If someone else decides what fits, the commitment is not the team's, and neither is the accountability.
A hero. One person who knows the critical system and never pairs. This looks like speed and is actually your largest single point of failure.

4. How to write a user story

A user story is a promise to have a conversation, not a specification. It is short on purpose.

The form

As a [type of user] I want [some goal] so that [some reason]

The third line is the one everyone drops, and it is the most valuable. Without the why, the team cannot propose a cheaper way to get the same outcome — and they usually can.

Weak: Add a CSV export button

Better: As an account admin, I want to export my team's activity as a CSV, so that I can reconcile it against our internal billing sheet

The second version invites someone to ask: would a monthly emailed summary solve this at a tenth of the cost? That conversation cannot happen with the first version.

Acceptance criteria

The story is the conversation. Acceptance criteria are what you agreed. Write them as Given / When / Then.

Given I am signed in and have at least one uploaded file When I select "Export all content" from the account menu Then I receive a ZIP archive containing every file I have uploaded, and an email confirming the export

Cover the unhappy paths too. Empty state, permission denied, network failure, the 10,000-file account. Most defects are missing acceptance criteria that someone assumed were obvious.

INVEST — the quality bar

Letter	Means	Fails when
Independent	Can ship on its own	Story B is meaningless without story A
Negotiable	Describes the need, not the solution	It specifies a dropdown, a color, and a database table
Valuable	A user or the business notices	"Refactor the auth module" — that is a `Tech Debt` task, not a story
Estimable	Team can size it	Nobody knows the answer → write a `Spike` first
Small	Fits comfortably in one sprint	Over 8 points → split it
Testable	Pass / fail is unambiguous	"Make it fast" — fast compared to what?

How to split a story that is too big

In rough order of usefulness:

By workflow step — sign up, then verify email, then complete profile
By business rule — the simple case first, edge cases after
By happy path vs. error handling — ship the happy path, then harden it
By data variation — one file type first, the rest later
By platform — web first, mobile next. Use the Component field, not separate sections
Spike then build — when the unknown is the real problem

Do not split by technical layer. "Backend for X" and "frontend for X" are two tasks that each deliver nothing. If you must track them separately, make them subtasks of one story.

Not everything is a story

Type	Tag	Points?
User story	—	Yes
Bug	`Bug`	Team's choice — be consistent
Technical debt	`Tech Debt`	Yes
Timeboxed research	`Spike`	Size = the timebox
Necessary chore, no user value	`Chore`	Usually no

Forcing "As a developer, I want…" onto every technical task is theater. Tag it and move on.

Copy this into a new story

As a [user type]
I want [goal]
so that [benefit]

### Acceptance criteria
- Given ... When ... Then ...
- Given ... When ... Then ...

### Out of scope
- 

### Open questions
- 

### Definition of Done
- [ ] Acceptance criteria pass
- [ ] Code reviewed and merged
- [ ] Tests written and green
- [ ] Docs updated
- [ ] Accepted by Product Owner

5. Definition of Ready

The gate a story passes before it is allowed into a sprint.

Without this gate, planning turns into requirements discovery, sprints overrun, and the team learns that estimates are meaningless. Adapt the list below, but keep one.

The checklist

How to use it

Stories arrive in the backlog as Backlog status
Backlog Refinement works them toward this checklist
When every box is checked, move the status to Ready
Only Ready stories may be pulled into a sprint

Anything still short gets tagged Needs Refinement and stays out.

The rule everyone breaks

Do not pull an unready story into a sprint because the sprint looks empty.

This feels responsible and it is the single most reliable way to miss a sprint. An unready story does not get smaller once it is inside the sprint — it gets discovered, and discovery is unbounded. Pull the next Ready story instead, or accept a lighter sprint and use the slack on Tech Debt.

If you never have enough Ready stories, refinement is under-invested, not planning.

Adapting it

Too strict and nothing is ever ready. Too loose and the gate does nothing.

A new team should start looser and tighten after a few retros
Bugs get their own shorter version: reproducible, severity assigned, environment noted
Spikes are ready when the question and the timebox are written down

Revisit this list in the retro whenever a sprint misses because of something a story failed to say.

6. Definition of Done

The shared, non-negotiable standard for calling anything finished. One definition for the whole team, not one per person.

Without it, "done" means "done on my machine" and the last 20% of every story reappears three sprints later as a bug.

The checklist

Code

All acceptance criteria pass
Peer reviewed and approved
Merged to the main branch
No new linter or static analysis warnings

Testing

Unit tests written and passing
Integration tests updated where behavior changed
Manually verified against the acceptance criteria
No known regressions introduced

Quality

Works on supported browsers and devices
Accessibility checked — keyboard navigation, contrast, labels
Error and empty states handled, not just the happy path
Performance acceptable on realistic data volumes

Release readiness

Deployed to staging
Documentation or help content updated
Analytics or logging added where the story needs measurement
Feature flag configured if the release is staged

Acceptance

Product Owner has reviewed it and accepted it

Rules that actually matter

Done means potentially shippable. Not "code complete." Not "just needs testing." If a story needs anything before a user could touch it, it is not Done.

Partial credit does not exist. A story is Done or it is not. Eighty percent of a story delivers zero value. This is why velocity counts only completed points — anything else lets a team feel productive while shipping nothing.

Unfinished work goes back to the backlog and gets re-estimated. Do not silently carry it into the next sprint at its old size. If it was a 5 and half of it is left, it is not "2.5 remaining" — re-estimate it honestly.

The Definition of Done is a team agreement, not a manager's checklist. The team writes it, the team can change it in a retro, and the team holds each other to it.

Where to put it

Paste the checklist into each story's description during refinement. Quire renders - [ ] as a working checkbox, so it becomes a real gate instead of a poster on a wall.

Adapting it

Start with what the team can genuinely hit every sprint. A Definition of Done nobody meets is worse than a short one everybody does.

Then tighten it deliberately — add one item per quarter, chosen in a retro, usually in response to something that went wrong. That is how a team gets better without pretending.

7. Estimating with story points

Story points measure effort, not hours. That distinction is the whole reason they work, and conflating the two is the most common estimation mistake teams make.

Why not hours

Hours are absolute and personal. A senior engineer's "4 hours" and a junior's "4 hours" are different numbers for the same work, so the estimate becomes a negotiation about whose hours count.

Points are relative and shared. "This is about twice the work of that one" is a judgment a team can agree on quickly and be roughly right about. Humans are poor at absolute estimation and decent at comparison.

Points also absorb three things at once: volume of work, complexity, and uncertainty. A task that is simple but large and a task that is small but unknown can both be a 5, for different reasons.

The scale

Fibonacci: 1, 2, 3, 5, 8, 13, 21

The gaps widen on purpose. Nobody can tell an 8 from a 9, and pretending otherwise wastes the meeting. Bigger numbers carry more uncertainty, and the scale should say so.

Points	Roughly means
1	Trivial. Understood completely. Copy change, config tweak
2	Small, familiar, no unknowns
3	Normal story. A day or two of focused work
5	Substantial. Several moving parts, still one sprint
8	Large. At the edge. Consider splitting
13	Too big. Split it before it enters a sprint
21	This is an epic, not a story

Nothing above 8 enters a sprint. That is not a suggestion. A 13 means the team does not understand the work well enough to commit to it.

Getting started: the reference story

Pick one story everybody understands and agrees is small. Call it a 3. Estimate everything else against it.

That is it. Do not build a conversion table from points to hours. The moment you do, you have reinvented hours with extra steps, and you lose the one property that made points useful.

Planning poker

Product Owner reads the story
Team asks questions until nobody has one
Everyone picks a number privately
Reveal simultaneously
If the spread is wide, the highest and lowest explain their thinking
Re-vote

The disagreement is the point. When one person says 2 and another says 13, they are looking at different work. Surfacing that before the sprint costs five minutes. Surfacing it mid-sprint costs the sprint.

Private voting matters. Once the tech lead says "five," the room says five.

Rules that actually matter

Only the people doing the work estimate. Not the Product Owner, not a manager, not last year's team.

Estimate the whole story, not your slice. Points cover design, build, test, review, and deploy.

Never convert points to hours in public. The moment leadership learns that 1 point equals 6 hours, points become a deadline commitment and the team starts inflating them. Both sides then negotiate the number instead of the work.

Do not re-estimate finished work to make velocity look better. Velocity is a planning input, not a performance score. Gaming it destroys the only forecasting tool you have.

Do not compare velocity across teams. A 5 on one team is not a 5 on another. There is no exchange rate, and looking for one turns estimation into politics.

What about hours?

Use Quire's built-in time estimate and time log for hours if your organization needs them for billing or capacity. Keep them separate from story points and never let one drive the other.

8. Running a sprint

A sprint is a fixed timebox that produces something potentially shippable. Fixed is the operative word: the dates never move, the scope does.

Choosing a length

Length	Works when	Costs
1 week	Requirements shift fast, team is co-located	Ceremony overhead is high relative to work time
2 weeks	Most teams, most of the time	—
3–4 weeks	Long build cycles, heavy compliance	Feedback arrives too late to be cheap

Start at two weeks. It is long enough to finish something real and short enough that a bad call costs ten days, not a month.

Never change sprint length mid-flight to fit work in. That single act destroys velocity as a forecasting tool, and velocity is the only forecasting tool you have.

The two-week cadence

When	What	Length
Monday, week 1	Sprint Planning	2 hours
Every weekday	Daily Standup	15 min
Wednesday, both weeks	Backlog Refinement	1 hour
Friday, week 2	Sprint Review / Demo	1 hour
Friday, week 2	Sprint Retrospective	1 hour

About 7 hours of ceremony across 10 working days. Roughly 9% of capacity. If it costs materially more than that, the timeboxes are not being defended.

All five exist as recurring tasks under 🔄 Ceremonies, each with a full agenda. Adjust the days to suit your team, but do not quietly drop refinement or the retro — those two are always the first to go and always the ones you needed.

Sprint schedule in this template

Sprint	Start	End
Sprint 1	Mon, Aug 10, 2026	Fri, Aug 21, 2026
Sprint 2	Mon, Aug 24, 2026	Fri, Sep 4, 2026
Sprint 3	Mon, Sep 7, 2026	Fri, Sep 18, 2026

Tag work with Sprint 1, Sprint 2, or Sprint 3. Sublists give you a saved board per sprint.

Reset these dates on your first day. They are illustrative.

The sprint goal

One sentence describing what this sprint achieves. Not a list of tickets.

Weak: Finish stories 12, 15, 18, and 22

Better: A new user can sign in with Google on all three platforms

A real goal gives the team something to trade against. When week two goes sideways, they can cut the story that does not serve the goal instead of cutting the one that happens to be hardest.

Mid-sprint changes

The sprint backlog is the team's commitment, and it is protected. When something new arrives:

Does it genuinely need to happen before the next sprint? Most things do not
If it truly does, something of equal size comes out. The Product Owner chooses what
If the sprint goal itself is no longer worth pursuing, cancel the sprint and re-plan. This is rare and it is allowed

Never just add work. "Can you squeeze this in" is how a team ends a sprint having finished nothing.

Ending a sprint

Unfinished work goes back to the backlog and gets re-estimated, not carried at its old size
Count only completed points toward velocity. Partial credit does not exist
Do not extend the sprint by a few days to finish something. Ever
Run the review and the retro separately. Merging them means the retro gets skipped

9. Tracking progress

Four numbers worth watching, and the honest limits of each.

Velocity

Completed story points per sprint. Only completed — partial credit does not exist.

Use it for: forecasting. After three or four sprints, average your velocity and use the range to answer "roughly when will this epic be done?"

Never use it for: comparing teams, evaluating individuals, or setting targets. The moment velocity becomes a goal, it stops measuring anything — the team simply inflates estimates and the number goes up while output does not.

Reading it honestly:

Ignore the first 3–4 sprints. A new team's velocity is noise
Use a rolling 3-sprint average, not last sprint's number
Forecast as a range, not a point. "18–24 points" is honest; "21 points" is not
A sudden drop is information, not failure. Ask what changed

Sprint burndown

Remaining work against days left. Shows whether the sprint is tracking.

Reading the shape:

Flat then a cliff — everything finishes on the last day. Usually means stories are too large or work in progress is too high
Rises mid-sprint — scope was added after planning. Look at why
Flat at the end — something is stuck. This should have surfaced at standup two days earlier

A burndown that is behind is not a reason to work weekends. It is a reason to cut scope and talk about it at the retro.

Cycle time

How long a story takes from In Progress to Done.

This is often more useful than velocity because it is harder to game and it exposes the real problem: waiting. Most cycle time is not spent working. It is spent sitting in review, waiting for QA, waiting for a decision.

If cycle time is long, look at queues before you look at effort.

Work in progress

How many items are between Ready and Done right now.

More items in flight means everything finishes later. A team of five with twelve stories open finishes nothing until the end of the sprint, then finishes everything at once — the cliff shape in the burndown.

Try a WIP limit. Roughly one and a half items per person. When you hit the limit, finish something before starting something. Teams find this uncomfortable for about a week and then never go back.

Where to look in Quire

What	Where
Sprint board	Board view, filtered by the `Sprint N` tag, grouped by Status
Points in flight	Sum the Story Points field across a filtered view
Blocked work	Filter by the `Blocked` tag
Release timing	Timeline view (Professional plan or higher)
Per-person load	Board view grouped by Assignee

The one thing to remember

These are the team's numbers, for the team's decisions. The moment they are reported upward as a performance measure, they stop describing reality — not because anyone is dishonest, but because people optimize what they are measured on. Every time.

The honest measure of an Agile team is working software that users value. Everything on this page is a proxy.

10. Make this template yours

The template is a starting point, not an answer.

Day one

Reset the sprint dates. The ones here are illustrative. Set your real Sprint 1 window
Fix the ceremony schedule. Open 🔄 Ceremonies and move each recurring task to the day and time your team actually meets
Delete the sample data. The stories, defects, and feedback items are examples. Keep them only while you are learning the structure
Invite the team and confirm who holds Product Owner and Scrum Master

First week

Rewrite the epics to match your product. The five here are illustrative
Edit the Epic and Component field options to match your real themes and platforms
Agree your Definition of Done as a team. Do not adopt section 6 unchanged — write the version you can genuinely hit every sprint
Agree your Definition of Ready. Same rule. Start looser than you think and tighten in retros
Pick a reference story for estimation and size everything against it
Set up your sprint sublists in Board view, grouped by Status

After three or four sprints

Check your first real velocity. Ignore anything from before this point
Revisit your Definition of Done in a retro and add one item

Things worth changing

If your team…	Then
Has a distinct design phase	Add a status at value 40, e.g. `In Design`
Has no separate QA	Delete the `In QA` status
Runs Kanban, not Scrum	Delete the sprint tags and sublists, keep the statuses, add WIP limits
Is not building software	Rename `In Review` and `In QA` to whatever your review steps really are
Is on a Free or Starter plan	Custom fields and extra sublists may be limited. Fall back to tags and description conventions

Things worth keeping

Opinionated, from watching teams fail at these specifically:

Keep the Intake / Backlog separation. The moment raw feedback goes straight into the backlog, the backlog stops being orderable and starts being a graveyard.

Keep Backlog Refinement weekly. It is the ceremony teams cut first and the reason their planning runs long.

Keep the retro, and keep it separate from the review. When they are merged, the retro is what gets dropped.

Keep Story Points as a field, not free text. Points buried in a description cannot be summed, which means no velocity, which means no forecasting.

Keep Won't Do as a real status. Declining work explicitly, with a reason, is a feature. Silence is not.

Getting help

Questions about Quire itself: send the team a message.

Plan notes

Timeline view requires Professional or higher
Custom fields are plan-dependent — Story Points, Epic, Component, and Business Value may not carry over on lower tiers
If duplicating this template fails, it is usually a sublist quota limit

Project: Agile