Orangescrum
Documentation index for AI agents (llms.txt). A markdown version of this page is available at /use-cases/sprint-planning.md or by requesting this URL with the header Accept: text/markdown.
Use case

Sprint Planning That Ends With a Commitment

Most sprint planning meetings run long because the backlog was not ready and nobody checked capacity. This is the version that finishes in ninety minutes with a sprint the team believes in.

Available inCloudSelf-HostedOpen Source
Start Free Trial →Book a Demo

Sprints are on the Pro plan and above, and in Self-Hosted · Unlimited users on every plan

The scenario

Your team works in two week sprints. Every other Monday the same thing happens: the product owner reads out stories nobody has seen, engineers estimate on the spot, half the team is on holiday and nobody notices until Thursday, and the sprint ends with four stories rolling over. The fix is not a longer meeting. It is doing three things before the meeting starts, and making the sprint visible for the rest of the fortnight.

Runs
Every one to four weeks
Meeting length
60 to 120 minutes
Start from
Agile project template
Owner
Scrum master or delivery lead
Who is involved

Who is in the room

Five people, three of whom have work to do before the meeting starts.
RoleWhat they ownWhat they see in Orangescrum
Product ownerPriority, the sprint goal, and accepting finished workThe product backlog ordered top to bottom, with epics grouping the big items
Scrum masterThe meeting, the sprint record, and removing blockersThe sprint board, the burndown, and last sprint's velocity
DevelopersEstimates, breaking stories into tasks, and the commitmentTheir own assigned tasks and the sprint board
QATest coverage for everything in the sprintTest cases linked to the stories, and defects raised against them
Engineering managerCapacity, leave, and who is on which projectThe workload view across everyone in the team
The workflow

Nine steps, in order

Steps one to three happen before the meeting. Skipping them is why planning meetings overrun.
  1. 1

    Keep the backlog groomed, continuously

    The backlog is not a dumping ground you tidy the night before. Order it as new work arrives, so the top twenty items are always the next twenty things you would build.

    • Group large initiatives as epics so the backlog does not become a flat list of two hundred rows
    • Break each epic into stories small enough to finish inside one sprint
    • Anything without a clear outcome stays below the line and does not get estimated
    Carried byAgile project managementTask management
  2. 2

    Put a story point on everything near the top

    Estimate the top of the backlog in a separate refinement session, not in planning. Planning should be about selection, not sizing.

    • Use story points, not hours, so the estimate is relative and stays honest
    • If a story cannot be sized, it needs splitting or a spike, and it is not ready
    Carried byAgile project management
  3. 3

    Check who is actually available

    Look at the workload view before the meeting, not after the commitment. Holiday, part time allocation, and people split across two projects are the usual reasons a sprint misses.

    • Open the workload view and check the fortnight, per person
    • Note anyone already over capacity from another project before you add more
    • Self-hosted teams can see approved leave for the same period
    Carried byWorkload managementResource management
  4. 4

    Agree the sprint goal first

    Open the meeting with one sentence describing what will be true at the end of the sprint. Everything you select then has to serve that sentence, which makes the selection argument much shorter.

    Carried byAgile project management
  5. 5

    Create the sprint and pull work into it

    Create the sprint with its dates, then pull stories from the product backlog into the sprint backlog until the points total matches what the team delivered last time.

    • Use last sprint's velocity as the ceiling, not an aspiration
    • Leave headroom for the defects you know will arrive
    Carried byAgile project management
  6. 6

    Break stories into tasks and assign owners

    A story with no tasks under it is a story nobody has thought about. Break each one into tasks and subtasks, give them owners and due dates, and the board becomes usable on day one.

    • Add a checklist for the definition of done so acceptance is not a debate
    • Link the test cases that will prove the story works
    Carried byTask managementChecklistsTest case management
  7. 7

    Start the sprint and work the board

    Once the sprint starts, the board is the meeting. Standup is people moving their own cards and saying what is blocking them, not a status report to the manager.

    • Drag a card to change its status, which keeps the board honest with no separate update
    • Mention someone on the task rather than messaging them separately, so the context stays with the work
    Carried byKanban boardMentions
  8. 8

    Watch the burndown mid sprint

    Check the burndown on day three and day six. A flat line early means the work was bigger than the estimate, and that is a conversation to have on Wednesday rather than on the last Friday.

    Carried byAgile project managementReports and analytics
  9. 9

    Close the sprint and record velocity

    Close the sprint, let the velocity chart record what was actually delivered, and take that number into the next planning meeting as the ceiling. Unfinished work goes back to the product backlog to be reprioritised, not silently carried.

    Carried byAgile project managementAdvanced reporting
Set it up

Build it on Monday morning

About forty minutes for the first project, then it repeats every sprint.
  1. 1Create a project from the Agile templateThe template starts the project on the backlog view with the sprint tools in the project menu, rather than a bare task list.
  2. 2Invite the whole teamEvery plan includes unlimited users, so there is no reason to leave QA, design, or the product owner out of the workspace.
  3. 3Load the backlogCreate epics for the big initiatives, then add the stories underneath them. Do not try to enter two years of ideas. Get the next two sprints right.
  4. 4Size the top of the backlogPut story points on the top twenty items. That is enough to run the first two planning meetings.
  5. 5Run one sprint before you tune anythingDo not add custom fields, custom statuses, or reporting on sprint one. Run it, close it, and see what actually annoyed people.
  6. 6Add a definition of done checklistOnce the flow works, add a reusable checklist group so every story arrives with the same acceptance steps on it.

The Agile template is one of eight. If your team does not run sprints, start from Kanban instead.

The result

What good looks like

After three or four sprints, these are the signals that it is working.
Planning finishes on time
Because the backlog was ordered and sized before the meeting, planning is about selection and takes under ninety minutes.
Velocity is a number, not a feeling
You can say what the team delivers per sprint, and you use it to size the next one rather than guessing.
Rollover is the exception
Most sprints finish what they committed to, because capacity was checked before the commitment was made.
Standup is five minutes
The board is already accurate, so standup is about blockers rather than reading out what everyone did.
Stakeholders stop asking for updates
Anyone can open the board or the timeline and see where things are without interrupting the team.
The backlog stays honest
Unfinished work goes back and gets reprioritised, so the backlog reflects what you would actually build next.
Watch out

Where this usually goes wrong

Estimating during planning
The meeting turns into a two hour sizing argument and nobody has energy left to commit properly.
✓ Size in a separate refinement session, so planning is only selection.
Committing to last sprint's plan, not its result
Teams commit to what they hoped to do rather than what they proved they can do.
✓ Use the velocity chart as the ceiling for the next sprint.
Nobody checks holiday
A ten point sprint is committed while two people are away for a week.
✓ Open the workload view before the meeting, every time.
Stories with no tasks under them
Work that has not been broken down has not been thought about, and it stalls on day four.
✓ No story enters the sprint without tasks and an owner.
The board goes stale
People stop moving cards, so the burndown lies and standup goes back to being a status report.
✓ Move cards in standup, on the screen, as the meeting.
Silent carry over
Unfinished stories quietly roll into the next sprint and the backlog stops meaning anything.
✓ Return unfinished work to the product backlog and let the product owner reprioritise it.
Features used

Everything this runs on

All live capabilities. Sprints, epics, backlog, and burndown are on the Pro plan and above, and included in Self-Hosted.
Agile project managementBacklogs, sprints, story points, burndown and velocityKanban boardThe daily working view during the sprintTask managementTasks, subtasks, owners, and due datesWorkload managementCheck capacity before you commitChecklistsA definition of done on every storyTest case managementLink the tests that prove the story worksReports and analyticsBurndown, velocity, and resolution timeGantt chartThe timeline view for stakeholders who want dates
Frequently asked questions

Sprint planning FAQ

How long should a sprint planning meeting take?
Between sixty and one hundred and twenty minutes for a two week sprint. If it runs longer, the cause is almost always that the backlog was not ordered and sized beforehand, so the meeting is doing refinement work rather than selection.
Which Orangescrum plan do I need for sprints?
The agile framework, sprints, epics, backlog management, and burndown and velocity charts are on the Cloud Pro plan and above, and are included in the Self-Hosted edition. Kanban boards are in every edition.
Which project template should I use?
The Agile template. It starts the project on the backlog with the sprint tools in the project menu. If your team does not run fixed sprints, the Kanban template is a better fit.
How do I work out capacity?
Open the workload view for the sprint dates and look at each person. Orangescrum shows you the allocation so you can see who is already committed elsewhere. It does not calculate the commitment for you, and it should not, because only the team knows what a point is worth.
Can stakeholders see the plan without joining the meeting?
Yes. The same work appears on a Gantt chart, so anyone who wants dates can see them without the team maintaining a second plan. Every plan includes unlimited users, so adding stakeholders costs nothing.
What do I do with unfinished stories?
Return them to the product backlog rather than carrying them automatically. The product owner then decides whether they are still the most important thing, which is the whole point of having a backlog.
Can two teams run different methods in the same workspace?
Yes. The method is set per project, so one project can run Scrum with sprints while another runs Kanban with a continuous board.
Does Orangescrum plan the sprint for me?
No. There is no scheduling optimiser and no automatic sprint builder. Orangescrum gives you the backlog, the estimates, the capacity view, and the velocity history. The commitment is the team's.

Run your next sprint in Orangescrum

Backlog, sprints, story points, and burndown, with unlimited users on every plan.

Start Free Trial →Book a Demo

Related use cases

Bug triageDecide what gets fixed, and whenProduct launchCoordinate a release across teamsQuarterly planningAgree what the quarter containsAgile Scrum templateThe project template this starts from

See all use cases →