--- title: "Sprint Planning Optimisation Guide | Orangescrum" description: "How to make sprint planning short and useful: refine the backlog before the meeting, agree one goal, plan from real capacity, and count carryover honestly." canonical: https://www.orangescrum.com/sprint-planning-optimization --- # Sprint Planning Optimisation Guide | Orangescrum > For the complete documentation index, see [llms.txt](https://www.orangescrum.com/llms.txt). [Home](/) / [Planning techniques](/optimization) / Sprint planning optimisation Planning technique # Sprint Planning Optimisation, _Explained Properly_ A sprint planning session that runs three hours is not a meeting problem, it is a backlog problem. Here is how to fix the cause, and what Orangescrum puts in front of the team while you do. [Start free trial](/sign-up?utm_source=site&utm_medium=technique&utm_campaign=sprint-planning-optimization) [See all features](/features) ## What is sprint planning optimisation? Sprint planning is the session where a team decides what it will take on in the coming iteration. Optimising it means making that decision faster and more reliable, and almost all of the gain comes from work done before the meeting rather than inside it. A backlog that has been refined, with items small enough to understand and clear enough to start, turns planning into a short conversation. An unrefined backlog turns it into a requirements workshop with the whole team in the room. The other half is honesty about capacity: leave, support duty, and unfinished carryover are real, and a plan that ignores them was never a plan. ## Why sprint planning _takes so long_ - **The backlog is refined in the meeting**Items arrive as one line titles and get discussed, split, and estimated with eight people watching. That is refinement, and doing it in planning is the single biggest cost. - **There is no sprint goal**The sprint becomes a list of unrelated items rather than one outcome. When something has to be dropped mid-sprint, nobody can say which item matters least. - **Carryover is not counted**Unfinished work rolls over and the team commits to a full sprint on top of it. The debt compounds quietly for three or four iterations, then the sprint fails visibly. - **Capacity is assumed to be the headcount**Two people on support, one on leave, and one interviewing all week. The plan is still built as though the whole team is available for project work. ## What Orangescrum _actually gives you_ Real features, named. Nothing here is an algorithm that decides for you. [**Keep a backlog you can refine**A product backlog separate from the sprint, so items can be groomed, split, and ordered before anybody walks into a planning session._Backlog and sprints_](/agile-project-management)[**Size the work in points**Story points on backlog items, so relative size is recorded once and does not have to be re-argued every time the item is discussed._Story points_](/agile-project-management)[**See what the team actually delivered**Velocity from completed sprints gives the conversation a number from history instead of a number from optimism._Velocity_](/project-reports-analytics)[**Watch the sprint as it runs**A burndown shows whether the commitment is tracking or quietly slipping, early enough that the team can do something other than apologise._Burndown_](/project-reports-analytics)[**Check who is already full**A workload view shows who is carrying more than their share before the work is assigned, rather than after they miss it._Workload management_](/workload-management-software)[**Run the sprint on a board**The sprint board makes carryover visible at the end of the iteration, which is the number teams most often forget to subtract from the next one._Kanban and sprint boards_](/kanban-board) ## How to _run planning in half the time_ 1. **Refine before you plan**Hold a short refinement session mid-sprint with two or three people. Items that reach planning should already be small, understood, and estimated. This alone usually halves the meeting. 2. **Agree one sprint goal first**Decide the single outcome the sprint is for before picking items. It gives you a rule for what to drop later, which is the decision that actually gets made under pressure. 3. **Subtract reality from capacity**Start from the days the team genuinely has after leave, support duty, and meetings, then take off the carryover. Commit against what is left, not against the headcount. 4. **Let the team make the commitment**Velocity is an input, not an instruction. The people doing the work are the only ones who know what this particular batch involves, so the number they agree to is the one that holds. 5. **Review the miss, not the people**At the end, look at what was not finished and why. Carryover caused by an unrefined item is a different problem from carryover caused by an interruption, and they need different fixes. ## What Orangescrum does not do here Orangescrum does not plan your sprint, and there is no feature called Sprint Planning Optimisation. Nothing reads your backlog and fills the next sprint. Nothing forecasts what you will finish from your velocity, balances the load across the team, prioritises the backlog for you, or warns you that a commitment looks unrealistic. It does not track leave against sprint capacity automatically, so the adjustment for people being away is one you make yourself. What it holds is the material for the conversation: a backlog, story points, sprints, boards, burndown, velocity from completed sprints, and workload. The commitment is made by the team in the room. Sprints, backlogs, story points, burndown, and velocity are on Cloud Pro and above and included in Self-Hosted. Essential SAFe for several teams planning together is on Cloud Premium and included in Self-Hosted. ## Sprint planning optimisation FAQ Does Orangescrum automatically plan or optimise a sprint? No. There is no feature that reads your backlog, applies your velocity, and fills the next sprint. Orangescrum does not forecast, balance, or warn you that a commitment is too large. It gives the team the backlog, points, velocity, burndown, and workload, and the team makes the decision. Why does our sprint planning meeting take so long? Almost always because the backlog is being refined inside it. If items arrive as one line titles and get split and estimated with the whole team watching, planning becomes a requirements workshop. Move that work to a short refinement session mid-sprint with a couple of people and the meeting shortens on its own. How is this different from sprint and iteration scheduling? They are two halves of the same problem. Sprint and iteration scheduling is about how much a team can realistically take on, meaning capacity and velocity. This page is about the planning session itself: backlog readiness, the sprint goal, and counting carryover. The other guide is worth reading alongside this one. Does Orangescrum calculate velocity? It reports what completed sprints delivered, which is your velocity. What it does not do is turn that into a forecast or use it to propose a commitment. Velocity is history you read, not a plan the tool produces. Should we commit to exactly our average velocity? Use it as a sanity check rather than a target. Average velocity tells you when a commitment is far outside the normal range, which is the useful signal. Treating it as a quota tends to push teams into inflating estimates instead of improving delivery. Can Orangescrum account for holidays and leave in sprint capacity? Not automatically. Leave is recorded in attendance and leave management, but it is not subtracted from a sprint capacity figure for you. Teams work out available days as part of planning and commit against that number themselves. Do we need story points at all? No. Some teams count items instead, which works well once items are consistently small. The point of estimating is to expose disagreement about what the work involves, and any unit that does that is fine. Orangescrum supports points if you want them. ## Give the planning session better material Free 14 day trial, no credit card. Every plan includes unlimited users. [Start free trial](/sign-up?utm_source=site&utm_medium=technique_cta&utm_campaign=sprint-planning-optimization) ## Related [**Sprint and iteration scheduling**How much a team can really commit to](/optimization/sprint-iteration-scheduling)[**Agile project management**Backlogs, sprints, and boards](/agile-project-management)[**Kanban board**Running the sprint day to day](/kanban-board)[**Workload management**Who is already carrying too much](/workload-management-software)