Sprint Story-points - Store and save?

[Ricardo Gomes]

Hi,

We're on Cloud and use the Jira Plugin for Excel to dump sprint data and convert into several different types of reports that Jira does not offer (unless you pay for another plugin).

So because the sprint data constantly changes, I need to store the initial amount of Story-points my sprint starts with, which is equivalent to the sum of the Story-point fields from all the tickets my sprint starts with (remember tickets can change later so can the amount of points).

The problem is that there's not an easy way to calculate that number nor Atlassian makes that info available out-of-the-box (even though it's available somewhere since it shows on the sprint report in Jira).

Also, even if I was able to figure out the number of points, I'd still have to find a way to store that information in Jira... I'd assume Jira won't let me set a custom property to the sprint entity, am I correct? In that case, I'd probably have to create a custom field or something along those lines...

Has anybody had to solve the same problem before? Or any thoughts on how to solve this?

[Brijesh Jain]

Are you using Story points in active sprint to estimate the effort for a story/Task?

[Linda Milne_Togetha Group_]

Custom field(s) to store the information, and automation to sum / store the totals you are interested in.

[Oliver Vistisen]

You can get that info from the Burndown chart by checking the initial points sum, and you can track changes from start to now via the both that chart and the data table beneath.

Exporting and working with that data is a challenge we haven't resolved yet either. During sprint planning we calculate team capacity and then record the committed points at sprint start in a tool we've build ourselves. Then we review that at the next planning session to update with an actual before repeating. 

[Lewis Cook]

As others have indicated this information is available in the sprint reports and velocity chart shows the "committed" vs delivered Story points as well.

I wonder if perhaps drilling into your comment of tickets changing could be useful. From my understanding the only changes to sprint story point commitment should be:

• Adding additional stories due to priority change
• Removing stories due to priority change (this would normally be in conjunction with the 1st bullet)

It sounds like your team might be adjusting the story point estimates of active items in sprint when things become apparent that the original estimate was wrong?

Assuming this is the case a few potential comments:

• Suggests that improving your refinement process could result in better initial estimates
• The team should be committing to deliver the items planned in a sprint which includes the story point estimates
• There is an inherent learning opportunity to items taking more/less time than originally estimated
  • This could loop back to refinement of future work similar
  • Or could simply be that unforeseen challenges have occurred

Our teams use the story points as the high level complexity measure and Jira time logging to enable a comparison process. This is allowing us to gauge that a 5 point tasks is generally around a days effort (A fair broad range of ~5hrs - ~10hrs), we're then able to drill into any outliers and understand why they took more or less time than an "average" X point task.

All the above said you could setup an automation Rule for when a sprint is started which copies the "Story Point" field value to a custom field you create of "Initial SP Estimate" for example on any stories in the sprint. Just make sure you factor in the opportunities for items to flow between multiple sprints!

[Bill Sheboy]

Hi @Ricardo Gomes 

Yes, and...to what Lewis describes:

I suggest to teams I support not to change the forecasted story point sizing after the sprint starts.  When there is a large difference in actual effort/complexity/uncertainty/etc. for a work item than what was understood when the item was refined, it is a learning opportunity for the team:

• What happened?
• What is different about this versus prior work items we have done of this type?
• What did we not know/understand before we started the work?
• What did we do differently from how we agreed to work?

Using that information in a retrospective conversation can lead to improvements, and reduce the frequency of such mismatches, and so eliminate the need to regularly track "original" and "actual" measures such as story points.  Consider instead using tools like a "sizing ruler", triangulation, or sizing with "things that matter" to help with consistent forecasting.

Best regards,

Bill

[Nicholas Ellis _ALM Works_]

Hi Ricardo,

First and foremost I am from ALMWorks, so my suggestion does involve using our tools, specifically Structure.

Today in Structure you could create this report in Jira to have up to date information on what these story point values are, even if they have changed.  We even allow you to group by Sprint and them sum up the story points. If you wanted to save this information for later use you can export the structure to an excel sheet, then compare it to the new Story point values for the sprint to see what changed.

Cheers,

Nick Ellis
[ALM Works]

[Ricardo Gomes]

Thank you all for your responses!

[Malka Jackson _Isos Technology_]

Best practice is not to change the story point value after the sprint begins. To instead use the Retro to discuss why the team feels the value was off and what they could have done to discover a more accurate value prior to planning next time.

But, if you are going to have changing story points, I would create a custom field to do so in. "Revised Story Points" This way you are not misusing the Story Point field but are adding information within a new field. Jira knows how to handle a Story Point field that does not adjust once the sprint starts. It also knows how to handle and export a custom field along with your data set when added to the columns for the return result set.

[Ricardo Gomes]

Sorry, the goal of this thread was not to discuss the Agile aspect of changing story-points mid-sprint but to simply have that information stored in Jira so I could pull via API, so I was trying to figure that out outside of the sprint report. My reports I'm customizing go way beyond what Jira can provide, hence why I need that information.

I completely understand all the points made here as far as not being a good practice to change story-points in the middle of your sprints, and we don't really do that as a matter of fact. Once in a while, we have an emergency come in and we have to shift priorities, but that's not our norm as we're striving to follow all Agile principles. 

Thank you all again!