Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

Next challenges

Recent achievements

  • Global
  • Personal

Recognition

  • Give kudos
  • Received
  • Given

Leaderboard

  • Global

Trophy case

Kudos (beta program)

Kudos logo

You've been invited into the Kudos (beta program) private group. Chat with others in the program, or give feedback to Atlassian.

View group

It's not the same without you

Join the community to find out what other Atlassian users are discussing, debating and creating.

Atlassian Community Hero Image Collage

How to distinguish completed and remaining story points

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?

2 comments

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

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!

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?

Comment

Log in or Sign up to comment
TAGS

Community Events

Connect with like-minded Atlassian users at free events near you!

Find an event

Connect with like-minded Atlassian users at free events near you!

Unfortunately there are no Community Events near you at the moment.

Host an event

You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events

Events near you