Scope creep = unplanned work added mid-sprint without removing equivalent work
Rollover = stories not finished; carried to the next sprint
0 / 10 completed
1 / 10
A Jira sprint report shows:
Sprint: "Sprint 42" — Day 6 of 10 Total commitment: 42 story points Completed: 18 pts Remaining: 24 pts Ideal remaining on day 6: 16.8 pts
How would you describe the sprint status at the daily standup?
Both B and C are correct — they just emphasise different things:
Option B (comparing to ideal burndown): • 18 / 42 = 43% complete • Day 6/10 = 60% of sprint time elapsed • Ideal: 42 × (1 − 6/10) = 16.8 pts remaining • Actual: 24 pts remaining → 24 − 16.8 = 7.2 pts behind ideal → Best for stakeholders and PMs who look at charts
Option C (projection / remaining-velocity): • Daily velocity so far: 18 pts / 6 days = 3 pts/day • Days remaining: 4 • Points remaining: 24 • Required velocity: 24 / 4 = 6 pts/day — twice current pace → Best for the dev team at standup — actionable, concrete
Key vocabulary: • burndown — chart showing remaining work over time; should trend toward 0 by sprint end • ideal burndown — straight line from total commitment on day 1 to 0 on day 10 • velocity — story points completed per day (or per sprint) • at risk — the sprint goal may not be achieved without changes • commitment — the total work the team agreed to complete
A manager says "great sprint — 100% delivered!" Is this accurate?
Option B is most nuanced and accurate.
The calculation: • Original commitment: 38 pts • Added mid-sprint: +9 pts • Removed mid-sprint: −6 pts • Net change: +3 pts (scope grew) • Delivered: 38 pts = original 38, but we don't know which were from the originals vs. the added items
Scope change is not automatically bad, but it needs context: • Added because: urgent bug fix needed? Good reason. • Removed because: story was too large, blocked, or deprioritised?
Key vocabulary: • scope creep — unplanned work added mid-sprint, often without removing other items (negative connotation) • scope change — neutral term for any addition or removal of work • sprint health — overall quality of sprint execution (predictability, focus, delivery) • predictability — how consistently a team delivers what they commit to
Useful phrase: "We delivered 100% of our original commitment, but the scope shifted mid-sprint — we'll discuss that at retro to improve our planning."
Why option C is best: 1. Uses the rolling average (industry standard for sprint planning) 2. Rounds down — cautious, realistic 3. Flags the variance — the range 28–43 is 15 pts wide, which is significant
Variance analysis: • Sprints alternate between ~28 and ~40+ pts • This could indicate: holidays, on-call rotation, scope creep, or team composition changes • Identifying the cause of variance improves planning
Key vocabulary: • rolling average / rolling mean — average of the most recent N values, updated each sprint • velocity — story points delivered per sprint • variance / standard deviation — how spread out the values are • capacity — the team's available time/effort for a sprint (may differ from velocity if people are OOO) • safety margin — intentionally planning slightly less than capacity to handle uncertainty
Phrase to use: "Our rolling average is 35.6 — I'd suggest committing to 34–35 this sprint and reviewing why sprints 39 and 42 came in below average."
4 / 10
A sprint retrospective note reads:
"Burndown was flat for the first 6 days, then steep in the last 4."
What does this pattern most likely indicate?
Flat then steep burndown is a classic anti-pattern:
What "flat" means: Little or no work was marked complete during days 1–6. Possible causes: • Stories were in progress but not closed until "done" • Blockers (waiting for design, API, review, dependency) • Team was working but not breaking work into small enough increments • Work estimated as complete wasn't meeting the "Definition of Done"
What "steep" means: Many stories completed quickly in the final 4 days — a late rush to close tickets.
Why this is a problem: • Hides risk: stakeholders see "no progress" for most of the sprint • Stressful for the team • Doesn't give time to course-correct if something goes wrong
Key vocabulary: • flat burndown — remaining work isn't decreasing (no progress visible) • late-sprint crunch — rush of closures at sprint end • J-curve burndown — flat, then steep — looks like the letter J flipped • Definition of Done (DoD) — agreed criteria a story must meet before it's "complete" • blocker — something preventing a story from progressing • anti-pattern — a common bad practice that looks reasonable but causes problems
5 / 10
An engineering manager presents this quarterly summary:
Q3 sprint summary (6 sprints) Average velocity: 37.3 pts Average completion rate: 89% Scope change rate: 22% of stories added after sprint start Rollover rate: 15% of stories carried to next sprint
How would you describe Q3 performance in one clear sentence?
Option C is the most balanced and precise description.
Reading the metrics: • 89% completion rate — strong; industry benchmark for healthy teams is often 80–90% • 37.3 pts velocity — useful for future sprint planning • 22% scope change — relatively high; more than 1 in 5 stories was added after sprint start • 15% rollover — 1 in 7 stories carries to the next sprint unfinished
The key insight: 89% completion sounds great, but the scope change rate (22%) partly explains it — if stories are added AND removed mid-sprint, the "committed" scope isn't stable. True planning accuracy = how often original commitments are met exactly.
Key vocabulary: • completion rate — % of sprint-committed stories delivered by end of sprint • scope change rate — % of stories modified (added/removed) after sprint planning • rollover rate — % of stories that weren't finished and moved to the next sprint • planning accuracy — how reliably a team delivers its initial commitments without changes • benchmark — a reference value used to compare performance
Useful framing phrase: "The numbers look solid overall, but the scope change and rollover rates are worth a closer look in the Q4 planning session."
6 / 10
Code Review Comment: 'The burndown chart shows a significant drop at the end. It looks like we over-estimated our capacity for this sprint.' What does this comment primarily highlight?
This comment isn't simply stating a fact about the chart; it's raising a concern. The phrase 'significant drop' suggests a potential problem with estimating capacity and delivering on commitments. A good developer should flag this for discussion.
7 / 10
Slack Message from Sarah (Lead Developer): 'Hey team, burndown's looking pretty flat today. We're on track to deliver everything planned for this sprint.' What is the *primary* implication of a 'flat' burndown in this context?
A flat burndown indicates that the team is consistently completing work at the same rate as planned. It's a positive sign *if* they remain on track to deliver their committed points. While it doesn't guarantee success, it suggests good execution and no major deviations.
8 / 10
PR Description: 'Updating the burndown chart to reflect the completion of Feature X. We're currently at 75% of our planned points for this sprint.' What does '75%' in this description *specifically* represent?
The phrase '75%' is referring to the *relative* progress. It indicates that 75% of the initially planned points have been completed, while 25% remains. Understanding this proportion is crucial when assessing sprint health.
9 / 10
Standup Update from David (Developer): 'Yesterday's burndown was really steep – we finished almost all of our planned tasks. We're looking at a small buffer now.' What does 'steep' refer to in this context?
'Steep' is a technical term used to describe a rapidly increasing slope on a burndown chart. This indicates that the team was completing work much faster than initially anticipated – likely due to an initial overestimation of effort or a change in priorities.
10 / 10
API Response (Partial): `{"sprint": "Sprint 45", "burndown": {"total_points": 65, "remaining": 15}, "velocity": 32}`. The 'remaining' value (15) represents which of the following?
The 'remaining' value in an API response for a burndown chart indicates the *quantity* of story points yet to be completed. It's a straightforward measure of the work still outstanding at that point in the sprint.
What will I practise in "Reading Sprint Burndowns"?
This module focuses on Numbers, Data & Metrics — real workplace phrasing you'll use on the job. It contains 10 scenario-based multiple-choice questions with instant feedback.
Is this exercise free to use?
Yes. Every exercise on CoderSlingo, including this one, is free to use with no account or sign-up required.
How many questions does this exercise have?
This module includes 10 questions. Each one gives an immediate right/wrong result plus a full explanation of the correct phrasing.
What happens if I answer a question incorrectly?
You'll see the correct answer highlighted straight away, along with a plain-English explanation of why it's right and why the other options don't fit — mistakes are part of the learning here.
Can I retry the exercise if I want a better score?
Yes — use the 'Try again' button on the results screen to reset your score and go through the questions again. There's no limit on attempts.
Who is this Numbers, Data & Metrics exercise for?
It's aimed at IT professionals with working English who want to sound more natural and precise around numbers, data & metrics — useful whether you're preparing for real conversations at work or just building confidence with the vocabulary.
Do I need an account to track my progress?
No account is needed. Your progress through the exercise is tracked locally in your browser for the current session, and you can replay the module at any time.
How is this different from reading a blog article?
This exercise is an interactive drill that tests and reinforces specific phrasing through multiple-choice questions with instant feedback, while blog articles explain concepts and vocabulary in prose. The two work well together.
Where can I find more Numbers, Data & Metrics exercises?
See the Numbers, Data & Metrics hub for more modules like this one, or browse the full Exercises page for other IT-English topics.
Can I complete this exercise on my phone?
Yes — every exercise on CoderSlingo is fully responsive and works on phones and tablets, so you can practise anywhere.