total backlog story points

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

8 answers

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.

Agreed. This would be nice.

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.

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());

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

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

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.

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

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

@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.

@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

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

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

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.

1 vote

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)

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)

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()")

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.

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

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.

+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?

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.

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. 

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. 

Suggest an answer

Log in or Sign up to answer
How to earn badges on the Atlassian Community

How to earn badges on the Atlassian Community

Badges are a great way to show off community activity, whether you’re a newbie or a Champion.

Learn more
Community showcase
Published May 21, 2018 in Jira Software

How large do you think Jira Software can grow?

Hi Atlassian Community! My name is Shana, and I’m on the Jira Software team. One of the many reasons this Community exists is to connect you to others on similar product journeys or with comparabl...

1,039 views 7 18
Read article

Atlassian User Groups

Connect with like-minded Atlassian users at free events near you!

Find a group

Connect with like-minded Atlassian users at free events near you!

Find my local user group

Unfortunately there are no AUG chapters near you at the moment.

Start an AUG

You're one step closer to meeting fellow Atlassian users at your local meet up. Learn more about AUGs

Groups near you