total backlog story points

[Liam Donaldson]

I am using greenhopper 6.0

My thought was this is an important piece of information, but I cannot find it an any screen or report. In order to help estimate the overal time to complete then a report contiaing the total amount of remaining story points is needed.

Can this be retrieved in anyway?

Thanks,

Liam

[Audrey Hudson]

I like to know the total size of the backlog for forecasting purposes. This is how I do it:

1. I set up a search for all stories within the project (yes, including closed stories) and save it as a filter.

2. Make sure you add Story Points in Tools > Configure Column

3. Export to Excel using Views > Excel (All Fields)

4. Once in Excel simply sum the Story Points column.

It would be nice if Greenhopper had a simple report that does this, and also shows how many stories in a whole backlog are unsized.

[StevenG]

Agreed. This would be nice.

[Elizabeth Sands]

This is an old post, but I think I've got a slightly different answer than any of the above. Try this:

[insert your qualifying project/ticket info here] AND (sprint not in closedSprints() or sprint is EMPTY) AND (sprint not in OpenSprints() or sprint is EMPTY) AND issueFunction in aggregateExpression("Total points", "storyPoints.sum()")

It brings up all of the tickets that are not yet assigned to a sprint or in a closed out sprint. Sort of a hack but it works. Now if only I could take the numeric value of the total number of story points returned and show it in Confluence on an Exec Mgmt report!! I can show the number of issues, but not the points. 

[Warwick Cox]

Updated version of Jeremy Walker::

Pop this in the console. 

sum = 0
pointsPerWeek = 30
jQuery('.ghx-backlog-container span.aui-badge[title="Story Points"]').each(function() {
 sum += parseInt(jQuery(this).text())
})
console.log('Total Story Points: ', sum)
console.log('Approx. Weeks until done: ', sum / pointsPerWeek)

[Drew Glass]

This is will work if you have stories without points:

sum = 0
jQuery('.ghx-backlog-container span.aui-badge[title="Story Points"]').each(function() {
if (!isNaN(parseInt(jQuery(this).text()))){
sum += parseInt(jQuery(this).text())
}
})
console.log('Total Story Points: ', sum)

[Tom Rattigan]

Seems the easiest way to do this is to create a sprint called 'Backlog Estimate Total' or whatever. Drag all the issues in the backlog into this sprint and you'll get an estimate total (why this same exact total count can't be added to the backlog itself is unclear, but clearly a point of frustration for many). Then drag back to the backlog. 

[A Navarro]

One way is to create a version/release using the menu tucked away on the far left, then highlight all the issues in the backlog and drag them into the new version/release. If you do that you will get a view like this where you can see the total story points in the Estimate badge (135 in this case). 

versions.JPG

[Deleted user]

So you're saying there's absolutely no value to knowing how much work you have ready to be worked on? Really?

[A Navarro]

No, I didn't say that nor did I intend to. Please re-read what I said because I don't think there is an issue here. "shouldn't really be used" hardly means "absolutely no value" and "to estimate against" is different from "knowing how much work you have ready to be worked on" I accept your point and agree that there is some value in knowing the total number of points in the backlog.

[slyadams]

This shows an issue count, which is pretty much meaningless.

[A Navarro]

@simonadams simon look again, the "Estimate" badge is the sum of the story points for the issues in that version.

[slyadams]

@anavarro, look again at the original question which is about points remaining in the backlog. The estimate in this pane is the total points in the version, including completed items.

[A Navarro]

@simonadams yes i understand that, that is why i wrote my answer the way I did clearly stating the user should ".. highlight all issues and drag them into the release .." which will then give then give them the total points remaining the in the backlog at that particular moment anyway, which IMO is still simpler than the other solutions

[slyadams]

@A Navarro, that's fine, my point was the pane you gave isn't useful.

[A Navarro]

@simonadams point taken, i have tried to cleanup my answer to improve clarity

[Deleted user]

In order to manage a project, you need to know how far through it you are. Project burnup charts are great for this (except if you're using Jira Agile)

Of course backlogs can/do change over time, but that's no reason not to have a snapshot at a point in time. Burnup charts also show how the scope changes over time, so I fail to see why you dismiss this as absurd.

Many of our projects are fixed-scope implementations, which we deliver using sprints. We have no easy way of seeing how myuch is done/remaining.

We could just use the version field and set everything to "Project", but we have to use the version field to keep track of which build stories were incorporated into, and so doing this would be a huge limitation (especially as this field is linked into Jenkins).

This issue has the 4th highest vote count of the Jira Agile project, and was logged nearly 2yrs ago - read the comments (https://jira.atlassian.com/browse/GHS-5513) . Not listening to your users, and how they reallyuse your product definitely isn't an agile practice.

[Deleted user]

If all your stories are visible on the page you can use this bookmarklet to count for you:

javascript:var sum = 0; jQuery('.aui-badge[title="Story Points"]').each(function() {sum += parseInt(jQuery(this).text())}); alert('Total Story Points: ' + sum); void(document.close());

To use the bookmarklet either copy/paste it in to the URL bar of your JIRA board and press enter, or (to re-use it) create a bookmark, then replace that bookmark's URL with the above code.  If you do that you can click the bookmarklet any time you're on the board to get the total.

[Jase Clamp]

I like this approach best. I've updated code (1. if epics showing was totalling those, so doubling. 2. wasn't handling blanks well) var sum = 0; var nw = 0; jQuery('.aui-badge.ghx-statistic-badge[title="Story Points"]').each(function() { nw = parseInt(jQuery(this).text()); if (nw > 0) sum += nw; }); alert('Total Story Points: ' + sum); void(document.close());

[Andrew Lindsay]

Thanks.  Super handy!  Added a filter so that it's only elements with actual visibility are shown:

javascript:var sum = 0; var nw = 0; jQuery('.aui-badge.ghx-statistic-badge[title="Story Points"]:visible').each(function() { nw = parseInt(jQuery(this).text()); if (nw > 0) sum += nw; }); alert('Total Story Points: ' + sum); void(document.close());

[Daniel Zelawski]

This was posted in 2013 and its still not a simple feature in 2021 :/ I don't think I'll be using or recommending JIRA for projects going forward.

[Steve Maiorano]

project = "Project Namr" AND issuetype = Story AND affectedVersion = XXXXXXXX AND issueFunction in aggregateExpression("Total Story Points for All Issues", "storypoints.sum()") ORDER BY summary ASC

[Dylan Kuhn]

I got here thinking I wanted see a total for story points in the backlog, but realized that really what I needed was a total for issues in an epic, and this is included as the Estimate badge when the epic is expanded in the left side menu in the backlog. 

[Danut M _StonikByte_]

Try our Great Gadgets add-on. It offer an Issue Formula Gadget that allows you to sum-up and display on your Jira dashboards the total number of story point in your projects. It also offer a Release Burnup/Burndown Gadget that shows the total number of story points along with the remaining and scope changes.   

[Robert Cavanna]

For now, I'm using the Version Report against a specific Fix Version to see the total story points remaining for incomplete issues.

Too bad there isn't anything when in Backlog mode that shows points for incomplete issues. The Versions on the left can be expanded to show total points, but that includes story points for issues that were closed. 

[EddieW]

Hmm, the backlog is an ever changing entity, and I am not sure it would ever be completed.

But you can see the total points in the backlog by dragging the sprint marker down to the bottom of the backlog. The total points are shown in the lower right corner.

Another option is something like Jamie's "Script Runner" plugin that has aggregate expressions for JQL where you could sum the points.

project = MYPROJECT and sprint not in openSprints() and issueFunction in aggregateExpression("Total points", "storyPoints.sum()")

[Deleted user]

This is a huge limitation, and the workarounds (exporting to Excel, scripts, or fixing everything to a version and using version burn up charts) are all very poor.

Being able to quanitfy the size of your project backlog and measure progress towards it is a key agile practice, and jira Agile still not supporting this is ridiculous.

I have to create charts in Excel to manage and communicate this - our MD wonders why we've bought a tool to do this when so much has to be done outside the system.

[EddieW]

Being able to quanitfy the size of your project backlog and measure progress towards it is a key agile practice.

It's not though. Its not a key practice, its not a common practice, its a violation of the principles of agile because your PRODUCT backlog is never done. If it is, your just doing iterative development in a waterfall project.

Just look at jira.atlassian.com- do you expect they have estimated all 40,000 issues for one product and are tracking their progress to completion? Its absurb. The key concept of agile is to focus on priorities is commitable pieces of work, giving the stakeholder full transparency and hands-on status updates every 2 weeks.

Version, Epic, and Spring burndowns can be calculated because all those concepts have a fixed scope. Products do not, nor do they end.

https://answers.atlassian.com/questions/262253/jira-agile-ondemand-display-project-burndown-based-on-points

[Deleted user]

In order to manage a project, you need to know how far through it you are. Project burnup charts are great for this (except if you're using Jira Agile)

Of course backlogs can/do change over time, but that's no reason not to have a snapshot at a point in time. Burnup charts also show how the scope changes over time, so I fail to see why you dismiss this as absurd.

Many of our projects are fixed-scope implementations, which we deliver using sprints. We have no easy way of seeing how myuch is done/remaining.

We could just use the version field and set everything to "Project", but we have to use the version field to keep track of which build stories were incorporated into, and so doing this would be a huge limitation (especially as this field is linked into Jenkins).

This issue has the 4th highest vote count of the Jira Agile project, and was logged nearly 2yrs ago - read the comments (https://jira.atlassian.com/browse/GHS-5513) .

Not listening to your users, and how they really use your product definitely isn't an agile practice.

[Colton Weeks]

+1 to Mark Love's comments.

We're mid-way through Sprint 5 of this project that I'm IM'ing in JIRA and we're trying to put a scope histogram together showing how total scope has changed over the past few sprints. It's not easy! Which does beg the question: why is it so hard to determine total project scope at points in the past? In my view, this is a basic feature of a project burn-up and I don't think it should take Excel or a script to get at this data. 

The closest I have found is the Release Burndown, which does not give a value for total scope, and the Version Report, which doesn't tell you the scope total at any point, you have to try to deduce it by visually scanning left to the Y-axis, which isn't a perfect value (nor is the X-axis as dates are varied and don't line up with sprint start dates). 

Seems to me it would be a fairly simple enhancement to add the Total Scope value to the Release Burndown, since that report already does some tallying of totals at the sprint starts. 

How do I submit this suggestion to Atlassian? Can anyone help me with that?

[jeff harris]

Is this still an open issue?  I think I can explain why this is important.  Unfortunately, we work on projects for government entities and often have fixed priced, fixed scheduled and fixed scope, which often take multiple years to complete.  I understand this is not a great way to do projects with all three of these fixed, but if you want to work in the federal government spectrum you often have no choice.  

It is important on these projects that you know the total number of backlog story points, as this represents total scope of the project as defined in the contract.  Many projects use agile as much as possible, but because of contracts and customer demands, full agile principles cannot be used.  

Knowing total story points in backlog is critical to knowing what is left and how much we have to manage the backlog to get it completed on time, within budget and within scope.

Again, I understand that this breaks agile principles, but some projects we do are fully agile and some are not.  We want to use the same tools for both, and this request is a simple way to help bridge that gap.

[Danut M _StonikByte_]

Try our Great Gadgets add-on. It offers an Issue Formula Gadget that allows you to sum-up and display on your Jira dashboards the total number of story point in your projects. It also offers a Release Burnup/Burndown Gadget that shows the total number of story points along with the remaining and scope changes.