I wish to know -How track the uncommitted or stretch goals in JIRA

[Suganthan.Subramanian]

Dear Team, 

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,

Suganthan S

[Bill Sheboy]

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.

Kind regards,
Bill

[suganthan S]

Hello @[deleted]  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.

[Bill Sheboy]

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.

[suganthan S]

I will completely agree with you. Thanks @Bill Sheboy for views and suggestions. 

Highly appreciated for your patience and time

Have a good day