Sprint Planning addresses Why, What, and How. The Sprint Goal, selected Product Backlog items, and delivery plan together form the Sprint Backlog. The Scrum Guide defines that structure; the agenda and search-team example below are practical proposals.
Bring inputs that can change the selection
Ask the Product Owner to bring the ordered work and its connection to the product direction. Developers need the current Definition of Done, known availability, relevant past delivery information, and dependencies. Where an input is missing, make it a question for planning rather than a number generated to fill a template.
Availability is an input, not a conversion formula for story points. A team's past experience can inform its forecast, but “eight days available” does not automatically mean a particular quantity of work.
A fictional document-search team
Illustrative example: all availability, work items, and dates in this section are fictional. For a two-week sprint, the team's supplied planning note lists Priya available for eight workdays and Luis for nine. Support interruptions are expected but not quantified. No team-wide delivery estimate can be calculated from those notes alone.
Proposed Sprint Goal: Help users narrow document searches to the document type they need.
| Candidate work | Goal connection | What planning must resolve |
|---|---|---|
| Add a document-type filter | Gives users the narrowing control | Confirm combined-filter behavior; estimate not supplied |
| Verify filter results against the test dataset | Checks whether narrowing returns the expected documents | Dataset readiness is unknown; estimate not supplied |
| Export search results | A separate workflow from narrowing search | Keep outside this proposed selection unless the goal or trade-off is reconsidered |
The first two items are the proposed selection. Listing them together does not establish that the Developers have accepted them. Developers need enough understanding to decide what they can take on and plan to meet the Definition of Done.
An example 75-minute agenda
- Why, 15 minutes: Discuss the proposed value and agree on the Sprint Goal. Confirm that the wording describes an outcome, not merely a list of tasks.
- What, 25 minutes: Review candidate items, availability, past delivery information, and dependencies. Decide which work is selected and identify questions that must be resolved before that choice is credible.
- How, 25 minutes: Developers outline the work needed for the selected items, including verification and integration. Expose the dataset dependency and plan around the information available.
- Read-back, 10 minutes: Confirm the goal, selected work, delivery plan, and outstanding assumptions in the maintained Sprint Backlog.
Seventy-five minutes is this example's proposed allocation, not the prescribed length of Sprint Planning. Increase the discussion time if your actual work needs it rather than filling unknown estimates just to finish on schedule.
Make the delivery plan expose the dependency
For the filter item, a proposed breakdown is to agree on behavior, build the control and query handling, test expected results, and check the integrated result against the team's Definition of Done. Developers decide the actual decomposition.
For dataset verification, the next question is specific: Who can provide the approved dataset, and when will it be usable? If it is unavailable, discuss an alternative with the Product Owner and Developers. Do not quietly omit verification and still describe the item as deliverable.
Read the packet in three passes: the goal in Why, the proposed selection in What, and the delivery steps in How. Keep each item beside its goal connection and unresolved estimate or dependency. The availability notes belong beside those unknowns so the reader can see what the proposal still depends on.
Ask AI to organize the inputs, not make the commitment
Prepare a sprint planning meeting agenda in US English.
Sprint dates and meeting length: [enter]
Product direction and proposed value: [paste]
Candidate Product Backlog items and ordering: [paste]
Supplied estimates and past delivery information: [paste or NOT SUPPLIED]
Known availability and interruptions: [paste]
Definition of Done: [paste]
Dependencies and missing inputs: [paste]
Maintained Sprint Backlog location: [enter]
Organize the meeting into Why, What, How, and a final read-back. Make phase
times sum to the meeting length and label them a proposed allocation. Draft
a proposed Sprint Goal, connect each candidate item to it, and expose the
questions needed for selection. Separate supplied availability from unknown
capacity assumptions. Do not convert days into points or invent estimates,
team agreement, readiness, or a delivery guarantee. Developers will choose
the work and the delivery plan. Keep missing values visibly NOT SUPPLIED.
Return a text planning packet. If requested, also make an HTML reading copy
with Why/What/How views, the goal always visible, and matching item details.
Label candidate work PROPOSED until I supply the selection. Do not create
another live backlog, automated estimation, or project integrations.
Before leaving, read the Sprint Goal and delivery plan together. If the planned checks cannot happen because the dataset is unavailable, that uncertainty belongs in the discussion and the maintained backlog. The output is a team plan with visible assumptions, not a promise produced by an agenda template.
Optional: review the planning packet in NOS
If an HTML briefing helps someone read the goal beside candidate work, NOS can save and display that copy. Keep selection decisions and ongoing updates in the maintained Sprint Backlog so the team has one place to adapt its plan.