B. Software Development · Software Development: Managing a Team Software ProjectKeeping a Project on Track: Progress, Burndown, Earned Value and Change Control
B1.2 B1.4About 75 minutes
Learning goals- I can explain the trade-off between scope, time, cost and quality, and use it to make decisions.
- I can track progress against a baseline with a burndown chart and forecast whether a sprint will finish.
- I can calculate and interpret schedule and cost performance indexes (SPI and CPI).
- I can run a change request through change control: logging, impact analysis, decision and updating the plan.
- I can write a status report that compares actual progress with the plan and states decisions and next steps.
Words to know
baseline
The approved plan (scope, schedule and estimates) that actual progress is measured against.
project triangle (triple constraint)
The idea that scope, time and cost are linked: changing one forces a change in another, or quality suffers.
burndown chart
A graph of the work remaining (for example in hours) at the end of each day of a sprint, compared with an ideal straight line to zero.
velocity (burn rate)
How much planned work the team actually completes per day or per sprint.
earned value (EV)
The planned hours of the work that has actually been finished; compared with planned value (PV) and actual cost (AC).
SPI and CPI
Schedule performance index = EV ÷ PV; cost performance index = EV ÷ AC. Values below 1 mean behind schedule or over budget.
change request
A written request to change the agreed scope, schedule or requirements, decided through the change-control process.
gold plating
A team adding features nobody asked for. Like scope creep, it uses time the plan does not have.
Plans meet reality
By week 3, LendIt's plan met real life. Jordan was sick for two days. The search feature was bigger than expected. Denise asked for skate sizes. Each event is small, but together they can sink a project if nobody notices until the last week.
B1.2 asks you to develop the software according to the project plan, making sure it meets user needs, works as intended, and fits quality standards, budget and timelines. B1.4 asks you to use project management tools to manage the project's components. This lesson is about controlling a project while it runs: measuring progress against the plan, forecasting, and handling change on purpose instead of by accident.
The project triangle
Every project balances three linked constraints: scope (what is built), time (when it is done) and cost (for a student team, mostly hours of work; for a company, also money). Quality sits in the middle. If one side changes, another must change too:
- More scope with the same time and hours? Something must give, and if nothing is chosen, quality gives: less testing, more bugs.
- Less time? Cut scope or add hours.
In a school project the deadline is usually fixed and the hours are limited, so scope is what flexes. That is why MoSCoW priorities matter: when trouble comes, the Coulds go first, then the Shoulds, and the Musts are protected.
Measuring progress with a burndown chart
"I'm about 80% done" is the least reliable sentence in software. Measure instead. At the start of a sprint, add up the estimated hours of every task in it. At the end of each day, add up the estimated hours still left, re-estimating unfinished tasks honestly. Plot it: that is a burndown chart. A straight line from the total down to zero on the last day is the ideal. Points above it mean you are behind.
LendIt's sprint 2 has 60 hours of planned work over 10 school days, so the ideal burn is 6 hours a day.
A short program does the same analysis. It compares each day with the ideal line, finds the average burn rate so far, and forecasts how many days the remaining work needs.
planned = 60 # hours of work in sprint 2
days = 10
remaining = [60, 54, 49, 46, 43, 40, 36, 32] # hours left at the end of days 0 to 7
for day, left in enumerate(remaining):
ideal = planned - planned * day / days
status = "behind" if left > ideal else "on track"
print(f"Day {day}: {left:2} h left, ideal {ideal:4.1f} {status}")
today = len(remaining) - 1
rate = (remaining[0] - remaining[-1]) / today
needed = remaining[-1] / rate
print(f"Average burn {rate:.1f} h/day; {needed:.1f} more days needed, {days - today} left")
Output: day 0 and day 1 are on track; days 2 to 7 are behind (on day 7: 32 h left against an ideal of 18.0). The last line reads Average burn 4.0 h/day; 8.0 more days needed, 3 left.
Worked exampleExample 1: Acting on the forecast
On day 7 of sprint 2, 32 hours of work remain, the team burns about 4 hours a day, and 3 days are left. What are the options, and what does the team choose?
- At 4 h/day, 3 days complete about 12 hours, leaving about 32 − 12 = 20 hours undone.
- Option A: cut scope from this sprint. The search feature R6 (a Should, about 9 hours left) moves to sprint 3, and the 3-item limit R7 (also a Should, about 6 hours) could follow if needed.
- Option B: add hours. The team can add about 4 extra hours (two lunch periods), not 20.
- Option C: cut quality (skip the integration tests). Rejected: it breaks the definition of done and risks Must requirements.
- Decision at stand-up: move R6 (9 h) to sprint 3 and add 4 extra hours; remaining gap ≈ 20 − 9 − 4 = 7 hours, absorbed by moving R7's tests to the start of sprint 3. Priya updates the plan and tells Denise in the status report.
Scope flexes (Shoulds move to the next sprint), a little time is added, quality is protected, and the client is told. Nothing is hidden.
Earned value: are we behind, and are we over budget?
Burndown works inside a sprint. For the whole project, professional teams use earned value. Three numbers, all in hours for a student team:
- PV (planned value): the planned hours of all the work that should be finished by today, according to the baseline.
- EV (earned value): the planned hours of the work that is finished. (A task estimated at 8 hours earns 8 hours when it is done, however long it really took.)
- AC (actual cost): the hours actually spent so far.
Then SPI = EV ÷ PV tells you about schedule (below 1: behind), and CPI = EV ÷ AC tells you about cost (below 1: each hour of planned work is costing more than an hour). If the trend continues, the whole project will cost about BAC ÷ CPI hours, where BAC (budget at completion) is the total planned hours.
bac = 110 # budget at completion: total planned hours
pv = 66 # planned value: hours of work that should be done by now
ev = 54 # earned value: planned hours of the work actually finished
ac = 72 # actual cost: hours actually spent so far
spi = ev / pv
cpi = ev / ac
print(f"SPI = {spi:.2f} ({'behind' if spi < 1 else 'on or ahead of'} schedule)")
print(f"CPI = {cpi:.2f} ({'over' if cpi < 1 else 'within'} budget)")
print(f"Forecast total hours: {bac / cpi:.0f}")
Output: SPI = 0.82 (behind schedule), CPI = 0.75 (over budget) and Forecast total hours: 147.
Worked exampleExample 2: Interpreting earned value
At the end of week 3, LendIt's numbers are BAC = 110 h, PV = 66 h, EV = 54 h, AC = 72 h. Interpret SPI, CPI and the forecast. Is the project in trouble?
- SPI = 54 ÷ 66 ≈ 0.82: the team has finished about 82% of the work it planned to finish by now.
- CPI = 54 ÷ 72 = 0.75: every planned hour of work is taking about 72 ÷ 54 ≈ 1.33 real hours.
- Forecast: 110 ÷ 0.75 ≈ 147 hours in total, 37 more than planned.
- Hours still needed ≈ 147 − 72 = 75. At 20 team-hours a week, that is about 3.75 weeks. Weeks 4, 5 and 6 give 60 hours, so the team is roughly 15 hours short.
- Response: the plan has slack in scope, not in time. Moving R6 and R7 (about 15 hours together) to a version 1.1 closes the gap if nothing else goes wrong. Priya raises it with Denise now, in week 3, not in week 6.
Behind schedule and over budget, but discovered early enough to fix by adjusting scope. The numbers turn "I think we're a bit behind" into a specific gap and a specific decision.
Change control
Clients change their minds; that is normal and often good. The danger is change that happens without a decision: a feature slipped in at a meeting (scope creep), or a developer adding something nobody asked for because it seemed cool (gold plating). Both spend hours the plan does not have.
Change control handles every change the same way:
- Request in writing and log it (ID, who, what, why).
- Analyse the impact: which requirements, modules, tests and documents change; how many hours; what risks; what it does to the schedule.
- Decide: the client and PM approve, reject, or defer it to a later version. If approved, decide what gives (time, hours or other scope).
- Update the scope document, requirements, plan and baseline.
- Tell the whole team.
| Field | CR-02: skate sizes |
|---|
| Requested by / date | Denise Tremblay, Monday, November 16, 2026 |
| Change | Record a size for each pair of skates and search for skates by size |
| Reason | Volunteers spend time checking sizes on the shelf |
| Affected | Data design (items.csv gets a size column), items.py, storage.py, main.py menu, 6 new tests, user guide |
| Estimate | O = 5 h, M = 7 h, P = 15 h, so PERT E = (5 + 28 + 15) ÷ 6 = 8 h |
| Schedule and risk | 8 h ≈ 0.4 team-weeks; the project is already about 15 h short; changes a file format (risk to existing data) |
| Options | Add now and drop R6 search; defer to version 1.1; reject |
| Decision | Defer to version 1.1 (Denise, Nov 18). Logged in the change log; scope document unchanged. |
Model: a status report with numbers
Status report 4: LendIt · Week 3, Friday, November 20, 2026 · Overall: at risk (was on track)
Milestones: Design approved (Tuesday, Nov 10) ✓ on time. Next: code complete. Baseline Wednesday, November 18 (missed); forecast Wednesday, November 25.
Progress against the baseline: SPI 0.82, CPI 0.75 (see the numbers below). Items module (E) done and reviewed. Storage (G) done; bug B-07 found by integration tests and fixed. Loans module (F) 70% done (nearly critical: its 1 day of slack is used up).
Issues: Jordan was away Tuesday and Wednesday (risk K1 occurred). The search feature turned out larger than estimated.
Change requests: CR-02 (skate sizes) analysed; Denise chose to defer it to version 1.1.
Decisions and next steps: Move R6 (search, a Should) from sprint 2 to sprint 3. Luc pairs with Jordan on loans tests Monday and Tuesday. Re-forecast at Wednesday's stand-up. Buffer before the Friday, December 11 deadline: 11 working days in the baseline, now forecast 6.
Compare this with Grade 11 status reports. It still gives milestones, work done, issues and next steps, but now every claim is measured against the baseline (SPI, CPI, slack used, buffer left), and decisions on scope are recorded with the change log.
Just for funThe "ninety-ninety rule", credited to Tom Cargill of Bell Labs: "The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time." Burndown charts exist so that you discover this in week 3, not week 6.
Hands-on activityProject step 10: Track your project
You need: your baseline schedule and estimates, a spreadsheet or graph paper, and Python.
- Burndown: for your current sprint (or the next week), list the tasks and estimated hours. At the end of every work day, write the hours left (re-estimate honestly). Plot actual against ideal and run the burndown program with your numbers.
- Earned value: at the end of a week, work out PV, EV and AC in hours from your baseline and your time log. Calculate SPI, CPI and the forecast total. Write one sentence on what they mean.
- Change log: start
docs/change-log.md. If your client has asked for anything new, write it up as a change request with an impact analysis, and let the client decide. If not, write one for an idea of your own (yes, your own ideas need change control too: that is how gold plating is stopped). - Write a status report like Status report 4: overall status (on track, at risk, off track), milestones, progress with numbers, issues, change requests, decisions and next steps. Send it to your client or teacher.
What to look for: numbers instead of feelings; scope decisions made with the client; quality (testing) never quietly cut.
Your turn
1Name the three sides of the project triangle and what sits in the middle.
Scope, time, cost; quality in the middle.
2A sprint has 50 hours of work over 10 days. What is the ideal hours left at the end of day 4?
50 − 50 × 4 ÷ 10 = 50 − 20 = 30 hours.
3On day 4 the team has 34 hours left. Are they ahead or behind? By how much?
Behind by 34 − 30 = 4 hours of work.
4PV = 40 h, EV = 30 h, AC = 25 h. Find SPI and CPI and interpret them.
SPI = 30 ÷ 40 = 0.75: behind schedule. CPI = 30 ÷ 25 = 1.2: under budget (the finished work took fewer hours than planned). The team is efficient but has not been spending enough hours on the project.
5What is the difference between scope creep and gold plating?
Scope creep: features added at the request of the client or others without a decision to change the plan. Gold plating: the team adds features nobody asked for. Both use hours the plan does not have.
6List the five steps of change control.
Request (and log), analyse impact, decide, update the plan, tell the team.
7Why does "I'm 80% done" make a poor progress measure?
It is a guess, usually optimistic, and the last 20% is often the hardest. Hours of work remaining (re-estimated) or finished tasks (earned value) are measurable.
More practice: warm-up
1What does a burndown chart show?
The work remaining at the end of each day of a sprint, compared with an ideal line down to zero.
2What is the formula for SPI?
The work is costing exactly the planned hours.
4Who decides on a change request?
The client together with the project manager (after impact analysis).
5In a school project, which side of the triangle usually flexes?
Scope (the deadline and hours are fixed).
More practice: on your own
1A sprint: 40 hours over 8 days. Hours left at the end of days 0 to 4: 40, 36, 31, 27, 22. Find the average burn rate and forecast whether the sprint will finish.
Burned 40 − 22 = 18 hours in 4 days: 4.5 h/day. Remaining 22 h ÷ 4.5 ≈ 4.9 days, but only 8 − 4 = 4 days are left, so about 4 hours (22 − 4 × 4.5) will be unfinished unless scope or hours change.
2BAC = 80 h, EV = 30 h, AC = 40 h. Forecast the total hours and the extra hours compared with the plan.
CPI = 30 ÷ 40 = 0.75. Forecast = 80 ÷ 0.75 ≈ 106.7 h, about 27 hours more than planned.
3A task estimated at 6 hours took 9 hours and is finished. What does it add to EV and to AC?
EV +6 (its planned hours) and AC +9 (the hours actually spent). That is how CPI detects the overrun.
4Write the "Affected" and "Options" parts of an impact analysis for: "Add an email reminder to members two days before their due date."
Affected: requirements (new R10; members' email addresses conflict with privacy requirement N4); data design (members.csv gains an email column); a new reminder module; internet access (conflicts with N1, no internet); tests; user guide. Options: reject for version 1.0 because it conflicts with N1 and N4; defer to a later version with privacy consent and internet access; or a no-internet alternative: print a daily "due in 2 days" list for staff to phone members.
5Explain why cutting testing is a poor way to recover a late schedule.
It saves hours now but lowers quality: bugs reach the client, the acceptance test may fail, and fixing bugs late costs more than the hours saved. It also breaks the definition of done. Cutting scope (Coulds, then Shoulds) keeps what is delivered working.
Challenge
1Using the burndown program, what would it print as its last line if the remaining list were [60, 52, 45, 38, 31, 25, 19, 12]? Is the sprint on track?
Burn = (60 − 12) ÷ 7 ≈ 6.857, printed as 6.9 h/day; needed = 12 ÷ 6.857 = 1.75, printed as 1.8: Average burn 6.9 h/day; 1.8 more days needed, 3 left. Yes: the team is ahead of the ideal (day 7 ideal is 18.0, actual 12) and should finish early.
2An SPI of 1.1 and a CPI of 0.8. Describe a realistic situation that produces these numbers and what the PM should watch for.
The team is ahead of schedule (more work finished than planned by now) but spending more hours than estimated for it, for example by working extra evenings. It looks good now, but the pace may not be sustainable (burnout, other subjects suffering), and the forecast total hours (BAC ÷ 0.8) is 25% over plan. The PM should check whether estimates are too low and whether the extra hours can continue.
3Denise asks for CR-02 (skate sizes, 8 h) to be added now after all. The project is already about 15 hours short. Using the triangle, give a plan the team could propose and what each option costs.
Something must give. The team is already about 15 h short, so adding CR-02 (8 h) makes the gap about 23 h. (1) Swap scope: add CR-02 and defer both R6 search and R7 limit (about 15 h) to version 1.1; that still leaves about 8 h to find, so the team would also need extra hours or another deferral. (2) Add time: move delivery past December 11, which the client may not accept. (3) Add hours: only a few extra hours are realistic, nowhere near 23. A reasonable proposal: show Denise that skate sizes cost more than both Shoulds together; if she still wants them now, defer R6 and R7, add a few extra sessions, keep all Musts and full testing, and record the trade in the change log. Quality is not an option to cut.
Quiz
1. A sprint has 80 hours over 10 days. What is the ideal work left after day 5?
2. PV = 50 h and EV = 40 h. What is SPI, and what does it mean?
3. EV = 45 h and AC = 60 h. What is CPI?
4. A developer adds animated menus that no one requested. This is called:
5. The deadline is fixed and the team is behind. Which response best follows the project triangle and MoSCoW?
6. In change control, what comes right after logging a request?
Big idea: B1.2 asks students to keep development on plan, within quality standards, budget and timelines; B1.4 asks them to use project management tools. This lesson covers measuring progress against a baseline (burndown charts, earned value with SPI and CPI), the scope-time-cost trade-off, and change control.
How to help: If you are the client, ask for changes in writing, and expect your teen to come back with "Here's what it costs; which would you like to give up?" That is exactly the right professional response. Ask to see the burndown chart each week.
Common difficulties:
- Reporting feelings ("almost done") instead of measured hours.
- Accepting every request on the spot, then running out of time.
- Recovering a late schedule by cutting testing.
- Mixing up EV (planned hours of finished work) and AC (actual hours spent).