How to calculate sprint capacity?

Question

Let's say the team works 5 days, and there are 3 developers in the team, and they are working 8 hours per day. So actually it is easy to calculate: 5*3*8=120 hours of work per week.

But there is something missing: there is no time for testing and code review process at the last day of the sprint. Because it takes some time to test sprint items and Friday night (last day of sprint) works cannot be sent to done.

So for agile principles, how should I calculate sprint capacity? Should I estimate it at 4 days? If so, what should developers do on the last day?

Answer 1

It is a common agile practice to reason in terms of story points instead of hours. You can learn more about why we do so here.

The velocity concept, instead, is well explained in this blog post.

I don't want to complicate things, so I will answer to your question speaking in terms of hours.

Let's imagine that you are on the first iteration with a brand new team.

In such a case, you can assume that the team will be "really" working for about 70% of their available time. You are considering the fact that the remaining 30% will be taken up by other tasks not related with development (paperwork, e-mails, phone calls, etc.).

It is wise to start with a conservative estimate. The idea is to adjust your estimation in the next iteration and use it to determine how many hours of work can go in the next sprint.

Let's give a look at your example (a team with 3 developers, working 5 days per week, at 8 hours a day):

3 (number of developers) * 5 (days) * 8 (available working hours per day) * 0.7 (initial estimation) = 84 ("real" working hours that your team can handle in one week)

Based on your question, I think that it could be good for you to search more information about the concept of Definition of Done (DoD) as well. You can start from here.

I understand that in your organization testing is separate from development. This is not the best agile approach, but it is (sigh!) common. You can find some interesting information in this answer to the question "How to fit testing in Scrum sprints and how to write user stories in Scrum" on Programmers Stack Exchange. Give a look also at this blog post about testers working in an agile team.

It is complicated to tell you what is best for your team and organization based only on the information provided. My understanding is that you are working with one-week sprints. You wrote that, according to your experience, it is better to leave the last day for testers to do their job. In this case, if I were you, I would probably continue to consider 5 working days. The team needs to speak with the Product Owner and organize the Sprint Backlog to have user stories that fit into 4 working days to be done (so that they can be sent to the testers team in the same iteration) plus another story (or more) that can be done in the last day (to be sent to testers in the next iteration).

Answer 2

I think Waterfall / Agile methodologies are being confused here. Testing should be completed after each user story is completed and not on a specific day of the week. This sounds more like the Waterfall methodology.

If there are elements that are less important the product backlog should be groomed and prioritised by the end user.

I'm sorry I would have posted this as a comment but I do not have enough reputation on this site yet. I have quite a bit of experience and academic qualifications here and will only be too glad to help or offer ideas.

Answer 3

There is a contradiction here, you don't use hours in terms of velocity. When you are estimating stories they should be done in terms of story points. These are typically Fibonacci numbers and stories should be sized to take into account effort to do, testing time, testing complexity, risks, unknowns etc.

So you could have a story where development may only take a few hours, acceptance criteria is clear, tests are straight forward. You'd probably say that was a 3 point story.

You could also have a story that ideally would take the same time to code, but the requirements/acceptance criteria is more hazy, to setup tests may take the tester several hours of prep, the story is touching something where you know there is a lot of technical debt (or has poor test coverage), so although ideally it'll take the same time, there are a number of risks, so you may decide to make this an 8 or even a 13.

Now based on this you can look at what the team did last sprint and estimate your capacity based on that. So if the team did 100 points and it is the same team, and the technical risk hasn't changed (say by working on some unknown area of the code), you would plan based on that figure, not hours.

This covers all your missed areas and leaves contingency for ceremonies and problems as you'll gain and lose over the sprint.

Answer 4

First of all, you have to calculate your team velocity - in others words how much they can do in one sprint (including concept, development, test and meetings). Then you will be able to know how much time you need to save for things other than coding.

In other words - no you don't have to cut your development phase to 4 days, you simply have to realize that testing will be done on first, second and ... day, so add hour or so to task based on it's complexity. That will let you complete sprint without saving time for one big testing at the end.

Answer 5

I'd like to hear more about the project itself. Are there external vs. internal clients, how are the project constraints prioritized (note: quality should never be compromised), is there one product or multiple products in play, what are those products, what does the software implementation process look like, etc. But, given what we have, here are some things to consider.

1. Estimates should always come from the team (ie the people doing the work).

2. In order to provide accurate estimates, teams must be able to focus on the work. If they are getting sidetracked by support requests, unnecessary meetings, etc., it is difficult to get an accurate team velocity and therefore provide meaningful estimates. Do what you can to ensure the team can focus. If you are not the scrum master, team up with this person to ensure the team is performing as well as possible.

3. If you have external clients, it is a historical norm for them to want an hour-based estimate. Ideally, you would structure contracts & expectations in a way that did not rely on hours-based estimates. However, if you are in the middle of a project and need hourly estimates, it is ideal to let the client/business stakeholder know that the best estimates will come during sprint planning, and that estimates further out should be expected to change. Given all that, you could derive hourly estimates by executing sprint planning as follows:

   a. During backlog grooming, discuss & document the various tasks needed to complete (according to the def of done) a user story & have the team assign story point estimates to each story. Tasks should include devops/setup, development, code review. Update estimates as they come in and provide to clients/business stakeholders.

   b. During sprint planning, have team confirm tasks & story point estimates for each user story in the sprint. Then, assign the owner of each story as the person doing the dev. The story owner will also be responsible for managing the story's code review process. If possible, assign all tasks, for each sprint story, to an individual.

   c. Have each developer go through each task assigned to them and assign an hourly estimate. This can be during, or outside of, a sprint planning meeting. At the beginning of a project, it may be helpful to review the hourly estimates as a group, perhaps in a follow-up sprint planning meeting (ie sp meeting 2).

   d. As the project progresses, assuming everyone is following Scrum rules, you should be able to clarify team velocity, and then correlate an "hour-of-work per story point" estimate for your business stakeholders, allowing you to perform hour-based capacity planning.

4. If you have a little extra development capacity at the end of a sprint, you could look to have the developer w/ extra capacity do some of the following:

   a. do some pair programming with one of the other developers. this could reduce bugs/speed the code review process, as well as provide an opportunity for peer mentoring.

   b. document any development-specific items that can be re-used on future projects, or could be used to help troubleshoot software issues in the future. another possibility would be documenting & sharing any lessons learned that could be shared with developers on other teams

   c. volunteer!

   d. mentor other developers

   e. look for opportunities to streamline devops processes

Answer 6

Determine your scrum team's total working hours for the sprint, then subtract 1-2 hours per person to absorb the unknown (slack) and the remaining hours are your team's capacity (how many hours of work they can complete in a sprint).

Answer 7

I am the scrum master for my team now and I've tried couple of methods to calculate sprint capacities and finally arrived at something that now works well.

Ideal scenario:

Lets assume that we have a team of 5 developers and sprints are 2 weeks long (i.e 10 working days) with typical working hours being 8 hours a day. Assuming that developers are working uninterrupted in the sprint:

Total Developer Hours = 5 Devs x 10 Days x 8 Hours/Day = 400 Hours

1 Developer Day = 8 Hours

Focus Factor: In the above calculations we overlooked the fact that developers indeed get interrupted during their work. This is a very common problem in most teams and humans by nature. So to account these into the calculations, we used the idea of focus factor. Focus factor reflects how much percent of the time a developer effectively gets to work on tasks in the sprints.

We took multiple iterations to fine tune this number as we had to carefully consider following key factors where we spend most of our time on:

• Scrum ceremonies (planning, grooming, retrospectives, demos etc.)
• On-call responsibilities
• Design review meetings
• Code reviews
• Other meetings like manager 1:1s, hiring interviews, learning sessions etc.

After iterating through historical data from every team member, we finally ended up with the fact that we were 60% efficient during the sprint which lead us to:

Focus Factor = 0.6

Now when we incorporated focus factor into our calculations:

Total Effective Developer Hours = 400 Hours x 0.6 = 240 Hours

1 Effective Developer Day = 8 Hours / 0.6 = 13.33 Hours

Now 240 Hours is the total productive hours where developers can focus on their sprint tasks in the whole sprint. Also, 8 hours of uninterrupted time in ideal world is 13.33 hours of interrupted time in real world.

Good part about focus factor is that you can tune it proactively depending on each sprint or when there is team dynamics shifts. In our case, we revised it recently to consider the fact that we got a dedicated team member for testing our code changes since we devs could focus more on coding the features.

For more detailed explanations you can refer my medium story