Workflow template for project and delivery
Sprint plan against capacity
Before each planning meeting, the delivery lead or scrum master brings a draft plan for the next sprint: the days each person really has, a forecast from the team's own recent delivery, the carryover, the ranked backlog cut at that figure, and what each item waits on. The team decides the commitment.
Listed under
Add it to a workflow in the Fully Powered Planner, beside the teams and roles that will run it. Book a fit call
The outcome
The planning meeting starts from a page instead of a blank board. Everyone sees how many working days the sprint holds once weekends, holidays and each person's time away are taken out, what the team actually finished in its last few sprints, and the figure that gives for this one, with a low and a high end so the risk is visible.
Work left over from the sprint that is ending goes in first, at the size it still needs. Then the backlog follows in the product owner's approved order until the planning figure is reached, and the line is drawn there. Nothing is skipped to squeeze in a smaller item; that choice is put to the team as a question. Items that are not ready, have no estimate, are held back or wait on unfinished work on the same board are set aside, each with its reason.
Every assumption behind the numbers is written down, and every open point arrives as a question with its facts. The team confirms the estimates and the dependencies and decides what it commits to, with the product owner. The AI assistant changes nothing on the board, assigns no one and commits nothing.
Who starts the work, and when
The delivery lead, scrum master or team lead runs it once the ending sprint's work has stopped and the board has been exported, a day or two before the planning meeting. It runs again if the order, an estimate or someone's availability changes before the meeting. Any team that plans in fixed sprints of one to four weeks can use it, whether it builds software, campaigns, designs or client deliverables.
What they supply
- The settings: the sprint's dates, the closed days inside it, the estimate unit (points, hours or days), which statuses mean done and ready, and whether to plan to the forecast, its low end or a figure the team sets.
- The board export, as a CSV file or pasted table with set column headings: key, title, status, estimate, remaining, rank, assignee, sprint and what each item depends on. If a heading does not match, nothing is calculated until someone says which column is which.
- Team availability: each person, their role, the share of their time that goes to this team and the dates they are out. Dates only; never a reason.
- Recent delivery, as an export or a short table: for the last few sprints, the person-days available, what was committed and what was completed.
- The product owner's notes: the sprint goal, what must be included and what is held back.
What comes out
One draft in a fixed order: the capacity, with the working days, each person's person-days and the forecast with its range; the carryover; the draft plan in order with a running total and the planning line; the items below the line and those set aside, each with its reason; what each item waits on; the product owner's notes checked against the draft; the load by person; the assumptions; and the questions for the team. Any section with nothing in it says so.
When estimates are in hours or days, the load by person shows whether anyone is assigned more than their share. When they are in points, it makes no such comparison, because points measure the team's work, not one person's. The draft never compares one person's output with another's.
An invented example
Illustrative example with invented data. The company, the team, the people, the items and every figure below are invented. The company is an invented 60-person business that sells appointment-booking software; its booking team works in two-week sprints. People are named by role and letter only. The delivery lead prepared the draft on the Friday the ending sprint closed, for the planning meeting the following Monday. First come the five inputs the delivery lead supplied, in full, then the draft the workflow template returned.
The inputs
1. Settings
Team: Booking team
Iteration being planned: Sprint 25, Monday 16 November 2026 to Friday 27 November 2026
Iteration ending: Sprint 24
Working days: Monday to Friday
Closed days: Thursday 26 and Friday 27 November 2026 (company holiday)
Estimate unit: points
Done statuses: Done
Ready statuses: Ready
Plan to: the average
Planning meeting: Monday 16 November 2026
Board exported: Friday 13 November 2026
2. Board export
Key,Title,Status,Estimate,Remaining,Rank,Assignee,Iteration,Depends on
APP-305,Recurring appointments: data model,Done,5,0,,Dev A,Sprint 24,
APP-311,Export appointments to a spreadsheet file,In progress,5,3,4,Dev A,Sprint 24,
APP-318,Fix reminder emails sent twice,In review,3,,2,Dev B,Sprint 24,
APP-320,Recurring appointments: weekly pattern,Ready,8,,1,Dev A,Sprint 25,APP-305
APP-322,Recurring appointments: change one occurrence,Ready,5,,3,Dev C,Sprint 25,APP-320
APP-325,Two-way calendar sync,Ready,8,,5,Dev B,,PAY-88
APP-327,Notes field on an appointment,Ready,3,,6,Dev C,,
APP-329,Accessibility fixes on the booking page,To refine,,,7,,,
APP-331,Reminder settings page redesign,Ready,5,,8,Designer,,APP-333
APP-333,Reminder settings service,Ready,3,,9,Dev A,,
APP-335,Bulk cancel appointments,Ready,5,,10,Dev C,,
APP-340,Waiting list for full days,Ready,8,,11,,Sprint 26,
3. Team availability
Person,Role,Allocation,Days out
Dev A,Developer,100%,
Dev B,Developer,100%,2026-11-19;2026-11-20
Dev C,Developer,50%,
Tester,Tester,100%,2026-11-27
Designer,Designer,50%,
4. Recent delivery
Iteration,Person-days,Committed,Completed
Sprint 22,36.0,40,36
Sprint 23,40.0,42,34
Sprint 24,32.0,36,30
5. The product owner's notes
Goal: Customers can book an appointment that repeats every week.
Must include: APP-320, APP-322.
Held back: APP-335, until support's feedback is in.
The draft the workflow template returned
SPRINT PLAN AGAINST CAPACITY: Booking team, Sprint 25, Monday 16 November 2026 to Friday 27 November 2026
Draft for the planning meeting on Monday 16 November 2026. Board exported Friday 13 November 2026. The team decides the commitment. Board rows: 12 read; 1 done; 1 in another iteration, not considered.
Capacity
Working days: 8. Skipped: Saturday 21 and Sunday 22 November; Thursday 26 and Friday 27 November (closed).
- Dev A, Developer: 8 working days, 0 days out, allocation 100%, 8.0 person-days.
- Dev B, Developer: 8 working days, 2 days out, allocation 100%, 6.0 person-days.
- Dev C, Developer: 8 working days, 0 days out, allocation 50%, 4.0 person-days.
- Tester, Tester: 8 working days, 0 days out (the day out on Friday 27 November is a closed day, not counted), allocation 100%, 8.0 person-days.
- Designer, Designer: 8 working days, 0 days out, allocation 50%, 4.0 person-days.
Person-days available: 30.0.
Recent delivery:
- Sprint 22: completed 36 of 40 committed, 36.0 person-days, rate 1.00.
- Sprint 23: completed 34 of 42 committed, 40.0 person-days, rate 0.85.
- Sprint 24: completed 30 of 36 committed, 32.0 person-days, rate 0.94.
Average rate: 0.93 per person-day (lowest 0.85, highest 1.00). Forecast: 27 points (range 25 to 30). Planning figure: 27 points, the forecast.
Carryover from Sprint 24: 2 items, 6 points.
- APP-318 Fix reminder emails sent twice: status In review, estimate 3, size this iteration 3 (remaining not stated, full estimate used). Assignee Dev B.
- APP-311 Export appointments to a spreadsheet file: status In progress, estimate 5, size this iteration 3. Assignee Dev A.
Draft plan, in order
- APP-318 Fix reminder emails sent twice (carried): 3. Running total 3. Assignee Dev B. Waits on nothing.
- APP-311 Export appointments to a spreadsheet file (carried): 3. Running total 6. Assignee Dev A. Waits on nothing.
- APP-320 Recurring appointments: weekly pattern: 8. Running total 14. Assignee Dev A. Waits on APP-305, done.
- APP-322 Recurring appointments: change one occurrence: 5. Running total 19. Assignee Dev C. Waits on APP-320, earlier in this draft.
- APP-325 Two-way calendar sync: 8. Running total 27. Assignee Dev B. Waits on PAY-88, outside the export, status unknown.
--- Planning line: 27 of 27 points planned; 0 left under the planning figure.
Below the line, in order:
- APP-327 Notes field on an appointment: 3. Waits on nothing.
- APP-331 Reminder settings page redesign: 5. Waits on APP-333, later in the order, both below the line.
- APP-333 Reminder settings service: 3. Waits on nothing.
Set aside:
- APP-329 Accessibility fixes on the booking page: not ready: To refine; no estimate.
- APP-335 Bulk cancel appointments: held back by the product owner.
What items wait on
- APP-320 waits on APP-305: done.
- APP-322 waits on APP-320: earlier in this draft.
- APP-325 waits on PAY-88: outside the export, status unknown.
- APP-331 waits on APP-333: later in the order, both below the line.
Product owner's notes against the draft
Goal: Customers can book an appointment that repeats every week. Must include: APP-320: above the line. APP-322: above the line. Held back: APP-335.
Load by person
- Dev A: 8.0 person-days. Above the line: APP-311, APP-320 (11 points).
- Dev B: 6.0 person-days, out Thursday 19 and Friday 20 November. Above the line: APP-318, APP-325 (11 points).
- Dev C: 4.0 person-days. Above the line: APP-322 (5 points).
- Tester: 8.0 person-days, out Friday 27 November (closed day, not counted). Nothing assigned.
- Designer: 4.0 person-days. Nothing assigned.
- Unassigned above the line: none.
Points measure the team's work, not one person's; no comparison is made.
Assumptions
- Allocations and days out are as supplied: Dev C and the Designer give 50% of their time to this team.
- The Tester's day out on Friday 27 November falls on a closed day and is not counted.
- The forecast uses the last three sprints: 100 points completed over 108.0 person-days, times 30.0 person-days, rounded down.
- APP-318 has no remaining size; its full estimate of 3 points is used.
- APP-325 is counted as if PAY-88, which is not on this board, will be ready in time.
Questions for the team
- APP-318 is in review and its remaining size is not stated. How much of its 3 points is left?
- APP-325 (8 points) waits on PAY-88, which is not in this export. Will PAY-88 be ready in time? If not, APP-325 comes out and 8 points are free under the planning figure.
- Dev B is out on Thursday 19 and Friday 20 November and is assigned APP-318 and APP-325 above the line. Does that assignment hold?
- APP-329 is in To refine with no estimate. Is it refined and estimated before planning, or left for a later sprint?
- APP-331 waits on APP-333, which comes after it in the order. If either is brought above the line, does APP-333 come first, or both together?
- The draft totals 27 points, the forecast. At the lowest past rate, 0.85, the forecast would be 25, which is 2 points fewer. Does the team commit to all 27?
Every figure traces to the board export of Friday 13 November 2026, the availability sheet and the delivery history supplied. Nothing on the board has been changed, assigned or committed.
Where it fits
- Project and delivery, which runs the planning meeting and keeps the iteration rhythm.
- Software engineering, where the backlog, the carryover and the dependencies between items decide what a sprint can hold.
- Software technology, where product teams plan in sprints and a holiday week leaves fewer days than the board assumes.
- Marketing and advertising, where agency and in-house teams run campaigns and content in sprints and share designers across teams.
- E-commerce and retail, where the store's own team plans site and catalogue work in sprints around trading peaks.
- Professional services, where delivery teams work client implementations in sprints and lose people to other engagements.
- Growth and scaling, when new teams form and need a planning habit that holds up.
- Startups and new ventures, where a small team with part-time members has to plan honestly from the start.
What has to change for your company
Map your board's column names to the template's once and keep the map with the settings. Name your done and ready statuses. Decide how many past sprints make the forecast, and whether you plan to the forecast, its low end or a figure the team chooses. Say how part-time members and people shared with other teams are counted. Decide whether carried work goes ahead of new work, which is the default, or takes its place by rank. Agree who may change the order before planning and who updates the board afterwards. It works in ChatGPT, Claude, Copilot or Gemini from the files you supply, with no connection to your board.
What has been checked
Fully Powered AI wrote this workflow template from its own published map of the work. It was editorially reviewed on 11 November 2026. It was tried once on its invented example in Claude on 11 November 2026, and the record of that run is published with it. The run reached no stop condition; the acceptance tests were not run. It has not yet been tested in a client environment, and has not yet been tested as a packaged version in ChatGPT, Claude, Copilot or Gemini.
Testing in your environment means running it on two or three past sprints your team remembers well, plus hard cases written in advance, each with its expected behaviour: a sprint with a holiday inside it, a renamed column in the board export, carried work with no remaining size, an item ranked high that waits on unfinished work, a team with only one past sprint. The delivery lead checks every figure against the board and the calendar before the team relies on the draft. Pilot acceptance-test preparation builds that test set, and what we test before we call an AI workflow ready describes the record we keep.
Who decides
Your people keep
- What the team commits to
- The order of the backlog
- The estimates and the dependencies
- Who updates the board afterwards
It does not
- Changes nothing on the board
- Assigns no one
- Commits nothing
- Never compares one person's output with another's
Questions people ask
Who is it for?
The delivery lead, scrum master or team lead of any team that plans in fixed sprints, whether it builds software, campaigns, designs or client deliverables.
What do I need to supply?
The settings, the board export, team availability with each person's dates out, recent delivery for the last few sprints, and the product owner's notes.
Does it decide what the team commits to?
No. The team confirms the estimates and the dependencies and decides what it commits to, with the product owner. The AI assistant changes nothing on the board, assigns no one and commits nothing.
Does it compare people?
No. It shows each person's days, not their output. When estimates are in points, it makes no comparison by person, because points measure the team's work, not one person's.
What has been checked?
Fully Powered AI wrote it from its own published map of the work. It was editorially reviewed on 11 November 2026. It was tried once on its invented example in Claude on 11 November 2026, and the record of that run is published with it. The run reached no stop condition; the acceptance tests were not run. It has not been tested in a client environment.
The full workflow template
Everything above is the outline. The complete workflow template is the working version: the roles, the inputs, the procedure, the exceptions and stop conditions, the output format, the reviewer checklist, the acceptance tests, the instructions for an AI assistant and what to customize for your company. It comes with a download and the link to its folder in Fully Powered’s public repository.
Free with an account. Sign in by email: no password and no card.
Next step
Put this workflow template to work for your team: on your plan, or built with you in a sprint.
Build this in a sprint
In a sprint, Fully Powered adapts this workflow template to your rules, proves it on your own work and puts it in the hands of the roles that own it.
Two ways to begin: