--- title: "Sprint Planning: How to Run It in Orangescrum | Use Cases" description: "A step-by-step sprint planning workflow, from grooming the backlog to closing the sprint: roles, agenda, story points, capacity, and features." canonical: https://www.orangescrum.com/use-cases/sprint-planning --- # Sprint Planning: How to Run It in Orangescrum | Use Cases > For the complete documentation index, see [llms.txt](https://www.orangescrum.com/llms.txt). [Home](/) / [Use cases](/use-cases) / Sprint planning 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 in[Cloud](/pricing "Cloud - included")[Self-Hosted](/self-hosted "Self-Hosted - included")Open Source [Start Free Trial →](/sign-up?utm_source=website&utm_medium=feature&utm_content=usecase_sprint-planning)[Book a Demo](https://calendly.com/orangescrum) 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. | Role | What they own | What they see in Orangescrum | | Product owner | Priority, the sprint goal, and accepting finished work | The product backlog ordered top to bottom, with epics grouping the big items | | Scrum master | The meeting, the sprint record, and removing blockers | The sprint board, the burndown, and last sprint's velocity | | Developers | Estimates, breaking stories into tasks, and the commitment | Their own assigned tasks and the sprint board | | QA | Test coverage for everything in the sprint | Test cases linked to the stories, and defects raised against them | | Engineering manager | Capacity, leave, and who is on which project | The 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 by[Agile project management](/agile-project-management)[Task management](/task-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 by[Agile project management](/agile-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 by[Workload management](/workload-management-software)[Resource management](/resource-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 by[Agile project management](/agile-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 by[Agile project management](/agile-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 by[Task management](/task-management)[Checklists](/checklists)[Test case management](/test-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 by[Kanban board](/kanban-board)[Mentions](/mention) 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 by[Agile project management](/agile-project-management)[Reports and analytics](/project-reports-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 by[Agile project management](/agile-project-management)[Advanced reporting](/advanced-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 velocity](/agile-project-management)[Kanban boardThe daily working view during the sprint](/kanban-board)[Task managementTasks, subtasks, owners, and due dates](/task-management)[Workload managementCheck capacity before you commit](/workload-management-software)[ChecklistsA definition of done on every story](/checklists)[Test case managementLink the tests that prove the story works](/test-case-management)[Reports and analyticsBurndown, velocity, and resolution time](/project-reports-analytics)[Gantt chartThe timeline view for stakeholders who want dates](/gantt-chart) 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 →](/sign-up?utm_source=website&utm_medium=feature&utm_content=usecase_sprint-planning_cta)[Book a Demo](https://calendly.com/orangescrum) ## Related use cases [Bug triageDecide what gets fixed, and when](/use-cases/bug-triage)[Product launchCoordinate a release across teams](/use-cases/product-launch)[Quarterly planningAgree what the quarter contains](/use-cases/quarterly-planning)[Agile Scrum templateThe project template this starts from](/project-templates/agile-scrum) [See all use cases →](/use-cases)