Deliverables
Deliverables & Grading ✅
This is your authoritative expectations map. Canvas = submission + points. Here = meaning + quality bar.
Grading Dimensions
Most iteration / planning evaluations roll up to these categories:
| Dimension | What We Look For | Typical Evidence |
|---|---|---|
| Technical Correctness | Features function as described, edge cases handled | Demo, PR diff, tests |
| Process & Planning | Board hygiene, iteration goals realistic + met, scope negotiation visible | Project board history, issues closed vs spillover |
| Quality Engineering | Tests exist & run in CI, DoD enforced, thoughtful refactors not churn | CI workflow logs, coverage summary (if added) |
| Communication & Documentation | Clear issues (acceptance criteria), PR descriptions, ADR updates, status reports | .md artifacts, PR timelines |
| Teamwork & Professionalism | Role rotation, reviews timely, respectful feedback, risk surfaced early | Review timestamps, status report blockers |
Planning Lab Deliverable Checklist
Use this to self-audit before submitting each planning milestone (A/B/C + Scaffolding). Mark each item DONE internally; only submit once all required are satisfied.
Planning A – Foundation
- Repository created (correct naming convention) & LICENSE / README initialised
- Project Board with columns (Backlog, Ready, In Progress, In Review, Done) + labels defined
- Working Agreement (v1) committed
- Definition of Ready (DoR) documented
- Definition of Done (DoD) documented (includes: tests passing, reviewed, docs updated)
- Initial backlog seeded (≥ 8–12 well-formed issues with acceptance criteria placeholders)
- Issue template(s) and PR templates present
Planning B – Discovery & Strategy
- Stakeholder Map (diagram or table)
- Refined & prioritized backlog (top 1–2 iterations realistically scoped)
- Risk Register with likelihood + mitigation columns
- At least 1 initial ADR (e.g., stack selection) committed
- Additional ADR stubs (if multiple open questions) created OR rationale captured elsewhere
Planning C – Roadmap & Testing
- MVP statement (1 concise paragraph or bullet set)
- 5‑Iteration Roadmap (milestone/goal per iteration)
- Test Strategy (unit vs integration vs E2E + tools + triggers)
- Acceptance criteria style defined (Given‑When‑Then examples)
- Backlog issues updated to reflect roadmap grouping / milestones
Scaffolding / Bootstrap (Week 6 bridge)
- Project structure committed (src/, tests/, docs/ or equivalent)
- CI workflow file present and green
- Lint/test commands runnable locally and in CI
- First “hello world” / skeleton executable demonstrates toolchain works
- README updated with run & test instructions
Iteration Cycle Deliverables
Each development iteration (1–5) produces a set of recurring artifacts:
| Artifact | Owner (Primary) | When Created | Quality Signals |
|---|---|---|---|
| Iteration Goals (issue or doc) | Iteration Lead | Day 1 | Clear, outcome oriented, ≤ 3–5 goals |
| Updated Board | All | Ongoing | WIP limited, aging items flagged |
| Pull Requests | Dev owning task | As work completes | Small, linked issue, tests, passing CI |
| ADR Updates / New ADRs | Dev or Lead | As decisions happen | Context + decision + consequences |
| Demo (increment) | Team | End of iteration | User observable value, runnable |
| Status Report | Iteration Lead | Final day | Honest scope vs plan delta + risks |
| Release Tag (optional early, required final) | DevOps / Release Lead | End (when stable) | Semantic-ish tag, release notes |
Weekly Status Report (Essentials)
Minimum sections (see template in Resources): 1. Goals committed vs achieved 2. Work summary (closed issues / notable PRs) 3. Risks / blockers (new & ongoing) 4. Adjustments (scope, roadmap) 5. Next iteration focus preview
Pull Request (PR) Quality Checklist
Every PR should answer: “What changed?” “Why?” “How validated?”
Required (treat as DoD extension): - [ ] Linked issue (Fixes #X / Closes #Y) - [ ] Clear title (semantic prefix optional: feat:, fix:, docs:, refactor:) - [ ] Scope: single logical concern - [ ] Description: motivation + approach + notes for reviewers - [ ] Tests: added / updated OR justification for none - [ ] CI: all checks green - [ ] Review: ≥ 1 approval (non-author) - [ ] No console/debug leftovers; no commented-out dead code
Nice-to-have: - [ ] Screenshots / GIF (UI-affecting) - [ ] Performance note (if hot path touched) - [ ] Security implications addressed (if auth/data handling changed)
Releases & Tagging
You should at minimum tag the final project state; high-maturity teams tag after meaningful increments (e.g., MVP, major feature). Release notes highlight: Added / Changed / Fixed / Risks / Upgrade steps (if any).
Final Deliverables (End of Week 17)
- Final Demo (narrative: problem → solution → live walkthrough)
- Poster / Presentation asset (concise value prop + architecture + results)
- Handoff Docs: README hardened (install, run, test, deploy), ADRs up to date, open issues triaged
- Final Status Report (retrospective flavor OK)
- Release Tag + notes
Policies & Extensions (Summary)
Deadlines follow the weekly cadence; one-time extension policy (see syllabus) applies to a single planning or iteration artifact—not the final handoff. Communicate early: use status report risk section.
Self-Assessment Pro Tips
Before submitting anything graded ask: - Did we produce evidence, or just say we did the thing? - Is the artifact discoverable (linked from README or docs index)? - Would an external developer ramp in < 30 minutes using what we documented? - Are failures / gaps transparently acknowledged (this earns, not loses, trust)?