nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Sprint Story point calculation just doesn't work

Leopold van Lynden

https://www.loom.com/share/63814671990e479399a3ba4c6226739b

I've explained it in the video, but to summarise:

- I can move tasks out of sprints and the sprint point calculation doesn't update

- I can change the sprint capacity and the sprint automatically fills up the whole sprint (up to 705 SP - I mean I know we're over scheduled but that's way off!)

Basically just want it to tell me the total SP for each sprint based on what is scheduled in it. If an epic spans two or three sprints, I'd expect the SP to be spread evenly across those sprints (is that not the case?)

This is quite urgent as we really need to know our capacity and I thought I had it, but now I'm just very confused!

Comments

Angus Russell_tybhkx

@LeoP ,

Thanks for the video!

Do you have story points assigned to the stories within those epics? I'm guessing what's happening is that the story points on the issues within the epics are filling up the sprints.

The reason the last sprint that TPB Internal PRE QA falls into is always red is likely because the story points on the issues inside that epic exceed the capacity of the final sprint (even when they've also been distributed to stories in prior sprints).

The capacity allocation algorithm essentially greedily fills sprints and then dumps the rest of the estimate into the last sprint into which any given issue is assigned. At that point the sprint will show as overbooked so you can see that the issue needs more time (extra sprints) to be completed.

Let me know if that doesn't help.

Thanks,
Angus

Leopold van Lynden

Hi @Angus Russell thank you so much for your response. In response:

What we do is if the epic does not have stories within it - it will have its own SP value, which we want to use for rough forecast scheduling. TPB Internal PRE QA for example has no stories within it

If the epic has stories in it then the stories have SP value and the epic tends to have no SP value - you can see in the video they are rolled up.

I understand the algorithm will move the SP into the available sprints. It's kind of annoying, as an 80SP epic spanning two sprints, would ideally be planned to do half in the first sprint, and half in the second. Just seeing the sprint capacity "as is" would be way more useful as then I could move things around.

For me I'm afraid I still don't understand how I can move an 80SP epic into two sprints and those two sprints remain at full capacity (280 out of 280).

Nor that both those sprints will go up to 705 if I change the capacity. Is it to do with old tasks that are not closed but were scheduled in the past? Because we have loads of those.

Basically all I would like to know is how many SPs are scheduled into a sprint (either by assigning the sprint or by start/end dates). Thanks again!

Angus Russell_tybhkx

Hi @Leopold van Lynden ,

an 80SP epic spanning two sprints, would ideally be planned to do half in the first sprint, and half in the second

The algorithm is designed to reflect the way that work actually gets done, which is to keep working on a task until it is done. So what it will do is allocate story points greedily into the earliest available sprints. I do concede this makes more sense at the story level than the epic level.

If you want the epic to span two sprints evenly, you'd need to create stories under it and assign story points and sprints to the stories.

In your case, the fact that you can increase the capacity of a sprint and still have all the capacity consumed indicates that you have one or many issues with a lot of story points running across the duration of all the green sprints in your video. I imagine that as you increase the capacity of one of the green sprints, you should see that the points allocated to the first red sprint (after the green) is reduced.

To find which issues are causing this, you should just be able to scroll the plan and find any issues that are scheduled during the sprints in question. Issues not in the plan should not affect the capacity allocation algorithm.

I'm not too sure if I've answered your question, so let me know if there's more to figure out.

Thanks,

Angus

Leopold van Lynden

@Angus Russell thank you again. It all makes sense but I guess my question now is how do I use this tool for my use case.

Let me explain it to you.

We always have new projects that we need to schedule and understand whether we have capacity against the teams in the future sprints.

We know what the epics will be for each project at the beginning, based on the SOW. And, from experience, we can roughly assign SP for each epic and assign them to a team, and a time period (which can cover multiple sprints).

We cannot at this point add stories to these epics. Some require designs, and also it's not practical to write out all the functionality for the whole project at the beginning.

So, how do we use the tool to forecast the amount of actual work split evenly for epics spanning multiple sprints so that we know whether what we're planning on doing is possible?

The only workaround I can think of is that we add placeholder stories which are scheduled into specific sprints with SP that amount to the epic total (and remove the SP from the epic). However this means creating roughly 60 stories which will then need changing when we come to actually briefing them in - it wouldn't be ideal.

I'm very open to changing our setup to work with the tool - I thought I was setting it up as it's meant to work but it sounds like I'm not because I can't imagine our use case is unique. Looking forward to hearing from you Angus. Thanks.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

cloud

advanced-roadmaps