How to Run a Two-Week Sprint with a Kanban Board, Deadlines, and a KPI

A sprint can look healthy on a task board while an important deadline slips or the team loses sight of its goal. A useful two-week overview puts three different signals together: a board for work status, an Upcoming agenda for dated events, and a metric tile for one key number. Each has a distinct job. Together, they help a team see what is moving, what is due, and whether the sprint is making progress.

The key is to configure each block deliberately. The board does not automatically supply the agenda dates or the KPI. Choose the relevant tasks, date source, and metric before relying on the page as a shared reference.

What the three sprint blocks show

• Board: A Kanban-style view that organizes tasks or ideas into draggable groups. Columns can represent stages such as To do, In progress, and Done.
• Upcoming: A list of the next deadlines or events drawn from a workspace database. It needs a database and a date property selected.
• Metric: A tile for one key number. Its value can be entered manually or linked to a database, and it can include an optional goal.

These blocks answer different questions, so avoid treating them as interchangeable. A board helps explain workflow; an agenda makes dates visible; a metric provides a compact measure. For details on arranging work into groups, see the Board block guide.

Start with the sprint outcome and one useful metric

Before adding tasks, write down what should be true at the end of the two weeks. Keep the outcome specific enough to guide decisions. For example, “prepare the onboarding flow for review” gives a team a clearer direction than “work on onboarding.”

Then choose one metric that helps assess progress toward that outcome. A team preparing a flow for review might track the number of review sessions completed, with a target of three. That is an illustrative choice, not a universal KPI. A count is useful only if the team agrees what qualifies as a completed session and why that count matters.

Use a database-backed metric when the relevant number is recorded in a database and can be linked in the metric settings. A manually entered value can suit a number that is tracked elsewhere or updated during a check-in. If a goal is useful, set one; do not add a target just to fill the tile. The Metric block guide can help clarify the block’s options.

Set up the board around the work

Break the sprint outcome into tasks small enough to review during the two weeks. Put those tasks on the board and use a small number of columns to represent the team’s actual workflow. A simple starting point is To do, In progress, and Done. Add a stage only when it answers a real question, such as whether work is waiting for review.

For each card, make the next action understandable without a separate explanation. “Draft the first-run checklist” is more actionable than “onboarding.” If a task has a deadline, ensure that date is recorded in the database used for the agenda as well. The board’s groups communicate status; the date information is what makes deadlines visible in Upcoming.

Keep the board focused on the current sprint. A long backlog can obscure the work the team has actually committed to finish. If a task is not part of the two-week effort, keep it out of the active view or clearly separate it from the sprint work.

Configure the Upcoming agenda with the right date source

The Upcoming block starts empty. To populate it, select the workspace database that holds the sprint’s deadlines or events, then choose its date property. That distinction matters: choosing the wrong database or date field can leave the agenda unhelpful even when dates exist elsewhere.

Use the agenda for dates the team needs to anticipate, such as a design review, a handoff, or a sprint-end demonstration. It complements the board rather than replacing it. A task can be in progress on the board while its review date appears in the agenda, giving the team both status and timing in view. For setup details, consult the Upcoming block guide.

Check that the selected database contains the dates the team intends to monitor. The agenda reflects the database and date property selected for it; it should not be assumed to find dates stored in unrelated places.

Put the three signals together and use them in check-ins

Arrange the blocks so the page answers three questions at a glance: what is the sprint trying to achieve, what work is underway, and what needs attention soon? A practical order is a short outcome statement and metric near the top, the board as the main working area, and the Upcoming agenda beside or below it. The exact layout matters less than keeping the information easy to find.

At a regular sprint check-in, use the same sequence:

1. Review the metric. Is the number moving toward the agreed goal? If it is not, decide whether the work, the measure, or the plan needs attention.
2. Scan the agenda. Identify deadlines or events that are approaching and confirm that the related work is visible on the board.
3. Review the board. Look for tasks that have stopped moving, too much work in progress, or cards that need a clear next action.
4. Update the shared view. Move cards when their status changes, keep relevant dates current in the selected database, and update a manual metric when the agreed check-in calls for it.

For example, midway through a sprint, the agenda might show a review scheduled for the next day while the related card remains in To do. That mismatch gives the team a concrete planning problem to resolve. A metric that has not changed can prompt a discussion, but the number alone cannot explain why progress stalled. Use the blocks to surface questions, then decide the next action with the people doing the work.

Know what this overview does not do

A combined page is a shared overview, not proof that every block is automatically synchronized with every other block. The board organizes cards, Upcoming reads deadlines or events from a selected database and date property, and the metric is either manually entered or configured with a database. Make sure the underlying information is maintained where each block expects to find it.

Also define the metric before interpreting it. A rising task count, for example, may show activity without showing that the sprint outcome is closer. Choose a number that corresponds to the result the team cares about, and keep its meaning consistent throughout the sprint.

ReadyTools Workspace is a block-based workspace that combines planning and structured data. For a broader view of planning work, see Workspace project management, or learn more about ReadyTools Workspace. The source catalog documents these block types and behaviors, but a catalog entry alone does not establish that a block is enabled for every account, plan, or deployment. Confirm availability in the workspace before building a process around it.