Sprint planning in Azure DevOps usually starts on the Capacity tab: who is in, who is off, how many hours each person has. That is useful, but it answers "how much time do we have?", not "how much will we finish?". This guide covers why capacity on its own tends to overcommit a team, what a better starting number is built from, and how the Next Sprint Planning view in Agile Analytics puts capacity and the team history together into one recommendation you can bring into the room.
Why capacity alone overcommits
Capacity counts available hours as if every hour goes into planned work. It does not. Bugs arrive mid-sprint, reviews wait for a reviewer, someone gets pulled into an incident, and items that looked like two days take five. A plan that fills the hours leaves no room for any of that, so the unfinished work slides into the next sprint and the team plans the same way again.
- Hours are an input, not an outcome. What the team actually finished in recent sprints already includes the interruptions, the waiting and the estimates that were too small.
- Capacity still matters. A sprint with two people on holiday should not get the same number as a full one, so the history has to be scaled by this sprint's availability.
- A single number hides the spread. A team that finished 8 items one sprint and 16 the next does not have a velocity of 12; it has a range.
What goes into the recommendation
Next Sprint Planning sits in the Plan group of the Agile Analytics sidebar. It picks the next future sprint with dates on the team's iteration path and builds its recommendation from four inputs, all read from Azure DevOps.
- Capacity for that sprint, read from the team's capacity settings in Azure DevOps Boards: members, hours per day, personal days off, team days off and working days. It appears as "Effective capacity this sprint", with the person-days available out of the total. Hours are weighted, so a member on 4 hours a day counts as half of one on 8.
- The last 6 finished sprints, or fewer if the team has fewer. The running sprint is never included. Completed items are counted in three buckets, Planned Work, Bugs and Exploration, using the item types set under Configuration, Item Types; an item counts as completed when it reached the first state mapped as Done in Workflow Mapping.
- A Monte Carlo run of 10,000 simulated sprints. Each one draws a whole past sprint at random and scales it by this sprint's capacity, so the bucket figures stay consistent with each other.
- Commitment reliability: how much of the work committed at the start of past sprints the team actually finished.
What the view shows
The main card is "Predicted range by bucket". Each bucket shows three figures, and the card ends with a "Total recommended" number of items and the "Capacity factor" used to scale the history.
- Recommended: the team's average per sprint for that bucket, scaled by this sprint's capacity.
- P50: the median of the simulated sprints.
- Safe: the P15 lower bound, which the team delivers at least about 85% of the time. When past sprints swing too much to set a confident lower bound, Safe shows a dash instead of a misleading zero.
- Cycle-time reality check: the median calendar days per bucket for items completed in those sprints, marked "fits" or "longer than sprint". A bucket whose median is longer than the sprint is a sign the forecast is optimistic, so split or reduce that work.
- Backlog risk scan: for items already pulled into the sprint, counts of "Items with no estimate" and "Items currently blocked".
Planning before capacity is entered
Many teams never fill in the Capacity tab. Next Sprint Planning still gives a forecast. When no capacity is found for the sprint, the "Effective capacity this sprint" card shows 100% (assumed) and says so plainly: the forecast assumes everyone is available for the whole sprint, and days off are not taken into account. Underneath is the fix (add team members with their daily capacity under Sprints, Capacity for that sprint) and an "Open Sprint in ADO Boards" link.
- If you know someone is away, enter it in Boards before the meeting. An assumed 100% overstates any sprint with leave or a public holiday in it.
- The view only reads capacity. It never changes the sprint, the capacity settings or any work item; you make those changes in Azure DevOps yourself.
- Two things do stop the forecast. A sprint with no start and end dates shows "is not yet configured", and a team with no future sprint shows "No upcoming sprint defined". Both say where in Boards to fix it.
- With fewer than 3 finished sprints, a "Low confidence:" note says predictions stabilise after 3 or more completed sprints. Treat the number as a rough guide until then.
Using commitment reliability honestly
The "Commitment reliability lens" card shows the share "of committed work this team historically completes". Committed means the items in the sprint at the end of its first day. For each finished sprint the view takes the committed items that were completed and divides by the committed total, capped at 100% so work added later cannot inflate it, then averages across sprints. Next to it, a line turns that into a count for the recommended total, for example "At a 14-item commitment, expect about 11 completed by sprint end", with your own numbers.
- Read it as a mirror, not a target. A team can hit 100% by committing to very little, and that helps nobody plan.
- If reliability is low, the first question is why: unplanned work, items too large for the sprint, or blocked dependencies. The cycle-time check and the backlog risk scan above usually point at the answer.
- If the card says there is not enough committed-vs-delivered signal, the team's recent sprints had no work in them when they started. It fills in once sprints have work assigned to them when they start.
- Unfinished committed work becomes carryover when it stays in the sprint or moves straight into the next one. Moved back to the backlog, it counts as removed scope instead.
Bringing the number to the planning meeting
The view itself calls its predictions advisory and a starting point for the planning conversation, not a substitute for it. A simple way to use it:
- Before the meeting, check the sprint has dates and capacity in Boards, or agree to plan on the assumed 100% and say so.
- Open Next Sprint Planning from the sidebar, or from the "Planning the next sprint?" card on the hub Dashboard.
- Start from Total recommended. If the team wants a commitment it is confident of, look at the Safe figures instead.
- Check the cycle-time reality check. Any bucket marked "longer than sprint" means some items need splitting before they go in.
- Clear the backlog risk scan: estimate the unestimated items and decide what to do about the blocked ones.
- Agree the number as a team, then pull the items into the sprint in Azure DevOps Boards.
Related: Monte Carlo forecasting in Azure DevOps · Monte Carlo forecasting for agile teams
Why Sprint Capacity can show a different number
Sprint Capacity, also in the Plan group, shows the team's available days after days off and a starting point for how many items that supports. It counts the same item types over its own sprint window and rounds differently, so the two views can differ slightly. Use Next Sprint Planning for the commitment and Sprint Capacity to check the available days behind it.
Looking further than one sprint
Next Sprint Planning answers "how much next sprint?". For "how many by a date" or "when will this be done", use the Monte Carlo view, which runs the same kind of simulation over a longer horizon.
Try it before your next planning meeting
Next Sprint Planning is one of the views in Agile Analytics. It runs in your browser against the Azure DevOps REST API, with no Power BI, no Analytics views and no personal access token, and it supports Azure DevOps Services (cloud). The 30-day free trial starts on install with no credit card, and every plan includes every feature.
Related: Install instructions · Pricing