Intermediate Labs Answer Key — Labs 07–15¶
Instructor material — and not secret
Published in a public repository. Treat it as a self-study reference, not a secured key.
Labs 07–15 contain substantial arithmetic. Every calculation is worked below, with the assumption each one depends on. Where a judgement is required, the reasoning that must be present is stated instead of a single answer.
Lab 07 — Creating a Work Breakdown Structure¶
Basis of decomposition. The strongest answers choose by product component for this project, with reasons such as: the system is delivered as separable components; team members have component-level expertise; and estimation is more reliable at component level than at phase level for a system whose phases are still poorly understood. The rejected alternative (by phase) has the disadvantage that phase boundaries shift, forcing WBS revision; the rejected alternative (by location) has the disadvantage that it splits components across warehouses and duplicates the same work four times.
Model level-2 structure (any consistent, product-oriented variant is acceptable):
- Stock and location data (1.1 item and location register, 1.2 stock level service, 1.3 movement history)
- Goods-in and goods-out (2.1 purchase order receipt, 2.2 dispatch against customer order, 2.3 barcode scanning integration)
- Replenishment (3.1 reorder point calculation, 3.2 suggested replenishment list)
- Views and reporting (4.1 real-time stock view, 4.2 supervisor mobile stock count, 4.3 movement history view)
- Accounting interface (5.1 fixed-width export generation, 5.2 export scheduler, 5.3 reconciliation report)
- Migration and transition (6.1 spreadsheet data migration, 6.2 warehouse supervisor training, 6.3 parallel-run support)
100% rule — expected findings. Almost every honest check finds at least one of:
- A missing element for training and handover (present in the scope statement's deliverables, absent from the WBS).
- An overlap between "reporting" at level 2 and reports inside another component.
- An unlisted element for migration from the spreadsheets, which lives only in the exclusions of nothing and in nobody's plan.
- A parent whose children do not cover it — for example "views and reporting" containing no element for the daily summary the accounting system needs.
Model work packages (six required). A work package must have all six fields, and should fall roughly in the 2–10 person-day range. A work package outside that range is acceptable if justified — for example "spreadsheet data migration" may be 15 days because it cannot be subdivided before the data is profiled.
Awkward items.
- Accounting export: represent it as a work package with a dependent acceptance criterion: the export generates a file matching the documented format once the format is documented. State the risk (undocumented format, retiring maintainer) and the mitigation (produce a written format specification in week 2, with the maintainer, as the package's first task).
- Barcode devices: represent the integration work as a work package, and record the device arrival as an external dependency and a risk. The acceptance criterion can promise that scanning works on the documented device model, but must state that it is untested until devices arrive — and that manual entry remains available.
Common errors: verb-phrase names; mixing bases at level 2; a 100% check that finds nothing (usually means the check was superficial); work packages with no acceptance criteria; the migration work absent from the WBS.
Lab 08 — Building a Project Schedule¶
All arithmetic, with the assumption each part depends on.
Task 1 — total effort
12 + 8 + 12 + 10 + 16 + 12 + 14 + 3 + 15 + 10 = 112 person-days
Assumption: the security review costs 3 person-days of our own effort; the remaining 7 working days are the security office's time, not ours.
Task 2 — effort to duration
Paid person-days = effort ÷ productivity factor = 112 ÷ 0.8 = 140 person-days
Assumption: 80% of paid time is project work, so a quarter more paid time than effort is required.
Security review, stated separately:
| Quantity | Value |
|---|---|
| Our effort | 3 person-days |
| External lead time | 10 working days |
| Why they must not be mixed | Recording only the effort (3) would imply the review finishes in three days, understating the schedule by a week |
Task 3 — capacity
| Resource | Availability | Person-days/week | Over 78 working days |
|---|---|---|---|
| Developers (4) | 100% | 20.0 | 312.0 |
| Business analyst | 60% | 3.0 | 46.8 |
| Tester | 50% | 2.5 | 39.0 |
| Total | 25.5 | 397.8 |
Basis: 16 weeks × 5 days = 80 working days, less the two public holidays the scenario gives (20 March and 6 April) = 78 working days. Availability × 5 days per week × 78 ÷ 5 = availability × 78 person-days. A student who uses 80 days and ignores the holidays gets 408 person-days and 34%; that is the arithmetic of the scenario being read carelessly, and the self-check criterion "dates respect the working calendar" is what catches it.
Task 4 — demand versus capacity
- Nominal capacity: 397.8 person-days (paid time) over the 78 working days in the window.
- Demand: 140 person-days of paid time.
- Utilisation = 140 ÷ 397.8 ≈ 35%.
The project has ample capacity. A utilisation of 35% does not mean the team is idle: it means the project could absorb roughly three times this work within the window, so capacity is not what limits the schedule. Something else is.
Task 5 — the real constraint
| Bound | Calculation | Result |
|---|---|---|
| Serial (one person, all work) | 140 ÷ 5 person-days per week | 28 weeks |
| Theoretical parallel (all work at once, capacity permitting) | 140 ÷ 25.5 | ≈ 5.5 weeks |
| Actual | Dependency-constrained | between the two, nearer neither |
The project is dependency-constrained. Three pairs that cannot run in parallel:
- Requirements workshops then data model design — the data model needs agreed requirements.
- Data model design then every build activity — form, upload, rules engine, and integration all consume the model.
- Integration then security review — the review inspects a completed integration.
- (Also acceptable) System testing then UAT — UAT exercises a tested system.
Task 6 — calendar
- 16 weeks from Monday 2 March 2026 is Monday 22 June 2026, so the last working day of the window is Friday 19 June 2026.
- 10 working days of security queue booked from 2 March 2026: 2–6 March (5), 9–13 March (10) — the queue completes Friday 13 March 2026; the review itself then requires its own execution time.
- Implication: if the review's queue is to be absorbed without delaying the build, integration must be complete and ready for review roughly two weeks before testing is scheduled to begin.
Task 7 — milestones. Any six are acceptable provided each has evidence: for example "data model approved (signed review record)", "form completes an application end to end (demonstration)", "security review passed (written approval)", "system testing complete (test summary with pass rate)", "UAT completed by a real applicant (recorded session)", "handover accepted by IT operations (operations team confirms they can run a change unaided)".
Common errors: multiplying by 0.8 instead of dividing; comparing effort demand with total capacity without applying the productivity factor to one side; treating the security queue as three days; forgetting the public holidays when computing the window end.
Lab 09 — Identifying Dependencies¶
Dependency table (model answer):
| Activity | Predecessors | Class | Justification |
|---|---|---|---|
| A Requirements workshops | — | — | |
| B Data model design | A | Mandatory | The model needs agreed requirements |
| C Applicant form build | B | Mandatory | The form consumes the model |
| D Document upload build | B | Mandatory | Uploads reference the model |
| E Eligibility rules engine | B | Discretionary | It could follow C, but running it in parallel shortens the build at the cost of coordinating three workstreams |
| F Admin review console | C | Discretionary | The console reuses form components — a convenience decision, not a technical necessity |
| G Student-record integration | D | Mandatory | Uploaded documents are referenced by the integration |
| H Security review | G | External | Performed by the IT security office; the lead time is outside the project's control |
| I System testing | E, F, H | Mandatory | Cannot test components or an unapproved integration |
| J UAT and training | I, and the academic calendar window | Mandatory + external | The window is fixed by the university |
Discretionary dependencies (Task 2).
| Dependency | What it buys | Risk it introduces |
|---|---|---|
| E after B, in parallel with C and D | Shorter build; the rules engine is the longest single activity | Three workstreams coordinating against one evolving model |
| F after C | Reuse of the form's components; less duplicated UI work | Integration rework if the console's needs force form changes |
Removing either shortens the schedule only if the released activity actually lies on the critical path — which is Lab 10's analysis.
External dependencies (Task 3). The security office (H) and the university's academic calendar window (J). For H: the project must supply a completed integration and a description of what to review; the office supplies a written approval; the lead time is 10 working days; the action to take now is to book the queue in advance, agreeing a provisional date. For J: the project supplies a working system and training; the university supplies the window; the action now is to confirm the window in writing and to record it as a constraint on the schedule.
Task 4 — network. Ten nodes (plus the migration activity added in Task 5), and one arrow per dependency in the table. The three checks should reconcile exactly; a common discrepancy is a missing arrow from B to E.
Task 5 — the missing work. The migration activity should be given: a duration estimate (a defensible range is 4–8 working days, justified from the four warehouses and the data-quality assumption), a predecessor of B (the model must exist) and a successor of G or of I (migrated data must be present for integration testing). What would otherwise be discovered late: that the migration is on the critical path and that it depends on data that has not been profiled, at a point where there is no time to profile it.
Task 6 — the security assumption. If the assumption holds, H starts when G completes. If it is false, H is queued after other work, and since H is on the critical path the entire project slips by the queue length. The email must name the deliverable the office will receive, the date it will arrive, and the date approval is needed — a booking, not a notification. The assumption belongs in the risk register and the assumptions log, not on the diagram.
Common errors: listing dependencies without classifying them; calling the security review an internal dependency; missing the migration work; a diagram with nodes but no arrows from B to E; treating the academic calendar as a preference rather than an external constraint.
Lab 10 — Gantt Chart with the Critical Path¶
Task 1 — forward pass
| Activity | Duration | ES | EF |
|---|---|---|---|
| A | 5 | 0 | 5 |
| B | 4 | 5 | 9 |
| C | 6 | 9 | 15 |
| D | 5 | 9 | 14 |
| E | 8 | 9 | 17 |
| F | 6 | 15 | 21 |
| G | 7 | 14 | 21 |
| H | 10 | 21 | 31 |
| I | 5 | 31 | 36 |
| J | 4 | 36 | 40 |
Project duration: 40 working days.
Task 2 — backward pass and float
| Activity | EF | LF | LS | Total float |
|---|---|---|---|---|
| A | 5 | 5 | 0 | 0 |
| B | 9 | 9 | 5 | 0 |
| C | 15 | 25 | 19 | 10 |
| D | 14 | 14 | 9 | 0 |
| E | 17 | 31 | 23 | 14 |
| F | 21 | 31 | 25 | 10 |
| G | 21 | 21 | 14 | 0 |
| H | 31 | 31 | 21 | 0 |
| I | 36 | 36 | 31 | 0 |
| J | 40 | 40 | 36 | 0 |
Task 3 — critical path: A → B → D → G → H → I → J (5 + 4 + 5 + 7 + 10 + 5 + 4 = 40).
The candidates that do not qualify are C → F (15 + 6 = 21, well short of the 31 days reached through D → G) and E (finishes at 17 against 31 for the parallel integration chain). Neither is on the path despite C and E both being large activities — the path is a property of sequence, not of size.
Task 4 — float interpretation.
- C: 10 days. Spending it means allowing the form to finish up to 10 days later. If spent, F's start slips with it, but F has 10 days of its own — the float on this chain is shared, not per-activity.
- E: 14 days. The rules engine can slip two weeks without affecting testing. Spending it means losing the project's main buffer against requirements discovery.
- F: 10 days. Shared with C.
Float belongs to the chain, not to a person or a task. Two activities on the same chain drawing on the same reserve will consume it twice over.
Task 5 — Gantt chart. A correct chart marks A, B, D, G, H, I, J with crit and C, E, F without.
What it hides, drawn honestly:
- the reason C follows B rather than running in parallel (a discretionary choice);
- which chain is critical, unless it is tagged;
- resource contention (Bilal, Chen, and the analyst are all assumed available);
- that H is an external activity whose ten days are mostly someone else's queue.
Task 6 — dates.
- 40 working days from Monday 2 March 2026, excluding 20 March and 6 April: the 38th working day is Friday 24 April, so the 39th is Monday 27 April and the 40th is Tuesday 28 April 2026.
- The window ends Friday 19 June 2026. From 28 April to 19 June is approximately 38 working days of margin (38 working days: 29 April–19 June inclusive of weekends excluded). Accept 34–38 depending on holiday treatment; the reasoning matters more than the exact figure. (Holidays already outside the 40-day count are not counted twice.)
- The margin is not spare time: the data-migration work package is not in this network; the stakeholder confirmation of complaint categories is outstanding; and the security queue could lengthen.
- G must finish by the date on which H's ten days must start for testing to begin on schedule — if testing is to start on day 31, G must complete by day 21, which is Tuesday 31 March 2026 (2 March plus 21 working days, less the 20 March public holiday). An answer of Monday 30 March means the holiday was left in the count: mark the reasoning, and correct the date.
Common errors: taking the sum of all predecessors rather than the maximum at I; starting the backward pass from a duration other than 40; treating C and E as critical because they look large; counting calendar days instead of working days.
Lab 11 — Developing a Risk Register¶
Exposure table (probability × impact):
| Rank | Risk | Calculation | Exposure |
|---|---|---|---|
| 1 | R8 Scope growth | 0.65 × 320,000 | 208,000 |
| 2 | R4 Undocumented rules | 0.60 × 300,000 | 180,000 |
| 3= | R1 Interface specification changes | 0.40 × 350,000 | 140,000 |
| 3= | R2 Clinic staff availability | 0.70 × 200,000 | 140,000 |
| 5 | R3 Hosting approval delayed | 0.25 × 400,000 | 100,000 |
| 6 | R6 Accessibility failure | 0.45 × 180,000 | 81,000 |
| 7 | R5 Key-person dependency | 0.30 × 250,000 | 75,000 |
| 8 | R7 Messaging outage at launch | 0.20 × 220,000 | 44,000 |
| Total | 968,000 |
Ranking override (Task 3): R3. Exposure 100,000 ranks it fifth, but its occurrence blocks launch entirely — the hospital cannot go live without hosting approval, and no amount of effort recovers it. Expected-value ranking treats all outcomes as recoverable, which is precisely wrong for an absolute blocker. The general rule: where a risk has an irreversible or absolute-impact outcome, rank it by impact first and probability second.
Responses (model).
| Risk | Strategy | Response | Owner | Trigger |
|---|---|---|---|---|
| R1 | Mitigate | Thin interface prototype in week 2; a named contact at the third party | Tech lead | Spec change request received from the third party |
| R2 | Mitigate | Review slots booked a month ahead; a deputy from the clinic | Project manager | Review attendance below half for two consecutive sessions |
| R3 | Avoid (early) | Submit the hosting approval package in week 1 | Project manager | Approval not granted by week 8 |
| R4 | Mitigate | Rules-discovery workshops with two clinic staff | Analyst | Fewer than five rules confirmed per workshop |
| R5 | Transfer (knowledge) | Pair the specialist; document the setup | Tech lead | Any unplanned absence |
| R6 | Mitigate | Accessibility testing from week 4, not at the end | Tester | Any failing automated accessibility check |
| R7 | Accept + transfer | Written availability commitment; manual reminder fallback | Project manager | Vendor status page shows degradation |
| R8 | Mitigate | Change control with published tolerance; monthly scope review | Project manager | More than two change requests in a month |
Secondary risks (at least two).
- Pairing for R5 costs the specialist's own delivery time and may slow reporting work.
- The hosting approval submission in week 1 may be rejected on incomplete information, delaying rather than accelerating it.
- Accessibility testing from week 4 may generate rework inside the build window.
Residual exposure. Accept any defensible residual estimates, provided the arithmetic is shown and the total is lower than 968,000. A common strong answer reduces the total by 40–60%, with R3's residual unchanged because it is externally owned — residue that cannot be planned away.
Common errors: exposure not calculated or not ranked; owners given as "the team"; triggers that cannot be observed; R3 ranked first by exposure without the irreversibility argument; no accepted risk at all.
Lab 12 — Preparing a Communication Plan¶
Communication cost per week
| Practice | Working | Hours/week |
|---|---|---|
| Weekly status note | 1 h writing + (12 × 10 min = 2 h) reading | 3.00 |
| Steering committee | (6 × 1.5 h) + 1 h prep = 10 h per fortnight → ÷ 2 | 5.00 |
| Department briefing | 1 h prep + (8 × 0.5 h = 4 h) = 5 h per month → ÷ 4.33 | 1.15 |
| Daily team check-in | 9 × 15 min = 2.25 h/day × 5 | 11.25 |
| Total | ≈ 20.4 |
As a fraction of an FTE: 20.4 ÷ 40 = 0.51 FTE — about half of one person's working week.
- The largest line is the daily verbal check-in (11.25 h/week), which is also the practice most obviously replaceable by the written update the team already needs.
- The cost is mostly invisible to the people paying it, because it is spread across nine calendars rather than appearing on one budget line. That is exactly why it needs stating.
Pruning (Task 4). The evidence points to the monthly department briefing: no decision, change, or action in three months. A strong answer either stops it or redesigns it into a 15-minute slot inside an existing meeting, and states what people should do if they still want the information (a written page, updated monthly, that they can pull). Stopping silently is the error being tested: silence is read as a problem.
Decision speed (Task 5). The appointment-rule change and the security submission both need decisions faster than a fortnightly cycle. Accept any mechanism with a named authority and a written record — for example a standing delegation to the project manager up to a stated size, with ratification at the next committee, plus a written submission channel for the approval queue with a tracked due date. The key sentence: a cadence slower than the decision speed turns the plan into a record of delays.
Status report (Task 6). Must contain: the fact (submission lodged 4 weeks ago; the queue is 2 months; review not begun), the assessment (a schedule effect with a number — for example "integration testing cannot start before week 9, moving the integration milestone by up to 12 days"), and the request (a decision or action with a deadline). A report with no number in the assessment fails the criterion.
Common errors: merging decision-makers and workflow-changers into one audience; writing time counted but reading time ignored; no pruning decision; a status report that softens the assessment.
Lab 13 — Estimating Effort and Cost¶
Task 1 — paid person-days
67 ÷ 0.8 = 83.75 paid person-days (about 84).
The difference (16.75 days) is time that is paid for but not available for project work — for a part-time team member this is a meaningful fraction of every working week.
Task 2 — labour
- 83.75 × 25,000 = PKR 2,093,750
- Rounded to 84 days: 84 × 25,000 = PKR 2,100,000
Either is acceptable provided the rounding choice is stated and applied consistently through the rest of the budget.
Task 3 — cost table
| Component | Basis | Amount |
|---|---|---|
| Labour | 83.75 paid days × 25,000 | 2,093,750 |
| Hosting | 3 months of build-period hosting | 60,000 |
| Tooling and licences | One-off | 40,000 |
| Subtotal | 2,193,750 |
Excluded: post-launch hosting, which the department funds from operating budget. It matters to the head of department because the project's apparent cost is lower than the lifetime cost of owning the system — the decision is between an LMS and spreadsheets, and spreadsheets have no licence.
Task 4 — contingency from risks
| Risk | Calculation | Exposure |
|---|---|---|
| R1 File storage limit | 0.40 × 200,000 | 80,000 |
| R2 Accessibility failures | 0.50 × 120,000 | 60,000 |
| R3 Notification sandbox | 0.30 × 150,000 | 45,000 |
| R4 Tester availability | 0.60 × 100,000 | 60,000 |
| R5 Hosting approval delay | 0.20 × 250,000 | 50,000 |
| Contingency | 295,000 |
The two dominant risks are R1 (80,000) and then R2 and R4 (60,000 each). R2 is a preventable risk: running accessibility checks during design rather than after build would reduce both its probability and its impact — which is where prevention effort should go first. R4 is a staffing risk with a cheap response (book review time in advance).
The figure is a contingency because it is auditable: every amount traces to a named risk with a probability and an impact, and any reviewer can challenge it line by line. A percentage cannot be challenged at all. As a proportion of labour it happens to be about 14%, but the percentage is an output.
Task 5 — three-point estimate
(10 + 4 × 14 + 26) ÷ 6 = (10 + 56 + 26) ÷ 6 = 92 ÷ 6 = 15.33 person-days
- About 1.3 days above the 14-day figure — roughly 9%.
- The difference should not simply be added to the total. The right response is to resolve the uncertainty: the pessimistic case exists because a requirement might exist (per-lecturer weighting schemes), so the action is to confirm whether it is required. If it is, the estimate becomes ~26 and the plan changes; if it is not, the estimate is ~14 and the range narrows.
- The person who can reduce it is the head of department, by deciding whether per-lecturer weighting is required in phase 1.
Task 6 — management reserve and total
- Management reserve = 10% × 2,193,750 = PKR 219,375 (or 220,000 with the rounded subtotal).
- Total = 2,193,750 + 295,000 + 219,375 = PKR 2,708,125 (or 2,715,000 with rounding).
- The contingency is controlled by the project manager, because it responds to identified risks the project can act on. The management reserve is controlled by the department, because it exists for work nobody identified — usually scope changes — which is a decision above the project's authority.
Task 7 — range
| Scenario | Basis | Amount |
|---|---|---|
| Low | No risk materialises; gradebook stays at 14 days | ≈ 2,193,750 + 219,375 = 2,413,125 |
| Expected | Contingency at expected exposure | ≈ 2,708,125 |
| High | R1 and R5 materialise at full impact | ≈ 2,708,125 + (200,000 + 250,000) = 3,158,125 |
Common errors: multiplying by 0.8; choosing a round contingency percentage; adding the three-point difference to the total without resolving it; no exclusions stated; contingency and management reserve combined into one reserve.
Lab 14 — Creating a Scrum Product Backlog¶
Task 1. Total = 5 + 8 + 3 + 5 + 8 + 5 + 8 + 13 + 13 + 13 + 3 + 8 + 8 = 100 points.
A story point is a relative unit of effort, complexity, and risk as judged by this team. It is not a number of hours, it is not comparable with another team's points, and it must not be converted into time for reporting.
Task 2 — capacity
| Item | Calculation | Points |
|---|---|---|
| Nominal | 18 × 4 sprints | 72 |
| Absence (one developer of five, one sprint) | 18 × 0.2 for one sprint, ≈ 3.6 | −4 |
| Available | ≈ 68 |
Non-project time is already inside the measured velocity of 18 — velocity is measured, not calculated — so applying 20% again would double-count it. A student who instead builds capacity from scratch (5 people × 10 days × 0.8 = 40 person-days per sprint) must say so and must not also use 18 points per sprint.
This is a forecast: it is invalidated if the leave is longer, if a second absence occurs, if a dependency blocks work mid-sprint, or if the team's composition changes.
Task 3 — model ordering (dependency-legal, value-led, with B5 pulled forward for its dependents):
- B3 Payment retry (3, value 5) — high value, no dependency, and it protects revenue
- B1 Cart persistence (5, value 4) — gates guest checkout
- B2 Guest checkout (8, value 5) — the owner's stated priority
- B12 Order tracking (8, value 5) — highest customer demand, no dependency
- B11 Address book (3, value 2) — small, unblocks nothing, but cheap and improves checkout
- B5 Product reviews (8, value 4) — pulled forward specifically because it gates 18 further points
- B13 Returns flow (8, value 3) — depends on B12, which is already in
- B6 Review moderation (5, value 3) — depends on B5
- B7 Search filters (8, value 3)
- B9 Loyalty points (13, value 3) — depends on B2
- B4 Wishlist (5, value 2)
- B8 Recommendation strip (13, value 2) — depends on B5, poor value per point
- B10 Gift cards (13, value 2) — depends on B2, largest item for the lowest value
The deliberately deferred high-value item is a defensible choice; the best answers defer B10 (high dependency, low value, large) or B9, and explain that a 13-point item consumes almost a whole sprint's capacity for a value rating of 2–3.
Task 4 — release contents. A model selection within about 68 points:
B3 (3) + B1 (5) + B2 (8) + B12 (8) + B11 (3) + B5 (8) + B13 (8) + B6 (5) + B7 (8) + B4 (5) + (one of B9 or B8, 13) = 74 — too large. Removing the 13-point item gives 61 points, leaving ~7 points of buffer for the realistic overrun.
Value delivered by that selection (B3 5, B1 4, B2 5, B12 5, B11 2, B5 4, B13 3, B6 3, B7 3, B4 2) = 36 of the 43 total value units across all thirteen items. So the selection delivers 36 of 43 = 84% of value for 61% of the points. That asymmetry is the point of the exercise: value is not proportional to size.
The whole-backlog value total: B1 4 + B2 5 + B3 5 + B4 2 + B5 4 + B6 3 + B7 3 + B8 2 + B9 3 + B10 2 + B11 2 + B12 5 + B13 3 = 43.
Task 5 — cascade. B5 + B6 + B8 = 8 + 5 + 13 = 26 points, combined value 4 + 3 + 2 = 9. Including the cascade costs 26 points for 9 value units; deferring it defers three items at once. The strongest answers either include B5 and B6 only (13 points, value 7) and defer B8, or defer the whole cascade and state the consequence explicitly.
Task 6 — definition of ready. Accept any six checkable conditions: value stated; dependencies identified and satisfied; acceptance criteria written; sized by the team; user-interface design available where needed; testable in the environment; small enough to finish within a sprint.
Task 7 — the finance manager. Converting points to hours permanently destroys the relativism that makes them useful and invites the team to inflate. What Finance actually needs is a cost forecast, which can be produced from the measured velocity and a blended rate, presented as a range, without touching the backlog's unit.
Common errors: applying the 20% twice; a value-maximising selection that ignores dependencies; converting points to hours; a definition of ready that cannot be judged.
Lab 15 — Running Sprint Planning¶
Task 2 — capacity
| Resource | Days | At 80% |
|---|---|---|
| Developer 1 | 10 | 8.0 |
| Developer 2 | 10 | 8.0 |
| Developer 3 | 10 | 8.0 |
| Tester | 10 | 8.0 |
| Designer | 6 (4 committed elsewhere) | 4.8 |
| Total | 46 | 36.8 person-days |
- Sprint demand: 19 points × ≈ 2.1 person-days per point ≈ 40 person-days (equivalently, 19 points historically took about 40 person-days).
- The sprint does not fit. The shortfall is about 3 person-days, or roughly 1.5 points.
- The honest commitment is nearer 17 points: the team should remove B11 (3 points) or split it, and state that the goal is adjusted accordingly.
Task 3 — model task breakdown (extract). Every task must be one day or smaller and assigned to one person:
| Item | Task | Owner | Days |
|---|---|---|---|
| B1 | Design the cart persistence data shape | Designer | 0.5 |
| B1 | Implement cart persistence server-side | Dev | 1.0 |
| B1 | Wire the cart into the session and expiry rules | Dev | 1.0 |
| B1 | Unit and integration tests for cart persistence | Tester | 0.5 |
| B3 | Define retry policy and failure states | Designer | 0.5 |
| B3 | Implement retry with idempotency key | Dev | 1.0 |
| B3 | Test retry against sandbox failures | Tester | 0.5 |
| B12 | Design the tracking status model | Designer | 0.5 |
| B12 | Build the order status endpoint | Dev | 1.0 |
| B12 | Build the tracking screen | Dev | 1.0 |
| B12 | Test status transitions | Tester | 1.0 |
| B11 | Design the address form states | Designer | 0.5 |
| B11 | Build address CRUD and default selection | Dev | 1.0 |
| B11 | Test address edge cases (postal formats) | Tester | 0.5 |
Plus the definition-of-done work: code review time (roughly 10% of development days), documentation, and acceptance by the product owner. The total will exceed 36.8 days for all four items, which is the finding.
Task 4 — designer absence. Affected tasks: B1 data shape, B3 retry policy, B12 status model, B11 form states — about 2 days of design, not 4. Options: (a) pull the design work into week 1 so it completes before the absence; (b) defer B11 and use the freed capacity once design returns. Choosing (a) protects the sprint goal; choosing (b) costs 3 points of scope. The strongest answers choose (a) and state the consequence (concentrated design effort in week 1, with developers waiting if the design is late).
Task 4 — finance manager. Two distinct problems: (i) B10 cannot start — it depends on B2, which is not in this sprint, so it is not a capacity question at all; (ii) B10 is 13 points against roughly 1.5 points of available room, so even removing B11 and B12 leaves it short. A good response names both, declines to break the sprint, and offers something actionable — for example a decision on whether to swap gift cards for order tracking in the next sprint, or an early estimate of the promotion scenario.
Task 5 — definition of done. Accept any eight checkable conditions. Waived first under pressure: the documentation condition, and the mitigation is to require that waiving it be recorded — a conscious, attributable decision rather than a silent omission.
Task 6 — deployment sequence. All four items touch the shared environment; the sequence must avoid collisions. A workable plan: deploy B3 early (small, isolated), then B1, then B11, then B12 last (largest and riskiest). The tester needs a stable environment from the start of the second week onwards, which requires developers to stop deploying to the shared environment on the last two days of the sprint unless a fix is required.
Common errors: planning for 19 points with 36.8 days and declaring it fine; adding design tasks larger than one day; treating the designer's four days as four days of lost capacity; answering the finance manager with "we will see" rather than a number.