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