Working in a team: issues, estimates and iterations · seed 1 · A4, ink-friendly. The answer key prints on its own page for grown-ups.
En anglais

Small pieces, honest numbers

Computing · Software Engineering · ages 21-22
Name ______________________   Date ____________

  1. A team's done rule requires acceptance checks, tests, review and merge. The checks and tests pass, and review is complete, but merge is pending. Is the issue done?

    • Done: tests passed
    • Done: writing the code is enough without the agreed completion checks
    • Not done: the agreed merge step is still pending

  2. Which issue is scoped well enough to finish and review?

    • An issue bundling unrelated changes across several future releases
    • A scoped issue with a checkable result and reviewable changes
    • A short issue title with no defined result

  3. An estimate guarantees that the work will finish within its range.

    Circle one:   True   False

  4. A new library's behaviour is uncertain. The team's current duration estimate is three to six working days. How should it report the estimate?

    • A fixed four-day promise, leaving the library uncertainty out of the plan
    • No estimate, while assuming the library cannot delay the team's planned work
    • Three to six days, with assumptions and a review after a short trial

  5. An export feature needs CSV and JSON output. Each format can be tested and merged separately. Which split gives each issue a checkable result and separately reviewable changes?

    • CSV export and JSON export, each with its own checks and review
    • UI buttons and backend stubs, with neither issue having a checkable result on its own
    • CSV and JSON files mixed across two issues, with each output check requiring both issues together

  6. A team planned nine pieces and completed six. Records show the other three waited for review. What should the next planning discussion do?

    • Review the queue and adjust work in progress or review capacity
    • Blame the authors and keep the same workload
    • Discard the review records and increase planned work without checking capacity

  7. Two pieces exceeded their estimates: one lost time when a teammate was ill, and one needed unexpected library work. What is a justified response for the next plan?

    • Review capacity risk and library uncertainty, then revise the plan
    • Revise only the library estimate, treating illness as irrelevant to capacity
    • Double every estimate permanently, treating both events as recurring delays

  8. A manager treats estimates as promises. The team reports doubling its ranges solely to avoid accusations of breaking promises. Scope and effort assumptions have not changed. What does this evidence support?

    • The unchanged scope proves the tasks require twice the original effort
    • The team padded ranges to reduce promise pressure
    • Doubling estimates proves all future delivery dates will be accurate
LightMySky · lightmysky.comW1-mt_HNNnVvADcF-s1

Answer key

For grown-ups. Fold this page away before handing over the rest.

Small pieces, honest numbers W1-mt_HNNnVvADcF-s1

  1. Not done: the agreed merge step is still pending · The stated rule requires all four conditions. Acceptance checks, tests and review are complete, but merge is still pending.
  2. A scoped issue with a checkable result and reviewable changes · Clear scope and a checkable result let the team judge completion and review the changes. A short title does not establish either property.
  3. False · An estimate describes expected work under assumptions. Its range communicates uncertainty; it does not guarantee the outcome.
  4. Three to six days, with assumptions and a review after a short trial · Report the current range with its assumptions. A short trial gives the team a reason to review the estimate instead of treating it as a guarantee.
  5. CSV export and JSON export, each with its own checks and review · Splitting by format gives each issue its own checkable output and reviewable changes. The other splits need both issues for a result check. A later review date alone would not make changes unreviewable.
  6. Review the queue and adjust work in progress or review capacity · The records show that waiting for review is a constraint. The team can adjust workload or review capacity and check the effect in the next iteration.
  7. Review capacity risk and library uncertainty, then revise the plan · Both events can inform planning. Illness affects capacity risk; unexpected library work affects task scope or uncertainty. Neither single event proves a recurring pattern.
  8. The team padded ranges to reduce promise pressure · The team states why it changed the ranges, and the prompt excludes changed scope or effort assumptions. This supports padding under pressure, not doubled work or guaranteed accuracy.
Worksheet · LightMySky