You're on your way to the next level! Join the Kudos program to earn points and save your progress.
Level 1: Seed
25 / 150 points
1 badge earned
Challenges come and go, but your rewards stay with you. Do more to earn more!
What goes around comes around! Share the love by gifting kudos to your peers.
Keep earning points to reach the top of the leaderboard. It resets every quarter so you always have a chance!
Join now to unlock these features and more
I have challenge to track the uncommitted or stretch goals in JIRA. Therefore, i wanted to know is there any way where i can track the uncommitted goals apart from committed sprint goal.
kindly do the needful
Thanks and Regards,
Hi @Suganthan.Subramanian -- Welcome to the Atlassian Community!
What do you mean by an "uncommitted or stretch goal"?
When teams use Scrum, they may create a Sprint Goal, which is a single objective to achieve for the sprint. This provides alignment and focus for the team members and product owner. And, it is supported by delivering work items from the sprint plan. It is not necessarily a count of items, story points, etc.
And so creating things like a "stretch goal" in that context could be problematic. The team could be confused into thinking the stretch is the actual sprint goal, and so dilute focus and react negatively when this larger scope goal is not met.
Perhaps instead use the idea from Scrum and Kanban of pull-based work: create a goal the team believes they can achieve, and if that is completed earlier than planned, work with the product owner to pull more items to deliver.
Hello @Bill Sheboy thanks for the update. what i meant was the user story was taken during mid of sprint due to business criticality . Therefore, we team considers the additional user story apart from sprint commitment . However, the velocity chart takes only the story points which took for sprint day 1 for respected sprint, in that case how do we track the user story which we took in the mid of sprint. Besides, i strongly suggested team to avoid the stretch goal unless it is super critical.
In my experience, adding a business critical item after the sprint starts is an exception and not a normal practice. For example, some teams have production support responsibilities and so may work on an urgent item after the sprint starts.
Fortunately this is visible with the Sprint Report. The team can review this report after the sprint (such as during their retrospective) to learn from any changes during the sprint. This is particularly helpful if the scope change was a non-urgent request, as that can disrupt other planned, valuable work the team was going to deliver.
It can be cumbersome to review such changes over time by loading the Sprint Report for each sprint. And so some teams may use an automation rule to add a label to issues added after the sprint started. This label could then be searched for with JQL for more analysis.
Again...hopefully adding items is an exception, and so be cautious of creating unnecessary reporting for this symptom. Instead help the team understand the root cause of the additions to experiment and resolve that cause.