--- title: "Working in a team: issues, estimates and iterations" description: "A team records work in issues with clear scope and checkable results. It agrees completion checks, estimates with stated uncertainty, and compares plans with outcomes before the next iteration. Treati" canonical: https://lightmysky.com/learn/computing/working-in-a-team-issues-estimates-and-iterations-mt_HNNnVvADcF source: https://lightmysky.com/learn/computing/working-in-a-team-issues-estimates-and-iterations-mt_HNNnVvADcF.md retrieved: 2026-11-12 --- > **Agent view.** This is the Markdown twin of the page, for tools and assistants. > When to use this site, and the call that answers each job: https://lightmysky.com/agent-instructions.md > API description (OpenAPI 3.1): https://lightmysky.com/openapi.json · Authentication: https://lightmysky.com/auth.md > Pricing: https://lightmysky.com/pricing.md · Catalog: https://lightmysky.com/llms.txt · Full catalog: https://lightmysky.com/llms-full.txt > Every machine-readable file on this domain: https://lightmysky.com/.well-known/ai-catalog.json > Ask for Markdown with `Accept: text/markdown`, a `.md` address, or `?mode=agent`. # Working in a team: issues, estimates and iterations A team records work in issues with clear scope and checkable results. It agrees completion checks, estimates with stated uncertainty, and compares plans with outcomes before the next iteration. Treating estimates as promises can encourage padding or hidden news, but larger or missed estimates alone do not establish their cause. Subject: Computing · Area: Software Engineering · Ages 21 to 22 Page: https://lightmysky.com/learn/computing/working-in-a-team-issues-estimates-and-iterations-mt_HNNnVvADcF ## Ready when they can - Split a feature into scoped pieces with checkable results and reviewable changes - Give an estimate with a range, assumptions and stated uncertainty - Use plan-to-outcome evidence to revise work, capacity or estimates ## Lesson: Small pieces, honest numbers You have compared the future cost of a shortcut. Team planning turns that decision into scoped work. An issue records a result, its boundaries and checks that show whether it is complete. Split a feature so each piece has reviewable changes and a checkable result. File count alone does not tell you whether a piece is small enough. **Example.** For a login feature, one issue could validate the form and another could check passwords. Give each its own checks. A piece can be reviewed separately without being a complete product. Record dependencies between pieces. Independent work may run in parallel; dependent work waits for what it needs. There is no rule that every issue must finish before any other starts. *(drawing: An iteration is a planned stretch of work. Comparing its outcome with the plan informs the next stretch.)* Agree completion checks before starting. In this team's workflow, done means the acceptance checks pass, required tests pass, review is complete and the change is merged. Passing tests alone does not meet that agreement. Other teams may use different checks, but everyone needs to know which ones apply. An estimate describes expected effort or duration under stated assumptions. It is not a guarantee. Give a range, name uncertain work and say when you will review it. A short investigation can reduce uncertainty about a new library. Promise pressure can encourage padding or hidden news. A larger estimate alone does not prove padding; scope or new evidence may explain it. Compare planned work with completed work, including early finishes, delays and unfinished checks. If six pieces were planned and four completed, ask where work waited and why. A review queue may call for less work in progress or more review capacity. Record an action and check its effect next time. Review can improve planning, but improvement is not guaranteed every round. Different delays can inform different changes. Illness can reduce available capacity, so review whether the plan allowed for absence risk. Unexpected library work can reveal missing tasks or uncertain estimates. One event does not establish a recurring pattern. Use available evidence to revise capacity assumptions, investigate unknown work or change estimates, then check later outcomes. **Recap.** Scope reviewable issues, agree completion checks and estimate with assumptions. Compare plans with outcomes, revise the plan and check whether the changes help. *Lesson, questions, worked solutions and flashcards about team issues, estimates and iteration review were written for this learning dataset.* ## Practice 8 questions on this page, each with its working shown. ## Needs first - [Technical debt and the cost of the next change](https://lightmysky.com/learn/computing/technical-debt-and-the-cost-of-the-next-change-mt_iA8-0Qg4ID) ## Optional connections - [Requirements: turning a wish into a testable statement](https://lightmysky.com/learn/computing/requirements-turning-a-wish-into-a-testable-statement-mt_TFb-YNpvT1) ## Opens up - [Dependencies, licences and the supply chain](https://lightmysky.com/learn/computing/dependencies-licences-and-the-supply-chain-mt_2kilqPb0aV) - [Scoping and Writing a Thesis-Scale Project](https://lightmysky.com/learn/computing/scoping-and-writing-a-thesis-scale-project-mt_Y46uRENRVf)