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; } } }

How to distinguish completed and remaining story points

Martin Härri

I know that this is not good agile practice, but we have a significant percentage of stories which are not complete at the end of a sprint. To calculate capacity needed, the teams usually reduce the story points from the original estimate to the remaining story points.

Example: original estimate 10 story points, at the end of sprint 5 the story is almost done and will require 2 more story points to complete, so the story point field is changed to 2 for sprint 6.

However, we realized that this distorts our story point reports, because once the story is complete, only the revised story points will be credited, and the velocity of the team is too low.

Is there a way to distinguish between "completed" and "remaining" story points? So in the case above, 8 story points would be credited to sprint 5, and 2 to sprint 6?

Comments

Martin Härri

Hi all - any thoughts on this? We are really struggling with that topic, opinions are very diverse. Thanks!

Mikel Bitson

Hey @Martin Härri ,

Story points represent your team's understanding of the effort remaining to complete a particular task.

That's critical- because it's your team's understanding and not the true remaining effort, the story point estimate might change from an initially low amount, to a very high amount as you first start a task and are unsure how to proceed, back to a low or medium amount as you've completed the task.

Which means that, in most cases, you're not going to be able to accurately subtract points as you progress through a task. Besides, your original estimate isn't always right, is it?

Instead, you could measure how many points of effort your team understands as being successfully completed toward the ticket goal each day. This gives you some measure, but it shouldn't be directly compared to your original (committed) estimate other than to see if you're over or under estimating effort.

More info on how some teams do this: https://www.scruminc.com/hyper-productive-metrics/

In either case, something is going to roll into the new sprint if the tasks aren't done. Try to make tasks smaller and more granular by limiting ticket scope. This, combined with the Hyper Productive patterns above helps get the team right up to complete but not started on too much else.

Good luck, hope this helps!

Martin Härri

Hi @Mikel Bitson

Thank you very much for your response, and the link. I watched the video, it is extremely interesting, and even though it seems to be several years old, achieving even that level of story point proficiency will take my project a looong time.

What I learned from this video is that there's a distinction between "velocity" (story points of completed stories as per original estimate) and "work capacity"(story points completed as per revised estimate). That was new to me, a very valuable input.

Now, I still struggle with how to put this into Jira, as I would like to avoid having to manage that information in Excel, but I suppose there's no field in Jira that I could use for work capacity. And how would I handle the remaining part.

Here's an example: let's assume that thanks to careful recording of work capacity I know that the average capacity of this team is 50 story points. And let's assume that all my stories have 10 points. I have 4 half-finished stories which I want to complete (= 20 remaining story points) in the next sprint. This means I can take on 3 additional stories (= 30 story points). When I finish them all I will have a velocity of 70 story points (4 stories + 3 stories). But when I plan the sprint and take the 4 half-finished stories with the original estimate of 10 into the scope for the next sprint, this adds up to 40 story points, and I would add only 1 new story.

Now, what this team does to simplify calculation is that they reduce the story points of the half-finished stories to 5, and then they can do the math very easily.

But what it does for me who would like to produce a meaningful metric is that it destroys the basis for velocity, as when the stories will be complete, I will only count 50 instead of 70 points.

Any advice on how to handle this in Jira?

Welcome!

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

Quick Links

Find more posts tagged with

server

jira

jira-server

story-points