How best to track points estimates vs actuals

[Lisa Besteni]

For our Kanban teams there has been discussion around adding a custom field in Jira to track actual points vs estimated points that the dev assigns prior to starting work.

The idea is that a developer would put an estimate in at the start and once finished he/she would put in the actual. 

1) Does Jira automatically track when points are changed so that no additional field is required?

2) If so, what are the filter parameters to help show any points changed and by how much?

3) Reporting on a teams velocity would require we have the "story points" field showing the "actual" number and not the customer field, correct?

4) Lastly, is velocity of a team, the points they estimated or the actual number? We have a small debate on this internally and I'd like to provide confirmed guidance.  

Many thanks, this is a great resource/community board for help.

[Yuliia_Borivets__SaaSJet_]

Hi @Lisa Besteni 

Story points are helpful if you need to estimate the number of different factors:

• the difficulty of the job
• the volume of work
• experience completing similar tasks
• possible risks or uncertainties, etc.

SPs are flexible and relative. It takes some time to get used to the estimation. 

Within our team, we don't change SPs. If we see that number was too small or too big we consider that for future tasks. It takes time to figure out what your actual velocity is.

If you still would like to change SPs, those changes are fixed in the issue history. My team has developed an add-on that might be helpful to see changes for the list of issues. You can filter by project, sprint, assignees, label, date range, etc.

Here is how we fix changes with the Issue History app:

[Josh Costella]

1) Does Jira automatically track when points are changed so that no additional field is required?

Yes, but only in the issue history which is not searchable for Story Points in JQL.

2) If so, what are the filter parameters to help show any points changed and by how much?

You would probably need to create a custom field to track an Estimate (Custom) vs Actual (Story Points field)

3) Reporting on a teams velocity would require we have the "story points" field showing the "actual" number and not the customer field, correct?

Correct.

4) Lastly, is velocity of a team, the points they estimated or the actual number? We have a small debate on this internally and I'd like to provide confirmed guidance. 

Actual. Always actual. If you are constantly changing your estimates, your estimates are not reliable to determine velocity. 

My other advice would be to not do this at all and just use the Story Points field as intended. As the team gets more comfortable with estimating, their estimates for their own work will become more refined and accurate. Just have a consistent Story Point range to use (ex Fibonacci sequence) and have everyone use the same range. It's okay if they over or underestimate. Points are just a guide for the user and team. They are not a law.  

[Bill Sheboy]

Hi @Lisa Besteni 

Yes, and...to what Josh suggests:

Perhaps do not resize; that makes permanent a work-around for the symptoms and does not help with the underlying causes. 

Instead consider a retrospective every couple of weeks and review the completed items to learn what was different/special for items that did not match the team's understanding of the work.  Ask "why" and consider how to experiment to improve sizing in the future.

Kind regards,
Bill

[Janis Plume _eazyBI_]

Hi,

eazyBI app for Jira allows tracking the story point changes. eazyBI imports all the story points history and allows seeing the changes and story points at any time in history.

Please, find here a couple of sample reports on how to report on story points in sprints.

You can track the balance of story points, including the estimate changes. Similarly, you can create your custom burndown charts, considering the estimate changes during the sprint:

https://eazybi.com/accounts/1000/cubes/Issues/reports/168153-story-points-balance-by-sprints

https://eazybi.com/accounts/1000/cubes/Issues/reports/50050-story-points-burn-down-in-sprint

Kindly,

Janis, eazyBI support

[Trudy Claspill]

Rather than tracking an "actual" story points value I would recommend using the native time tracking features to have the assigned developer add a Time Estimate to the issue, and then also track actual time spent working on the issue using the native Log Work feature.

If you want to get better at estimating story points you could then examine the original time estimate and actual time spent and consider factors that impacted the time spent, like the experience level of the person doing the work, the complexity of the work, etc.