Done? Resolved? Story Points vs. Story Point Estimate?

[Cris Coffey]

I have used Jira for many many years but always at organizations that had Jira admins on staff setting up and managing our environments. I am now deploying my own Jira environment for a new company and running into issues understanding the multiple story point fields and why they dont seem to work properly as well as why story points do not burn down properly when items are completed.  I have seen conflicting information online about story points vs. story point estimates fields and which one we should be using and information on setting the resolution to properly close things but I cannot seem to find that field in our system to add it to a form.  Any help or guidance would be helpful.  Thanks!

[Bill Sheboy]

Hi @Cris Coffey -- Welcome to the Atlassian Community!

Regarding story point fields...

When team-managed projects (TMP) were added, Atlassian made a design choice to add a new field: "Story point estimate".  The "Story points" field is the global one still used for company-managed projects (CMP).

In the UX for TMPs, the field is inconsistently called "Story point estimate" and "Story points", but both refer to the new field.

Kind regards,
Bill

[MattD]

Where's my rolling eyes emoji gone

[Cris Coffey]

We are using Company Managed Projects so this is helpful and explains why all the data we imported into the Story Point Estimate field was not showing up in our sprints.  We copied all the values into the "Story Points" field and the points started showing up. Now we are just having the issue where the Burndown report shows everything totaled on the red open issues line with nothing closing as we close out items.  Most of these issues were added after the sprint started and then dumped into the sprint.  Is that why this is not working?  Is it not possible to add scope to the sprint after it starts and reflect it properly in the burn down chart?

[Bill Sheboy]

I recall the guideline on the burn charts is based on the scope when the sprint starts, and so if all of the story points we set after sprint-start, the chart will be wrong.

Regarding burning down values, is your final workflow status mapped to the right-most column of the board?  That is how Jira Scrum board detect completion for burndown.

[Cris Coffey]

Thanks for all the help Bill.  I guess that would make sense but it would be nice if items added to the sprint mid way through would reflect in the report as well.  

Our final status is Done and that is in the last column of the board.  The interesting thing is the Burn Up chart does show items being completed in the same sprint.  

Separate question.  Is there a best practice for sprint burn down reports and status that would work better?  Should we add a "Complete" status or something before the final Done status so the burn down/burn up shows more accurately throughout the sprint?  Right now a ton of our items are "In Testing", which is not a completed status so those items even though they are completed and awaiting deployment, they still show as open items on the sprint Burn Up chart.  

[Bill Sheboy]

I suspect many community members many offer opinions on your last question, and so there could be other ideas to consider.

For me, I do not believe in "best practices"; instead I ponder "what are better (or worse) practices for a specific team's people, methods, and needs".

What problem are you trying to solve by tracking progress up to, and including, "In Testing" relative to the typical burn-up chart?  Knowing that may help clarify the need.  Perhaps also discuss this problem with the team to learn what other things could be tried.

When using Scrum, as defined in the guide, work items are completed or not, based on the team's process (i.e., workflow) from start of work until value delivery.  And so "In Testing" is likely not completed, and so would not show on the burn-up chart.

But I note something in your last paragraph, apparently indicating "In Testing" might mean "all build and validation is completed and we are awaiting deployment to production."  In that case, is there a separation of responsibilities where another team performs deployment to production...or perhaps are feature toggles used to "release" something.  Those conditions may impact the boundaries of what your team considers as the "start" and "end" of work.

[Cris Coffey]

Love your approach.  I have worked with many different Dev teams over the years and there has not been a 1 size fits all approach that would work for all of them.  On this team, we operate on 2 week sprints and do rollouts to production every other sprint.  Eventually we plan to release to production at the end of every sprint but this is a new team so we are walking before we run.  That said, we have 2 goals currently. 

1. Ability to monitor the health and progress of the current sprint. The way things are set up, nothing impacts burn down until ultimately marked Done, which means everything sits in Testing and then the burndown all happens on the last day. Then when things are marked Done, there isnt an indicator on the item when the actual items are released to production.
2. Keep track of which items are Released into production, when, and with which version of the product they were included in.  We have implemented the Releases feature for this and it seems like it will do what we need but we are considering another status value to help track all this. We are a small team and there is no separation of responsibility. 

In the end we want to be able to see sprint progress as the sprint moves along and see the burndown happening as items are finished.  Then we want to be able to move all of those finished items into a Release and launch them, create release notes, etc. which seems to all work with the Release feature.  

The current thinking is that we need 2 "completed" status values to solve all this. The theory is that Done becomes "Dev Complete" and we add an additional completed status of Released to track when the items are actually delivered to customers.  

Really truly appreciate you taking the time to offer advice.  Thank you!

[Bill Sheboy]

Regarding the idea of having multiple status values in the last column on the Jira Scrum board, the first one to hit that column will show as "done" for burn-up / down.  (The status category does not impact the burn for Jira's Scrum boards.)

Has the team considered using a Jira dashboard with gadgets (and saved filters) to show the progress of the upcoming release items?  That could be shared so stakeholders could also view progress.  The filter could check for the issues in the earliestUnreleasedVersion(): https://support.atlassian.com/jira-software-cloud/docs/jql-functions/#earliestUnreleasedVersion--

The team could also discuss at retros each item which did not finish during the sprint, planned or unplanned, and consider experiments to try to align the release cycle with the sprint one, or disconnect releasing with automation-driven release management (e.g., CI / CD pipeline).

[Cris Coffey]

Implementing a true CI / CD pipeline is part of our plan eventually. That is an interesting idea to just build a custom dashboard filter to show what we want to show instead of trying to use the built in report.  I think I have a better handle on what is possible now so I plan to discuss with the team and then decide on one of these approaches.  Thank you for all the help.