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

Khairul Nizam

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.?

Accepted answers

Carlos Garcia Navarro

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.

All comments

Carlos Garcia Navarro

Hi @Khairul Nizam ,

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

Benjamin_tmh9yg

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.

Khairul Nizam

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

Carlos Garcia Navarro

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. :-)

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

burndown