Sprints, Points & Velocity: When They Help and When They Lie
Sprints, story points, burndown and velocity are genuinely useful to a small number of teams and pure theatre for everyone else. Here is how to tell which you are, and exactly what the charts compute — including the two simplifications that make a healthy team look behind.
A Nairobi software team runs two-week sprints. They have a burndown chart on the wall. It has looked like a flat line for four sprints and nobody has mentioned it. When somebody finally asks, the answer is not that the team stopped delivering — it is that the chart was counting a status nobody uses. Four sprints of a metric that measured nothing, displayed with total confidence.
That is the shape of most agile tooling failure. Not that the ideas are wrong — for a stable team doing genuinely uncertain work they are among the best planning tools available — but that the numbers are trusted long past the point where they mean anything. So this post does two things: it says plainly who should use sprints, and it says exactly what our charts compute so you can decide whether to believe them.
The vocabulary, translated
Half the resistance to agile in Kenyan teams is vocabulary rather than substance. Stripped of the jargon, each of these is a small, concrete thing.
What the words mean in this system
The word What it actually is
Sprint A named, dated bucket of tasks
It belongs to a project, has a name, a goal, a start and end date, and a status of planning, active or completed. Tasks are put into it. That is the whole object.
Story points A whole number on a task
A relative size estimate. Not hours, not days — a number your team agrees means "about this much effort compared to that other thing". Its only job is to be consistent within your team.
Commitment The sum of points in the sprint
What the sprint currently contains. Note the word currently — this is computed live, so it changes when tasks are added or removed mid-sprint.
Burndown Points still open, day by day
A line showing what remains open on each day of the sprint, drawn against a straight ideal line from the full commitment to zero.
Velocity Average points finished per completed sprint
The mean of done points across every sprint you have marked completed, in the order they were completed. A planning input, not a performance score.
Notice what none of these are: an estimate in hours, a commitment to a date, or a measure of how hard anyone worked. Every misuse of agile metrics in a Kenyan office we have seen starts by treating one of them as one of those three things.
Exactly what the burndown computes
This matters because the chart is easy to over-read. For each day of the sprint, the line shows the total commitment less the points on tasks completed on or before that day. The ideal line is a straight descent from the commitment to zero, spread evenly across the days between start and end. If a sprint has no end date, fourteen days is assumed.
A 34-point sprint over two calendar weeks
The ideal line runs over calendar days, not working days. So every weekend the ideal keeps descending while nobody is working, and a perfectly healthy team appears to fall behind on Monday morning and catch up by Wednesday. Read the shape of your line, not its position against the ideal — and read it over a whole sprint, not daily.
One more behaviour to know: the commitment used for the whole chart is the sprint's current total. Add a task on day eight and the entire line rises retroactively, as though the work had been there from the start. There is no scope-change step in the chart. That is a legitimate reason a burndown can look worse on Friday than it did on Thursday despite genuine progress — and it is a decent argument for not adding to a sprint once it is running.
If your chart is flat, check your board columns first
A bug we found while writing this post, and fixed
Until recently, burndown and velocity counted only the built-in done status. A project that defined its own board columns — fully supported, with their own done flag — had its progress percentage computed correctly while its burndown stayed flat and its velocity read zero. Both now resolve the full set of done statuses for your organization, including custom columns. Worth knowing because it means a historical chart that looked flat was measuring nothing, not a team that delivered nothing.
The wider lesson holds regardless of whose software you use: a metric that reads zero looks exactly like a team that produced nothing, and the chart will never tell you which it is. If a line has never moved, distrust the instrument before you distrust the people.
Should your team use sprints at all?
Most teams who ask us this should not, and saying so is more useful than selling them a burndown. Sprints solve a specific problem: work whose scope is genuinely uncertain, done by a stable team, where the value of a regular forecast exceeds the cost of producing it. Take away any of those three conditions and the ceremony costs more than it returns.
Five conditions — how many hold for your team?
Sprints are worth the overhead when most of these are true. Two or fewer and you want a plan with dates and dependencies instead.
The same people work together for months at a time
Make them prove it: List who worked the last three sprints. If the roster changes every time, velocity is measuring a different team each round and cannot be averaged meaningfully.
The work is genuinely uncertain in scope
Make them prove it: Could you write down the finished task list up front? If yes, you want a plan with dependencies, not an iterative forecast.
The team is not constantly interrupted by unplanned work
Make them prove it: Count how much of the last sprint was support and emergencies. Above roughly a third and you have a queue, not a sprint — and a queue is better run as a ticket flow.
Somebody actually uses the forecast to make a decision
Make them prove it: Name the last decision that changed because of a velocity figure. If nobody can, you are producing a number for its own sake.
You have completed at least three or four sprints
Make them prove it: Velocity from one or two sprints is noise. The average only starts to mean something once you have several comparable rounds behind you.
If your team is interrupted more than a third of the time, you do not have a sprint. You have a queue wearing a sprint's clothes.
The most common misdiagnosis
For interrupt-driven work, a ticket queue with priorities and response targets fits far better than an iteration — that is what a helpdesk queue is for. For work with a known shape and hard dates, plan it with dependencies and a critical path.
Questions to ask your own team this week
Four questions that reveal whether the metrics mean anything
What does a 5-point task mean, in your own words?
What you will probably hear
Two developers give two different answers, usually one in days and one in complexity.
What it tells you
Points only work if the team estimates consistently. If half the team is secretly converting to days, you have hour estimates with extra steps — and you would be better off estimating in hours honestly.
What happened to the work that did not finish last sprint?
What you will probably hear
"It carried over."
What it tells you
Carry-over is normal once. Habitual carry-over means the commitment is systematically too large, and your velocity is being propped up by counting the same work's eventual completion in a later sprint.
Who decides what goes into the sprint?
What you will probably hear
"Whoever shouts loudest during the week."
What it tells you
Mid-sprint additions raise the burndown retroactively and make the chart unreadable. If scope changes daily, the sprint boundary is not real and the chart cannot tell you anything.
What did we change after the last sprint review?
What you will probably hear
Nothing, or a vague intention.
What it tells you
A sprint that produces no change is a status meeting with a fortnightly cadence. The retrospective is the only part of the ceremony that has to happen for the rest of it to pay for itself.
What we do and do not do
What AWRA OpsHub does today
- Sprints belonging to a project, with a name, goal, start and end dates, and a planning / active / completed status.
- Story points on tasks, and tasks assigned into a sprint.
- A committed-points total and a done-points total per sprint.
- A day-by-day burndown of remaining points against a straight ideal line.
- Project velocity — done points per completed sprint, in completion order, with a rolling average.
- A fourteen-day assumption when a sprint has no end date, so a chart still draws.
- Custom per-project board columns, with their own done semantics driving progress, completion timestamps, burndown and velocity alike.
What it does not do
- A working-day ideal line. The ideal descends over calendar days, so weekends make a healthy team look behind.
- A scope-change marker: adding work mid-sprint raises the whole burndown retroactively rather than showing a step.
- Capacity planning — no per-person availability, leave-aware capacity, or "this sprint has four working days for Grace".
- A cumulative flow diagram, cycle time or lead time.
- Automatic sprint rollover of unfinished tasks into the next sprint.
- Points on subtasks rolling up to a parent task independently of the parent's own points.
The first two are honest simplifications you can work around by reading the shape of the line rather than its exact position — but they are worth knowing before you present a burndown to anyone who will draw a conclusion from it.
Our take
Sprints are a good tool for a stable team doing uncertain work, and dead weight for everyone else — which in Kenya is most teams asking about them, because most of the work is either interrupt-driven support or projects with fixed scope and a client date. If you run sprints, add nothing mid-sprint and treat velocity as a planning input after four sprints rather than a score after one. If you do not, plan with dependencies and dates and lose nothing.
The planning alternative is in dependencies, slack and the critical path, the structure underneath either approach is in subtasks, milestones and statuses, and what the hours actually cost is in project budget vs actual.
Sprints when they help, plans when they do not
Sprints, story points, burndown and velocity for teams that genuinely need iteration — alongside dependencies, milestones and costing for the work that does not.
See project delivery in AWRAFrequently asked questions
Why is our burndown chart flat?
If it has been flat since before this was written, the likely cause was a bug we have since fixed: burndown and velocity used to count only the built-in done status, so a project with renamed board columns reported zero while its progress percentage was computed correctly. Both now resolve your full set of done statuses, custom columns included. If a chart is still flat after that, check that your tasks actually carry story points — a sprint of unpointed tasks has a commitment of zero and nothing to burn down.
Are story points the same as hours?
No, and treating them as hours removes the only advantage they have. A point is a relative size — this is about twice that — and its value comes from being consistent within one team rather than comparable between teams. If your team is quietly converting points to days anyway, you would be better off estimating in hours openly, because at least then everyone knows what the number means.
Why does the burndown look worse after a weekend?
Because the ideal line descends over calendar days, not working days. Over a fourteen-day sprint it drops every day including Saturday and Sunday, so a team that works ten of those days appears to fall behind at each weekend and catch up midweek. Read the shape and direction of your remaining line over the sprint rather than its position against the ideal on any given morning.
What happens to the chart if we add work mid-sprint?
The whole line rises retroactively, because the chart uses the sprint's current total commitment for every day. There is no step showing that scope changed on day eight. This makes a burndown genuinely misleading on a team that keeps adding work, and it is the strongest practical argument for holding the sprint boundary once it starts.
How many sprints before velocity is useful?
Three or four completed ones, with roughly the same people. Velocity is the average of done points across completed sprints, so one or two data points is noise, and a roster that changes every sprint is measuring a different team each time. Use it to sanity-check what you can commit to next round, never to compare teams or to appraise individuals.
Do unfinished tasks roll into the next sprint automatically?
No. Carry-over is a deliberate act — you move the task into the new sprint yourself. That is arguably better than automatic rollover, because it forces a conversation about whether the work is still worth doing. Watch the pattern though: habitual carry-over means the commitment is systematically too large, and it inflates the velocity of whichever sprint eventually finishes the work.
Can we use sprints for support and maintenance work?
You can, but it usually fits badly. If more than roughly a third of a period is unplanned interruptions, you have a queue rather than an iteration, and a ticket flow with priorities and response targets will serve you better than a two-week commitment that reality overwrites on day three. Sprints are for uncertain work by a protected team; queues are for arriving work by an available one.
