Plan the sprint where
you can see all of it.

Start from the goal, not the queue: Put one sentence at the top naming the outcome this sprint is for. Teams that skip this end up committing to a batch of unrelated tickets, and nobody can tell at the end whether the sprint succeeded because there was nothing to succeed at.

Lay the candidates out spatially: Cards under the goal, grouped by area or by workstream, so the team sees the whole proposed sprint at once instead of scrolling a backlog one row at a time. Shape problems only appear when the shape is visible.

Split until each story is deliverable: The test is not whether a story sounds small. It is whether a person could genuinely finish it inside the sprint and demo it. Drag out the pieces, split again, and stop when each card passes that test.

Draw the commitment line: Once capacity and dependencies are on the board, mark what is in and what is out. The out pile is not waste. It is the record of what the team consciously declined, which is the thing everyone forgets by the retro.

Relative sizing beats hour estimates: Teams argue about hours because hours are a prediction about a specific person on a specific day, and nobody can make that prediction. Relative sizing asks a much easier question: is this bigger or smaller than that one we already did? The number matters less than the disagreement it exposes.

Disagreement is the signal: When one engineer says small and another says large, the useful thing is not the average. It is that the two of them are describing different stories. Put both readings on the card and the scope gap surfaces before the sprint starts rather than on day four.

Capacity means real availability: Not headcount. Actual working days after holidays, on-call rotation, interviews, the all-hands, and the person who is half on another team. Write the real number beside the total on the board and the overcommit becomes arithmetic instead of optimism.

Refinement is what keeps the meeting short: Most planning sessions overrun because they are doing refinement live: reading a story for the first time, discovering it is three stories, and rewriting it while eight people watch. Keep a refinement area on the same board between sprints so planning starts with work the team has already seen.

Dependencies as connections: Draw a line from the blocker to the blocked. Chains and cycles become visible immediately, and a story sitting at the end of a three-link chain is a story you should probably not commit to this sprint.

Risks pinned where they apply: The third-party API that might not be ready, the review that needs legal, the environment that only one person can deploy. Pin each risk to the story it threatens instead of listing them somewhere nobody reads again.

Roadmap, research, and designs on the same canvas: Half of planning is somebody asking what the design looks like or why we decided that. Pin the roadmap, the research, the flows, and the screens beside the work and the answer is one scroll away rather than a follow-up meeting.

One board for a distributed team: Everyone works on the same canvas during the call, so the sprint is built in front of the team rather than typed up by one person afterwards. Remote planning fails when only the facilitator can move anything.

View-only links for stakeholders: Send a link and a product lead, a client, or another team opens the whole plan in a browser with no account. Seeing what was declined and why is usually more valuable than the list of what was taken.

Then create the issues where you track them: The committed stories become tickets in Jira or Linear, and the sprint runs there with the burndown, the states, and the reporting your team already relies on. Storyflow stays open as the map of why the sprint is shaped that way.

Carry the board into the retro: Keep the planning board next to the retrospective. Comparing what the team committed to against what actually happened is far more concrete when both versions of the sprint are visible side by side.