Sprint Team Availability Calculator
A tool to help you accurately determine dev output each sprint.
Over the past eight years I’ve been a part of over a dozen software development teams. Some teams were part of a much larger organization, some were growing startups, and some were teams I pulled together to grow a company. A common issue for every single team I’ve been a part of is accurately determining how much can be built during a sprint. Reflecting on my own career, each team I’ve been a part of has relied heavily on intuition, past performance, and what a 10x contributor can do to estimate output. While that may work for young companies that are willing to pull an all nighter if their off by half a day, it’s more ideal to have a thoughtful strategy for estimating an agile team’s development output.
In my opinion one of the main reasons output is hard to measure is downtime. Downtime being the time lost during a sprint that is not dedicated to sprint related work. I’ve yet to be part of a dev team that openly acknowledges the downtime that will occur for each team member. Even rarer is a team that actually considers downtime when costing and planning a sprint.
What is downtime?
Downtime is any time that a team member is not working on sprint related work. Examples of downtime are commutes, meetings, lunch hours, coffee and bathroom breaks. Downtime should be things that occur during the everyday life of someone who works a 9–5.
Downtime is not accidents or things that are otherwise unforeseeable. We don’t know when we’re going to crash our car but I’ll bet my house that I’ll need to participate in a meeting (or ten) during the next week.
How do we measure downtime?
Now, I’ll admit that this could be a very scientific process. Personally, I’d rather make an educated guess instead of asking my team to clock their bathroom breaks.
To do this I created the “Sprint Team Availability Calculator” one sheet. Check it out below…
What’s the goal of the calculator?
The calculator gives product managers a quick way to determine availability during a sprint that considers downtime.
Quick note before we jump into the calculator: Most PMs are familiar with “Story Points”, I refer to them as “Sprint Points”. I’ve always found it a bit confusing to use the term “story” in numerous ways within an agile development process. Also, the goal of the calculator is to measure what is containable within a single sprint so the name change felt appropriate. That’s really it. Out with Story and in with Sprint. Feel free to use whatever feels good!
OK, let’s break down the sheet by section…
Section #1: Sprint Details.
The goal of this section is to agree on and document the terms of the sprint.
We’ll skip straight to the sprint point related stuff.
Sprint Point Value
Document the value of a sprint point so that the entire team is aligned on expectations. I suggest that one sprint point represents four hours of work. That would make one day two sprint points and one week ten sprint points.
Total Available Sprint Points in Sprint
This section is not extremely actionable, however, it gives you perspective into how big your sprint is. The number calculated should reflect an “empty” sprint. You have not considered the team members who will be working in the sprint or their downtime.
Section #2: Team Role Details.
The goal of this section is to document the department roles that will be participating in the sprint. Each sprint is different and understanding who will and will not be participating helps frame the work ahead.
Document the role of the team members. I suggest abbreviating the role as well. For example, Quality Assurance to “QA”.
Total Team Members
Document how many team members will be representing that role within the sprint.
*Pro tip: You should have all members of the product team involved in your sprint. I suggest documenting each of your product department roles are and ensuring each are represented when filling this out. There’s nothing worse than forgetting the mobile dev team, right!
Section #3: Team Member Sprint Point Calculation.
This is the core part of the calculator. The goal of this section is for you to document the total available and downtime points for each team member.
Total Available Sprint Points (TASP) represents the availability of that team member excluding any downtime. This should take into account days missed due to PTO or travel.
Downtime Sprint Points (DTSP) represents the expected total downtime during a sprint for the team member. Looking at the days ahead, quantify the sprint points that will be forfeited due to meetings for example.
Realistic Sprint Points (RSP) represents the DTSP subtracted from the TASP. The RSP is what you should use to measure your sprint for that team member as it is the most realistic measure of their availability.
Work through this section filling it out for all team members participating in the sprint.
Section #4: Total Available Sprint Points.
The goal of this section is to quantify the total Downtime Sprint Points and the Team’s Realistic Total Available Sprint Points.
Downtime Sprint Points are calculated by adding together all of the “DTSP” for the entire team.
Team Realistic Total Available Sprint Points are calculated by adding together all of the “RSP” for the entire team.
The total of Downtime Sprint Points is important to know so you can track and measure the amount of time your team is forfeiting each sprint. Part of a product manager’s job is to protect their team’s time as much as possible. Quantifying the downtime will allow you to know when you need to intervene.
The Team’s Realistic Total Available Sprint Points is what you should use when considering the sprint candidates for your sprint.
The Sprint Team Availability Calculator allows product managers to achieve a realistic understanding of the dev time available to them. Work through the calculator before organizing your sprint.
Please share your thoughts below and good luck using the calculator!
Sprint Team Availability Calculator download link: https://www.dropbox.com/s/qbk67c1cqm6gobq/Sprint%20Team%20Availability%20Calculator.pdf?dl=0