Skip to content

Guide

How to use Sprintwise

Eight steps from a messy backlog to a one-page sprint report, plus every word you'll meet along the way.

The idea in one minute

Teams often start a sprint with stories that are unclear, then the plan changes halfway through and nobody can say by how much. Sprintwise helps with both.

Before the sprint, it scores each story so you can see which ones are clear enough to commit to, and why the others aren't. During and after, it compares the sprint with what the team committed to on day one, so the retrospective can talk about numbers instead of feelings.

Step by step

  1. 1

    Create a project

    Sign in with GitHub and create one project per team or backlog.

  2. 2

    Add your stories

    Score a story by typing it in; the score updates as you type. Or import a CSV, connect Jira and import straight from a search, or load 12 sample stories to practise with. Connected projects can Sync from Jira and Send edits back.

  3. 3

    Order the backlog and fix the weakest stories

    Drag stories into priority order. Then list them weakest first, open a story, read why it lost points, and choose Edit story to fix it; Next to fix takes you to the next one. Aim for Ready (80 or more) before planning.

  4. 4

    Refine together

    In the team's refinement meeting, open Refinement from the backlog. It shows one story at a time with what's missing. Fix it together, then everyone shows a size (1, 2, 3, 5, 8 or 13); the highest and lowest explain, the team agrees, and you click that size. Share a read-only backlog link if people want to read ahead.

  5. 5

    Create a sprint and lock the baseline

    On day one, create the sprint, write its goal, and tick the stories the team committed to. Sprintwise warns you about stories that aren't Ready and about planning more than the team usually finishes. Locking them makes the baseline.

  6. 6

    Keep it up to date as the sprint runs

    Update statuses (To Do, In Progress, Done) and points straight from the backlog or the sprint page. A sprint built from the backlog records each change by itself; one built from CSVs needs a fresh export saved as a snapshot. Tag why each scope change happened: a bug, a stakeholder request, discovered work or tech debt.

  7. 7

    Open the report for the retrospective

    One printable page: the goal and whether it was met, how much scope was added or removed and why, churn, completion, and whether the stories that changed scored low before planning. Share a read-only link with stakeholders.

  8. 8

    Watch the trends

    After a few sprints, the Trends tab shows velocity, completion, churn and readiness over time, with plain-English insights. The planning helper uses the same velocity.

Try it in the demo first

What the numbers mean

Readiness score
Out of 100, from nine fixed rules. 80 or more is Ready, 50 to 79 needs work, below 50 isn't ready.
Net change
How much bigger or smaller the sprint got. +20% means 20% more work than the team committed to.
Burn-up
The sprint page's chart of scope and work done on each snapshot day, against the day-one commitment. When the two lines meet, everything in the sprint is done.
Churn
How much work moved in, moved out or changed size, even if the total stayed the same. High churn means an unstable sprint.
Completion
How much of the original commitment got done. Work added later doesn't count towards it. Which statuses count as done is set in project settings.
Velocity
Points of the original commitment the team finished, averaged over the last three sprints. A planning guide, not a target.
Team checks
Your own Definition of Ready items, such as “has a design link”. They don't change the score, but a story that fails one can't be Ready.
Worth a second look
Signs of an AI draft pasted without a careful read: chat leftovers (“Certainly! Here's…”), unfilled placeholders, criteria that fit any story, filler words and made-up figures. They don't change the score, but leftovers and placeholders keep a story from being Ready.

Words you'll see

New to Scrum or Jira? Start here.

Sprint
A short block of time, usually two weeks, in which the team picks some work and tries to finish it.
Backlog
The team's to-do list: everything it might build, in priority order.
User story
One item on the backlog, written from the user's side: “As a customer, I want to save my card, so that checkout is faster next time.”
Acceptance criteria
A short checklist that says when a story is done, such as “The card is saved after payment.” One per line.
Story points
A rough guess at a story's size, testing included: a story isn't done until it's tested. Small is 1 or 2, large is 8 or more. They measure size, not hours, and leave room for bugs by themselves: velocity counts only planned work that got done.
Product Owner
The person who decides what goes on the backlog and in what order, and who writes or approves the stories.
Commitment
The stories the team agrees to finish in a sprint, chosen in sprint planning.
Baseline
Sprintwise's frozen copy of the commitment, taken on day one. It can't be edited, so every change is measured against it.
Snapshot
A later copy of the sprint, taken while it runs. Sprintwise compares it with the baseline, story by story.
Sprint goal
One sentence on what the sprint should achieve. At the end, the team records whether it was met.
Definition of Ready
The team's agreed list of what a story needs before it can be planned. Sprintwise's rules are a starting point; team checks add your own.
Jira
A popular tool for keeping the backlog. Sprintwise doesn't need it: type stories in, or upload a CSV exported from Jira or a spreadsheet. If your team uses Jira Cloud, connect it to import from a search, sync, and send your edits back.