Sprint 14 - Mentor Meeting
- Date: June 22th, 2026
Key Discussion Points
Sprint Completion Definition
- We discussed how to define when a sprint is actually “done.”
- Currently, tasks are considered complete once reviewed, even if not merged.
- Mentor highlighted that review alone is not sufficient, since tasks may still require rework.
Work in Review
- A significant portion of estimated work is still in review state.
- This creates uncertainty when closing Sprint 14 and planning Sprint 15.
- Work in review should still be treated as active workload.
Sprint Planning and Carryover
- Starting a new sprint while previous tasks are unresolved affects estimation accuracy.
- Unfinished review work may impact capacity in the next sprint.
Mentor Feedback
Definition of Done
- A task should only be considered complete when:
- It is reviewed
- Required fixes are applied
- It is merged
- “In review” should not be treated as “done” for sprint closure.
Closing Sprints Properly
- We should fully close the previous sprint before starting the next one.
- Unmerged tasks should not remain open across sprint boundaries when planning.
Include Review Work in Planning
- Code review is part of sprint workload and should be explicitly estimated.
- Reviewer capacity must be considered alongside development effort.
Improve Sprint Flow
- Avoid concentrating reviews at the end of the sprint.
- Instead, we should distribute review activity throughout the sprint to reduce bottlenecks and context switching.
Better Estimation and Buffering
- Sprint planning should include buffer for:
- Review time
- Potential rework after feedback
- This improves predictability and reduces overcommitment.
Agreed Adjustments
- Treat “in review” tasks as incomplete until merged.
- Close Sprint 14 only after all review and merging is finished.
- Include review capacity explicitly in Sprint planning.
- Spread review work more evenly across the sprint.
- Account for review and rework cycles in sprint estimation.