How to log and track Estimated Story Points versus Actual Story Points

[Aleisha Talbot]

Hi,

Id like to find the best way to track what we originally estimated our story points would be. Versus what they actually turned out to be.

So that we can learn if we are ever vastly estimating any items wrongly. E.g. thought it would be a 5, ends up being a 13.

Context: My team uses Story Points and I believe their estimations are stable (e.g. a 3 one week, would be a 3 the next week).

To hold the 'baseline' original estimate:

I've heard I can make an Estimated Points field (however I cannot do this myself and need to ask permission from a higher administrator).
I do have the 'Original estimate' field - which deals in TIME not POINTS.

My plan would be to automate a 'copy' of the Story Points field, when the Story is pulled into a Sprint (or when a sprint containing it is started).
This copy would land in either the estimated points field that doesnt exist yet, or bodged into the original estimate field = where 6 points equals 6 minutes.

To track the actual Story Points through the Sprint

Hypothetical 1:
Hypothetically lets say we originally estimate it to be a 5.
During the sprint we think it remains a 5.

I'd like to copy the Story points at the end (when item is set to done) into an 'Actual Story Points' field

So that I can then somehow compare Baseline Estimate versus Actual.

So in this scenario:

The original baseline estimate (ideally in Estimated Points field) would show 5

The story points throughout did not change - so show 5

And the actual Story points (when the story closed) - shows 5



Hypothetical 2:

Hypothetically lets say we originally estimate it to be a 5.
During the sprint we think it increased to a 8.

I'd like to copy the Story points at the end (when item is set to done) into an 'Actual Story Points' field

So that I can then somehow compare Baseline Estimate versus Actual.

So in this scenario:

The original baseline estimate (ideally in Estimated Points field) would show 5

The story points throughout did change - so show 8

And the actual Story points (when the story closed) - shows 8.


Other useful bits:
I did think we could potentially bodge the 'time tracking' feature 
Or just update story points during the sprint (via each person writing their part in the comments when they hand over)

1. What are peoples thoughts on the best way to complete the above?

2. Any help with setting up the automations is also appreciated.

[Mateusz Krawczyk (Eyzee)]

Hi Aleisha,

You can change story points values directly in the native Story Points field. All the changes will be reflected and nicely reported in your Jira Sprint Report, see here: https://support.atlassian.com/jira-software-cloud/docs/view-and-understand-the-sprint-report/

"Under ‘Completed Issues’, the ‘Story Points' column indicates how many story points your team completed during the sprint. If it’s displayed with two values and an arrow between them (ie. 3 → 3.5), this indicates that story point estimation was adjusted during the sprint."

All the best, Matt

[Bill Sheboy]

Hi @Aleisha Talbot -- Welcome to the Atlassian Community!

Creating automation rules to do what you ask seems straightforward, with the only challenge you note as the location to store the values.  The rules could be triggered on transitioning issues to "done" or on "sprint completed", followed by editing the issue fields.  Later, JQL filters could be used to list and review the issues.

Please consider if there is another approach...

You believe the team's forecasts are stable.  And it seems the team is changing the value of the Story Points field after the sprint has started...and perhaps that is infrequent due to stability in forecasting. 

What if the team did not change the sizing during the sprint? 

Instead during the retrospective the team could "walk the board", considering what was unexpected between the work forecasts and delivery.  To help with that, the built-in control chart could be used; with quick filters by story point sizing.  That would make visible differences between the "3 point" stories, and so forth.  This discussion could create ideas to improve backlog refinement, planning, and delivery during the sprint with experiments.  A couple of advantages to this approach are it can be tried immediately, with no updates to issues, and it can be used to look back at data from prior sprints.

Kind regards,
Bill

[Nic Brough -Adaptavist-]

It's also worth noting that this is not what story points are for.  There is no "actual story points" if you are using them as intended.  They are intended to help you size and estimate work for a team across a sprint, not report on how inaccurate any single estimate was.

If you're using them as time and effort logs, you would be better off moving to using the time estimates, which does have built-in reporting on estimate and actual, and all the functions you need to track automatically.