Showing results for 
Search instead for 
Did you mean: 
Sign up Log in
Deleted user
0 / 0 points
badges earned

Your Points Tracker
  • Global
  • Feed

Badge for your thoughts?

You're enrolled in our new beta rewards program. Join our group to get the inside scoop and share your feedback.

Join group
Give the gift of kudos
You have 0 kudos available to give
Who do you want to recognize?
Why do you want to recognize them?
Great job appreciating your peers!
Check back soon to give more kudos.

Past Kudos Given
No kudos given
You haven't given any kudos yet. Share the love above and you'll see it here.

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 Jira differentiate a burndown and a scope change at the end of the sprint ?

Let say I have a task of a 5 story point at the beginning of the sprint. At the end of the sprint, we couldn't complete the task on time. But there some effort already put into it and has partially completed (not done). So to reflect the amount of effort, we change the story point to 2 points (as the amount of effort is 3).
But in Jira, this action will only tag it as a scope change but not as a burndown. The graph (burndown/burnup) will also tag this as a scope change. Is there any workaround for Jira to detect this behavior? Is there any field I can use or graph to reflect the partially completed (burndown) situation.?

2 answers

1 accepted

1 vote
Answer accepted

Hi @Khairul Nizam ,

I don't have the full context to understand your process, but I'd recommend not to modify the story points, or the scope of the story, and just let it roll over to the following sprint. Once you have completed a number of sprints, the velocity will have normalized, and will reflect the team velocity without having to correct scope/story size. The story points are just an estimation (sometimes a bad one) which accounts for uncertainty as well.

Changing the story points will be identified as a scope change by Jira.

Hi, @Carlos Garcia Navarro Thank you for your answer.
I agree. Changing story points will only be identified as scope change in Jira.
In my cases, I've taken into consideration the last 3 sprint Velocity, TeamOffDays (plan), and also complexity to measure the recommended total story point for the next sprint. For that reason, I cant' allowed a task rollover to the next sprint without calculating the amount of effort (partially completed) already spend on that task. If in the beginning the estimated issue is 5 and the amount of effort spent was 3 at the end of the sprint, the new story point for that particular task will be 2 in the next sprint.

I can't wait to have the task completed for the velocity to normalize because I need the total completed effort at the end of the sprint to calculate the total recommended story point for the next sprint. :)
I'm trying to find out any method/Graph/gadget/setting in Jira that can address the scenario. Thank you for your help in advance :)

Thanks for the additional context. I still think that you would get the results that you need for planning and predictability by letting stories roll over. After a few sprints (4 or 5), you can use the velocity report to get an average number of points that you should plan for the sprint. Otherwise, in my opinion, your process may become more complex and may need more overhead than what Agile good practices intend to. This is my advice:

  • if a story isn't done by the end of the sprint, let it roll over to the next sprint. If stories don't get complete use this data as a trigger to ask questions: "what didn't go well?" "how can we do better next time?" This could turn into a very positive conversation where the team gets better overtime (the real retrospective goal!)
  • if you don't have enough sprints to get an average velocity for the team, you could assume that each person gets 1 point per day in the sprint (you can discount one or two days for meetings, e.g. if you week is 2 weeks, this translates as (10 business days - 2 days of meetings ) X 1 point/ day = 8 points total per person. You can also discount holidays or vacation days. I don't think this is "official" but it helped me get started.
  • eventually, you velocity (reported in the velocity chart e.g.) will suggest the number of points that you should plan for the sprint. Not all sprints are equal, and at times people will go on vacation, or need a sick day, or things will slow down because of public holidays,.... but don't worry, this is normal, and the important thing is to get an estimation to start the work without having to think too much. :-)
0 votes
Benjamin Community Leader Apr 27, 2021

Hi @Khairul Nizam ,


This is by design. A story that is 5 point is still 5 points. The complexity should remain the same even if some of effort is complete. So, when the story points is decrease or increase, what you are doing is increasing or decreasing the the complexity and not the effort. 


There's a way you can go about it. You can break the story in 2 pieces. leaving 1 story for the completion and the other story for the next sprint. Don't recommend this. Would recommend to just leave the story as is and carry to the next sprint and use the story as a discussion point in the retrospectives on why the story was not able to complete in the sprint and how could thing go better in the in the next iteration.

Suggest an answer

Log in or Sign up to answer

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