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!

[Angus Russell · Accepted solution]

@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]

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.

[Angus Russell]

Hi @Leopold van Lynden 

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?

Maybe you just need to change your frame of mind a bit? If the algorithm is pushing the capacity into one of the earlier sprints, and the story points are roughly correct, then that means you actually can get the work done earlier than you thought (when you were expecting it to be split over multiple sprints). So you could embrace this and run with it.

Another thing to consider is that the algorithm takes into account how many team members you have, and assumes only one team member will work on any given issue at a time. So, if you have a single epic with 100 story points, spanning 2 sprints that each have a 100 point capacity it would normally all go into the first sprint. However, if you have two team members in your team, the algorithm will assume only one of them will work on this issue and therefore only 50 story points will be allocated to each sprint, leaving the other team member with 50 story points worth of capacity available in each of the sprints.

So in other words, if you set up your team to have as many members as your real life team, the epics' story points will be more evenly distributed across their assigned sprints and should roughly reflect how the work will actually get done by the team.

Please feel free to keep asking questions, it's good for us to understand any points of confusion or annoyance.

Thanks,

Angus

[Leopold van Lynden]

@Angus Russell thanks that all makes sense - I'm going to work a bit more on it, could we possibly leave this open for a couple of days in case I have a related question? 

And just one thing to confirm. I assume that the start date for an epic and it's SP allocation will never be pulled earlier than the Target Start date that has been set (regardless of SP capacity in the prvious sprint)? Thanks

[Angus Russell]

Hi Leopold, that's correct. Story points are greedily consumed by the sprint's capacity, but only those that are scheduled within the sprint are available for consumption. :)

I don't think topics ever get closed in here, though they can be marked as "Answered".

Thanks,

Angus