Agile Project Template
A sprint board that doesn't assume you're building software: backlog, this sprint, review, done, sized to what the team actually finished last time.
Nothing here mentions code. The columns are the same whether the team ships software, campaigns, or contracts.
Why most "agile" boards stop being agile
Most teams that adopt sprints keep the ceremony and lose the discipline within a few cycles. The board still says "sprint," but three specific habits quietly turn it back into a plain to-do list with a deadline. The standup still happens, the columns still exist, and none of it changes what actually gets prioritized or finished.
The backlog isn't ranked, it's just long. Everything the team might ever do sits in one column with no order, so "what's next" gets decided in the sprint planning meeting from scratch every time, rather than being mostly settled by an ordered list someone maintains between sprints.
Sprints get committed by hope instead of history. The team agrees to take on a stack of work because it seems reasonable, not because it matches what they actually finished last sprint or the one before. The commitment is optimistic on day one and abandoned by day four.
Review happens, but nothing changes afterward. The team looks at what got done, says a few things went well and a few didn't, and starts the next sprint exactly the same way. A retro that doesn't change the next sprint's plan is a meeting, not a feedback loop.
None of that is really about the framework. Teams that call their process something else, or nothing at all, run into the same three problems the moment they try to plan in fixed cycles. The fix isn't a stricter ceremony; it's a board that makes the ranked list, the capacity limit and the review outcome visible instead of implicit.
This template is deliberately not tied to software. It's the underlying agile shape: a ranked backlog, a capacity-sized sprint, a review, a done column, usable by a marketing team, an operations team, or a mixed group that's never called itself "engineering" in its life.
The structure, and why each part is there
Not a pile, an ordered list, maintained between sprints rather than reordered from scratch in the planning meeting. When it's time to plan, the question is how far down the list you get to, not what belongs on it.
Delivery forecasts are calculated from the team's actual velocity as sprints complete, so "how much can we take on" is answered by recent history instead of a guess that resets every two weeks. Most teams see the gap between what they commit to and what they actually deliver close within three or four sprints, once the forecast has real history to draw on.
Planning accounts for who's genuinely available that sprint, with approved leave factored in. A five-person team with two people on leave isn't a five-person team's worth of capacity, and the plan should say so.
Work sits here until it's actually checked against what "done" was supposed to mean, rather than moving straight from in-progress to done on the strength of someone saying it's finished. For a non-software team this might be a second read-through rather than a code review. The gate matters more than what checking it looks like.
Logging a day's hours takes about five seconds and sits right next to the task just finished, which is close enough to the moment that people actually do it. The main reason most time tracking gets abandoned is that it's too far from the work.
What the retro decided to change lives on a page next to the sprint, with history, and any sentence on it can become a task, so "we agreed to fix this" turns into something on next sprint's board instead of a note nobody reopens. Teams that keep this habit tend to notice the same retro complaint stop showing up after a sprint or two, because it actually got turned into work.
New requests don't get inserted straight into the current sprint or silently dropped into the backlog unranked. They land in one inbox, where someone decides whether, and where, they belong before the ranked list absorbs them.
How to use it
- 01Start a workspace. It opens with a sample project already on the board, so the sprint flow is visible before you load real work into it. Free for up to five people, permanently.
- 02Rank the backlog before the first planning session, not during it. Even a rough order beats deciding priority live in a room with everyone waiting.
- 03Commit to a sprint size based on last sprint's actual output. There won't be history for the first sprint, so guess conservatively and let the number correct itself from the second sprint on. Most teams overcommit for the first two or three sprints before the forecast catches up to reality.
- 04Hold work in Review until it's actually checked. Deciding what "checked" means for your team, in one sentence, prevents most disputes about whether something is really done.
- 05Write down what the retro changes, and turn it into a task before the next sprint starts. A retro that doesn't produce at least one task on the next board didn't change anything.
None of this requires calling the framework Scrum, or running two-week cycles specifically. The shape (rank, commit to capacity, review, done) holds for a team running one-week sprints, three-week sprints, or something looser that just borrows the discipline.
- A ranked backlog does most of planning's work before the planning meeting starts
- Sprint size should come from measured velocity, not optimism
- A retro that doesn't produce a task on the next sprint didn't actually change anything
Common questions
No, that's the point of this template. The columns don't reference code, tickets, or deploys. Marketing, operations, HR and mixed teams use the same backlog-sprint-review-done shape with their own kind of work in it.
No. This is the general agile shape without Scrum-specific ceremony baked in: no mandated roles, no fixed sprint length. If your team runs a more formal Scrum process, the columns, limits and cadence here are all editable to match it.
It doesn't exist until you have a completed sprint to measure. The first sprint's size is a judgment call. From the second sprint onward, forecasts are calculated from the team's actual completed work, and they get more reliable as more sprints close.
Each project keeps its own board and its own sprint cadence. A one-week sprint for a fast-moving team and a three-week sprint for another don't have to match. Velocity and forecasts are calculated per project, against that project's own history.
No. Velocity and forecasts work from completed work over time, not from a specific estimation method. Teams that count items, teams that use points, and teams that just track hours all get a usable measure of what they actually finish per sprint.
Yes. All templates are included on the Free plan, which covers up to five users and two projects and doesn't expire. See pricing for larger teams.
Related pages
See it on your own work.
A workspace your whole company will actually use is 60 seconds away. No card, no risk, nothing to install.
14-day full-access trial · sample project included · no card required