Question About Burning Down Story Points and Tracking Sprint Velocity

[Drew G]

Hello!

I recently started a new position as a Scrum Master for a new organization. I am inheriting a Jira instance where no one on the team had much experience administering Jira before my arrival.

One of the first configurations I made was adding a workflow automation to burndown Story Points at a specific point in the workflow. This automation occurs on the 3rd to final step of the workflow (the Tech Lead communicated to me that that's the status where we want to show the burndown action).

It was then communicated to me that, when looking at completed Issues on the Sprint Board, that the team does not like to have the Story Points showing 0 on the tickets, because they like to get a high level understanding of the original Story Points of completed Issues in order to understand the level of effort of work put in.

My initial thinking was that not burning down Story Points would mean that I would not be logging Sprint velocity numbers, and would have no burndown chart to reference. After some testing I found that when Issues arrive in the FINAL "Completed" status of the workflow that the "burndown" action does occur, even when the Story Points aren't actually burned down to 0. The "burndown" action is captured in the Sprint burndown report when a ticket arrives to the final "Completed" workflow status.

First reaction is that this is news to me, that ticket Story Points get marked as "burned down" when they are completed in the workflow (and not actually burned down to 0). However, does anyone know how I could have this "burndown" action occur on the 3rd to last step of the workflow?

[Matt Parks]

Jira considers a work item to be completed in a sprint when it enters a status that is mapped to the far-right column of the board. So, if you put that 3rd to last step of the workflow in the far-right column, the Burndown chart would reflect the work item as being completed at that point.

Note that, if you do this, it would probably make sense for the 2nd to last step to also be in the far-right column or else it would then be considered incomplete when moving into that step.

If you do this, you won't be able to transition the story through the last two steps on the board, although you could always go directly to the issue and execute the transitions there.

Also, doing this means that, if the issue makes it to either the 3rd or 2nd to last step when the sprint is complete, the issue would be considered completed in that sprint for the purposes of the Sprint report and would not be moved to the backlog or a future sprint when the sprint is completed.

[Drew G]

Hey Matt -

Thanks for the response. Really good info you shared about an Issue landing in the far-right column is what "completes" the Issue. I was struggling to understand how that worked.

Not great news for me and how the team wants this configured though. I will have to keep pushing for burning down points, with the "0" on the Issue card being the standard.

Thanks again!

[Matt Parks]

If you change your Story Points to 0 as work is completed, your Velocity Chart will not be accurate, because, at the end of the sprint, it totals up the Story Points of all of your completed items, which will be zero.

So your Committed will be accurate, since that's captured when the sprint starts, but the Completed will always be zero. So, if you're using the Velocity Chart, I would not recommend changing the value of the Story Points field on your work items as you complete them.

[Drew G]

Hi Matt - 

Hope you've been doing great. Circling back to this because I am having the same issues about not being able to properly track the numbers in the Velocity Report (manager is starting to get on me about it).

Screenshot here shows what my Kanban board looks like. I have 2 automation rules set in place when an Issue lands on the "Ready for QA Deployment" status in the "Awaiting QA Deployment" column.

1. Story Points get burned down to 0

2. Resolution changes to "Done."

Burning Story Points to 0 does help with the Burndown Chart report (red line on the graph goes downward when points are burned down to 0), however, the Velocity Report is still empty.

If I am understanding you correctly, you suggest that I do not have the points automatically burndown when an Issue lands in the "Awaiting QA Deployment" column, and to leave the points as is?

Furthermore, it sounds like I must somehow rework my workflow so that the "Awaiting QA Deployment" column is the furthest right column on the Kanban Board in order to get that correct Velocity Reporting.

Does this all sounds correct? Really appreciate your help here.

[Matt Parks]

@Drew G 

If you want your Velocity Chart to accurately represent the amount of completed work, don't ever change the Story Point value.

The way that the Velocity Chart works, as far as the Completed value is concerned, is that it adds up the estimate value (in your case, Story Points) of all of the work items in the far-right column.

So, if you want anything that has a status of Ready for QA Deployment to be included in the Completed portion of the Velocity Chart, that status has to be mapped to the far-right column of the board.

Note that you can have multiple statuses mapped to a single column, so you could have Ready for QA Deployment and Complete both mapped to the 'Done' column, which means that any work items in either of those statuses would have their Story Point totals added to the Completed total in the Velocity Chart.

That being said, unless I am mis-understanding your workflow, it would feel weird that it could be considered Complete while in the Ready for QA Deployment status but then later be considered incomplete when it moves forward in the workflow (to either Ready for QA, QA Testing, or Failed). But that's not directly related to this particular discussion.