0

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?

Improve this question
6
  • 6
    You're not doing Scrum. What you are trying is to assume that SP correspond to work hours (they do not) and make a full-utilization plan from that. This won't work, ever. It is nice that your team (I hope you mean your team with "we") has estimated the backlog items and has a (likely not very accurate) estimate of their velocity, now let them pick items at the beginning of each sprint as Scrum prescribes. Don't plan everything ahead of time, or you're in for some very unpleasant surprises.
    – Hans-Martin Mosner
    Commented Dec 16, 2021 at 11:59
  • 3
    Velocity is a team metric, not an individual productivity metric. Tasking into a Sprint rather than pull-based Sprint Planning is also an anti-pattern. I'm not sure how much real help you'll get unless you are willing to let go of some of these preconceived notions first.
    – Todd A. Jacobs ♦
    Commented Dec 16, 2021 at 12:16
  • @Hans-MartinMosner Well the inaccuracy of the estimation is of course one thing to deal with. But we got quite good with it. Not perfekt, but we still have some idea what can be done when. However we have Clients, that want stuff to happen in specific time frames, so we need to plan ahead, so we know what we can promise. In other words. we do have scrum, but we also have to plan ahead. For that we need to calculate the capacity, and the accurate the better.
    – telion
    Commented Dec 16, 2021 at 12:59
  • 1
    Why are you estimating in Story points, when you assume man-hours anyway and plan that a specific developer can do a specific number of story points? The whole point of story points is to not have that by having an abstraction. Why aren't you simply calculating in man-hours, if you don't use any of the story points benefits anyway?
    – nvoigt
    Commented Dec 18, 2021 at 22:51
  • Mainly Selling/Defence and its project dependent. We don't do that in every project. It mostly depends on how old the project is, and how experienced the developers are. So this project is older with experienced developers, so their performance is predictable. Basically, you could say we sell story points, giving us more flexibility but we correlate it with hours as much as possible to predict the budget and capacity needed. Basically, my clients want us to be predictable and I want my team utilized efficiently meaning that few devs shouldn't be overworked in one sprint.
    – telion
    Commented Dec 20, 2021 at 8:13

1 Answer 1

Reset to default
4

TLDR: Frame challenge. Use Scrum.

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 assuming you know everything and that some parts of Scrum are unnecessary, first try out Scrum as it's intended, then master it, and only then try to adapt it to your situation.

Stop correlating stories to developers

Well, Scrum doesn't have sub-Teams. 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 Cone of Uncertainty. 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."

Improve this answer
12
  • First of all: We might be at the conflict line between scrum and safe. What I am planning is a Programm Increment: innolution.com/resources/glossary/program-increment and I am not in the position to change that, so I need to plan ahead but still be flexible at the same time. Difficult but possible. Secondly about 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 categorized in UI, BE & Devops. If got those kind of people please refer them to me ;).
    – telion
    Commented Dec 16, 2021 at 17:37
  • Thirdly my problem is not the estimation of a Userstory. We can handle that. My Problem is the capacity/velocity of the team with those 3 categories. Why? Because I had sprints, where we ignored the category of devops and the sprint failed, because the guys responsible for devops have been overestimated, while the capacity for UI was underestimated. This resulted in stress for those skilled in devops and boredom for those in UI. And no, those in UI cannot be made into Devops-Engineers in a Sprint.
    – telion
    Commented Dec 16, 2021 at 17:42
  • 1
    @telion 1-3: Updated my answer. 4: Correct. That is what a frame challenge means. You asked "I want X, how can I do Y?" I'm saying "Don't do Y."
    – Sarov
    Commented Dec 16, 2021 at 17:51
  • 1
    @telion "Now I can just ignore that difference in plannings and just say we only do UI in the first sprint, and the Backend in the last" No, if you are doing Scrum, then you are not the one picking what goes into the Sprint. The Team is. And they will, over time, get good at pulling in the right amount of work despite confounding factors such as uneven workload.
    – Sarov
    Commented Dec 17, 2021 at 14:20
  • 1
    @telion "I mean nobody has the overview over who has how much holiday, work in another project, other events" The team has, at least for the first few sprints. And that's what you have a scrum master for as well - to have that info present.
    – Jan Doggen
    Commented Dec 22, 2021 at 14:09

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge you have read our privacy policy.

Not the answer you're looking for? Browse other questions tagged or ask your own question.