How to use it
Run this at the start of sprint planning, before anyone talks about which stories go in. Getting the number first stops the conversation running the other way, where the team picks a comfortable-looking backlog and then works out whether it fits.
Build the roster honestly
Add every person who will work on sprint items. Hours a day is the time they can put against those items on a normal day, not the length of their working day. For a full-time engineer with no other duties, six is a fair starting figure on an eight-hour day. Someone who spends half their week on another team gets three. A tech lead who is in a lot of other meetings might get four.
Days off covers holiday, training, conferences and any full day on a support rotation. Half days are allowed, so a person on a two-day course and one afternoon of interviews goes in as 2.5.
Set the overheads once
Ceremony hours are the same for everyone, so they live in the settings rather than on each row. Count planning, review, retro and every standup across the sprint. A two-week sprint with a two-hour planning, an hour of review, an hour of retro and ten fifteen-minute standups comes to 6.5 hours per person, which is more than most teams guess.
The focus factor absorbs everything else: interruptions, context switching, the code review you did for another team, the incident on Wednesday afternoon, and the shallow half hour after a meeting where nothing much happens. A factor between 60 and 80 percent is what most teams see once they measure it. Setting it to 100 does not give you more capacity, it just moves the disappointment to the end of the sprint.
Turn hours into points, if you use them
Points and hours are different currencies, and the exchange rate is local to your team. Enter the points the team finished last sprint and the focus-adjusted hours that produced them, and the tool divides one by the other. Applying that rate to the adjusted hours for this sprint gives a points figure grounded in what the team has actually done.
If the roster has changed a lot since that sprint, the rate is still roughly right, because it is a rate per hour rather than per person. If the kind of work has changed a lot, be more careful, and check the number against your velocity history before committing to it.
Read the result as a ceiling
Capacity is the most that could be delivered, so committing to all of it means committing to a sprint where nothing goes wrong. Commit somewhere below the number and keep a small pile of ready work to pull in when the sprint goes well. A team that finishes early and pulls more in looks and feels very different from a team that carries three items over every sprint, even when the delivered totals match.