These cookies are required for the website to function properly. They ensure security, enable basic features like page navigation, and store user session data. You cannot disable these cookies.
- Sprint / Agile Board
- Features
- Sprint Scopes
Sprint Scopes
The Project Manager groups stories inside a dated sprint scope linked to a project.
OverviewSprint Scope Review Queue×
Sprint / Agile Board · Sprint Scopes
New
Sprint Scope Review Queue
Approval conditions
| Sprint code | Sprint name | Owner | Estimated hours | Start date | End date | |
|---|---|---|---|---|---|---|
| SC-884 | Sprint 279 | 6 | 12 Oct | 20 Oct | ||
| SC-350 | Sprint 788 | 15 | 25 Oct | 28 Oct | ||
| SC-544 | Sprint 467 | 13 | 10 Oct | 17 Oct | ||
| SC-742 | Sprint 355 | 3 | 19 Oct | 28 Oct | ||
| SC-469 | Sprint 380 | 14 | 15 Oct | 24 Oct |
6 of 6 records
SC-884Sprint scopes · SS-41660
SubmittedSprint nameSprint 279
Estimated hours6
Start date12 Oct
End date20 Oct
What you can do
Scope and baseline
The Project Manager groups stories inside a dated sprint scope linked to a project. An owner, estimate, start date and end date form the baseline used when the scope is submitted. Story counts and actual hours give the team a way to compare the planned effort with work recorded in the scope.
How the work is organized
- Starting record. The Project Manager groups stories inside a dated sprint scope linked to a project.
- Named owner. Project Manager prepares the scope; Scope Reviewer makes the review decision; Delivery Lead owns the project outcome.
- Current position. The status and linked records tell the team where attention belongs next.
What to agree during setup
Agree what belongs in a sprint scope before work begins. Set a named owner and realistic date range, then settle the estimate with the team. Decide who reviews a submitted scope and who updates its status after that review. A rejected scope returns to the Project Manager for correction. Submission checks the baseline and leaves a receipt that the reviewer can inspect.
The Project Manager checks the project link and related stories before submitting. The Scope Reviewer uses the pending receipt to find the submitted baseline. An accepted or rejected status is a separate human update after that inspection; the intake receipt only confirms the baseline passed its check.
Check the handoff on an actual case
A scope covers several stories for a customer release. The Project Manager enters an estimate but leaves the end date blank. When it is submitted, the intake records a failed receipt with the reason. The manager adds the end date and submits again. The reviewer then receives a pending receipt and can examine the planned stories before updating the scope with an accepted or rejected status.
The Project Manager checks the failed receipt against the same scope before resubmitting. After the pending receipt appears, the Scope Reviewer compares the owner, estimate and dates with the linked stories. The reviewer updates the scope status after making a decision. The receipt remains evidence of intake, rather than evidence of approval.
What your team sees
- Sprint Scope Review Queue — Submitted scopes awaiting a review decision.
- Sprint Schedule — Upcoming and active scopes with their date range.
Follow the work through
See sprint planning for the planning handoff and review and approval for the decision record. Begin with a small project in implementation, then compare the team’s results with the data model.
What it keeps track of
Data model- Projects
- Engagements delivered for an organization, with budget and schedule.
- Sprint scopes
- Groupings of work inside a project.
- Stories
- Individual pieces of work assigned to a delivery team member.
- Operation receipts
- Evidence that a delivery operation was executed.
Who uses it
Permissions- Project Manager
- Prepares the scope; Scope Reviewer makes the review decision; Delivery Lead owns the project outcome.
Set up Sprint / Agile Board your way.
Start free, then use Proto to change fields, steps and approvals before your team goes live.