Orangescrum
Documentation index for AI agents (llms.txt). A markdown version of this page is available at /optimization/sprint-iteration-scheduling.md or by requesting this URL with the header Accept: text/markdown.
Planning technique

Sprint and Iteration Scheduling, Explained Properly

Velocity tells you what happened. Capacity tells you what is possible next. Neither of them plans the sprint for you, and here is how to use both in the conversation that does.

Start free trial See all features

What is sprint and iteration scheduling?

Sprint and iteration scheduling means fixing a short, repeating period of work, usually between one and four weeks, and deciding what the team will commit to inside it. The length stays constant so that throughput becomes measurable: after a few sprints you know roughly how much the team completes, which is its velocity. Scheduling the next sprint is then a conversation between that history and the team's actual capacity for the coming period, allowing for leave, support duty, and anything carried over unfinished. The commitment is made by the team rather than calculated for them, because only the people doing the work know what this particular batch of it involves.

Where sprint plans quietly go wrong

  • The sprint is planned from hope, not historyThe commitment is built from what stakeholders want delivered, then justified afterwards. Velocity from the last three sprints is in the tool and nobody opens it.
  • Capacity ignores everything that is not project workTwo people are on support, one is interviewing all week, and one is on leave for three days. The sprint is still planned as though it were a full team.
  • Carryover is never counted firstUnfinished work rolls into the next sprint and is added on top of a full commitment, so the new sprint starts already over capacity and ends the same way.
  • The sprint length keeps changingTwo weeks, then three because of a holiday, then one to hit a date. Velocity now compares nothing with nothing, and the team has lost its only reliable planning number.

What Orangescrum actually gives you

Real features, named. Nothing here is an algorithm that decides for you.

Keep one ranked backlogA single ordered list means sprint planning starts from an agreed priority rather than from an argument about what matters most this fortnight.BacklogsSee what the team really completedVelocity across previous sprints gives you an evidence-based starting point for the next commitment instead of a number somebody feels comfortable with.VelocityWatch the sprint while it runsA burndown shows whether the committed work is being completed at a rate that finishes. A flat line in the first week is information you can still act on.BurndownCheck capacity before committingAvailability and allocation show how much of each person is genuinely there for this sprint, which is what turns a velocity average into a realistic commitment.Resource managementSpot who is already over-committedA workload heat map shows the person carrying more than the sprint assumes, which is usually why some of the committed work does not finish.Workload heat mapPlan several teams on one cadenceEssential SAFe supports planning where several teams contribute to the same increment and need their dependencies visible to each other.Scaled Agile

How to schedule a sprint honestly

  1. Fix the length and stop changing itPick one to four weeks and keep it. Velocity only means something when the periods are comparable, and a fixed cadence is worth more than a convenient one.
  2. Work out capacity for this sprint, not in generalCount the days each person is actually available after leave, support, and meetings. Sprint capacity is a different number every sprint, and treating it as constant is the most common error.
  3. Subtract carryover before you commit anything newUnfinished work is the first claim on the new sprint. Whatever is left after that is the space you have, and it is usually smaller than the room expected.
  4. Let the team make the commitmentPresent the velocity and the capacity, then let the people doing the work say what they will take. A commitment handed down is a forecast made by someone else.
  5. Review velocity, do not chase itUse it to plan, never as a target. The moment velocity becomes a goal, estimates inflate to meet it and the number stops telling you anything true.

What Orangescrum does not do here

Orangescrum does not plan your sprint for you. There is no feature that reads your velocity, looks at your backlog, and fills the next sprint automatically. Story points, velocity, burndown, backlogs, and capacity are all there to inform a planning conversation, and the commitment is made by the team in that conversation. Nothing balances the sprint, assigns the work to people, or warns you that a commitment is unrealistic beyond showing you the numbers you already have. Sprints, backlogs, story points, burndown, and velocity are on Cloud Pro and above and included in Self-Hosted. Essential SAFe for multiple teams is on Cloud Premium and included in Self-Hosted.

Sprint and iteration scheduling <em>FAQ</em>

Does Orangescrum automatically plan a sprint from our velocity?
No. Nothing reads your velocity and fills the sprint for you, and nothing tells you a commitment is too big. Orangescrum shows velocity, capacity, the ranked backlog, and the burndown once the sprint is running. The team looks at those numbers and commits, which is where the commitment should be made.
How many story points should we commit to?
Start from the average of the last three sprints, then adjust for this sprint's actual capacity and subtract carryover. If the team is smaller this fortnight, the commitment should be smaller by roughly the same proportion.
How should we handle work carried over?
Count it first, before any new work is added. Carryover is already committed effort, so it comes out of the new sprint's capacity rather than sitting on top of it.
Should velocity be a target?
No. Velocity is a measurement, and measurements stop being useful the moment they become targets. Estimates inflate quietly, the number rises, and delivery does not change. Use it to plan and never to assess the team.
Which plan or edition do I need for this?
Sprints, backlogs, story points, burndown, and velocity are on Cloud Pro and above and included in Self-Hosted. Essential SAFe is on Cloud Premium and included in Self-Hosted. Resource management and the workload heat map are on Cloud Premium and included in Self-Hosted.
Can several teams plan on the same cadence?
Yes, using the Scaled Agile support for Essential SAFe, where several teams contribute to a shared increment and can see the dependencies between them. That is on Cloud Premium and in Self-Hosted.
How long should a sprint be?
Two weeks suits most teams. Shorter gives faster feedback but higher planning overhead. Longer reduces the overhead but lets a sprint drift for weeks before anybody notices. The length matters far less than keeping it the same.
Should we estimate in story points or hours?
Either works. Points are relative and tend to be quicker and less contested; hours are concrete and easier to reconcile with capacity and cost. Orangescrum supports story points on the work and time logged against it, so teams can use one, the other, or both.

Plan the sprint from real numbers

Free 14 day trial, no credit card. Every plan includes unlimited users.

Start free trial

Related

Agile explainedScrum vs Kanban, ceremonies and metricsAgile project managementSprints, backlogs, velocityScaled agileEssential SAFe for several teamsRelease planning coordinationGetting everyone ready to shipResource-constrained schedulingPlanning around limited people