How to calculate a flexible team capacity and have the sprint capacity adapt to it?

  • I am planning a Program Increment of 3 Months and I have a team of people with a variety of skills.

    Basically, we have 3 categories in which each developer is differently skilled: UI, Backend & Devops.

    • We know the capacity of each developer for each sprint. (in Story points [SP])
    • We know how strong each developer is in which category. (in %)
    • We know each User Story (US), their estimations in Story points (1SP ~ 8hours) and their category.

    We now want to plan the sprints in such a way, that we respect our capacity in each category and that our developers can't clone themselves.

    Up until now we just calculated a sprint capacity, assigned US to this Sprint and subtracted the estimation of that US from that capacity.

    The problem with that is, that in a team of 10 people only 4 can do tasks in the category of devops. That means we have a capacity of let's say 10SP per Sprint and our total capacity would be 30 SP.

    However, these 4 people are also skilled UI developers. Meaning if I assign a devops ticket to the sprint, it reduces the capacity of the UI as well.

    My problem is how to adaptively calculate the remaining capacity of each category.

    So I give the following example for a calculation that I am trying to do:

    Capacity of an employee in a Sprint:

    Employee Sprint 1 Sprint 2 Sprint 3
    A 10 SP 6 SP 8 SP
    B 8SP 5 SP 9 SP
    C 10 SP 10 SP 10 SP
    D 10 SP 0 SP 10 SP
    E 10 SP 5 SP 5 SP

    Estimated Skill of an developer in a category:

    Employee UI Backend Devops
    A 0% 50% 100%
    B 100% 0% 100%
    C 20% 50% 80%
    D 100% 100% 0%
    E 30% 50% 50%

    Potential Capacity per Sprint (Calculated by SUMPRODUCT() in Excel)

    Sprint UI Backend Devops Total (Sum())
    Sprint 1 23 SP 25 SP 31 SP 48 SP
    Sprint 2 8.5 SP 10.5 SP 21.5 SP 26 SP
    Sprint 3 22.5 SP 21.5 SP 27.5 SP 42 SP

    Now with have these 3 US:

    • Task 1: 8SP (UI)
    • Task 2: 16SP (BE)
    • Task 3: 10SP (Devops)

    So let's add Task 1 to the 1. Sprint:

    UI UI SP Backend Backend SP Devops Devops SP Total
    task 1 8SP 8 SP
    Total SP Used 8 SP 0 SP 0 SP 8 SP
    Capacity 23 SP 25 SP 31 SP 48 SP
    Remaining SP 15 SP 25 SP 23 SP 40 SP

    This one is easy because Employee B can take that US completely in Sprint 1 but you can already see that the remaining capacity of Devops is lowered aswell.

    Let's add Task 2:

    UI UI SP Backend Backend SP Devops Devops SP Total
    task 1 8SP Task 2 16SP 24 SP
    Total SP Used 8 SP 16 SP 0 SP 24 SP
    Capacity 23 SP 25 SP 31 SP 48 SP
    Remaining SP 4.6 SP 9 SP 11.4 SP 24 SP

    This one is a lot more complicated as more than on employee will work on that task. Let's Say Employee A, C, D will work on it:

    • A will do: 5 SP of work using 10 SP. => Devops cap. -10SP
    • C will do: 1 SP of work using 2 SP. => UI cap. -0.4 SP & devops cap: - 1.6 SP
    • D will do: 10 SP of work using 10 SP. => UI cap. -10 SP

    However, I could choose a different selection of Employees to do all the tasks.

    So my question is:

    Is there a formula that can give a good approximation of the remaining capacity, based on the overall capacity, individual capacity and individual categorized skills?

  • TLDR: Frame challenge. .

    Try to use Scrum

    In other words. we do have scrum, but we also have to plan ahead

    You say you're doing Scrum, right? (Though others here disagree.) Well, before you start , .

    Stop correlating stories to developers

    Well, . So stop trying to assign stories to developers.

    Story points are a relative estimate of effort for the Team as a whole. It's not really possible to convert story points to time. Primarily (though there are other reasons) because Story A with 2 points might take Alice 1 day but Bob 3 days, while Story B might take each of them 2 days, and both stories could be done by Charlie in half a day, or Dave in 2 weeks...

    You can (kind of) use story point estimates for long-range time estimates, based on (and only on) the Team's velocity. But this is going to be a very rough estimate. With that in mind...

    Stop trying to give exact estimates for uncertain things

    Take a look into the . You're at the wide end of the cone but trying to pretend that the cone is a line. You have uncertainty, so be realistic and bake that uncertainty into your estimates.

    It's better to say "It will take between 2 and 5 months" and be correct than to say "it will take 3 months" and have it take 4.

    You shouldn't have sub-Teams

    We do have sub-teams, because nobody is skilled enough to handle any type of User Story, but is skilled in a specific kind of User Story

    You have misunderstood the purpose of not having sub-Teams. Of course different people have different skills. That's never going to change. The reason to never have sub-Teams despite that fact is because Scrum is all about the Team. The Team is atomic.

    Trying to break the Team up into sub-Teams leads to problems such as:

    • Trying to get overly-complex for estimates (everything about this thread right here)
    • Assigning responsibility/blame to individuals
    • Lack of cohesion - the Team members don't feel like members of a single Team. At best, they are coworkers; at worst, competitors.
    • Team members stop caring about the parts of the Sprint not related to their Sub-Team

    stress for those skilled in devops and boredom for those in UI

    See final bullet point above. Remove the sub-Teams and this problem should resolve itself as your Team members start working together.

    Use the Retrospective!

    I could be wrong, but the vibe I'm getting is: "My Team ran into a problem. I assume the solution is X. How can I do X better and then force that on my Team?"

    When what should be happening is: "My Team ran into a problem. I want to bring it up in the Retrospective to see their perspective and gather suggested fixes."

Suggested Topics

  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2
  • 2