JIRA AGILE (ondemand) display project burndown based on points

Graeme Milligan February 12, 2014

Hi All,

We ave recently adopted JIRA AGILE ondemand to track our current project but I am having some issues viewing a project burndown. By this I mean chart showing all of the complete backlog of the project with an expected completion date.

I have found the version report on the standard report tabof my project. This shows a burn-up with projected end dates etc but I really want a burn down instead. Also I have tried the classic statistics tool (failed as I couldnt set the field) and a number of other methods.

We have a backlog with all user stories in it and all stories have estimates. I have setup a version and all user stories are linked to the version using the "fix version" parameter.

Hopping someone can suggest what I am doing wrong or at least confirm that this is not possibel (which seems weird and if so I would probably ask to cancel my license as this is a key report we require for management)?

Thanks in advance,

Graeme

2 answers

1 accepted

0 votes
Answer accepted
Graeme Milligan February 18, 2014

I am closing this question and asking another as I know realease my choice of titel was not correct. Should have been "how do I generate a version burndown?"

1 vote
EddieW
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 12, 2014

A burndown chart has nothing to do with the backlog, but rather is the measure within the cycle of a single sprint, and charts both the ideal, and the real progress of stories in the sprint.

It's completion date is always the end of the sprint, and is not driven by estimates. (higher estimates just mean increased demand on the team within those (2) weeks.

Forecasting out an entire backlog is decicdely _not_ agile. Agile is the ability to respond, reshape, and reprioritize based on the product owners needs, which are re-assessed each sprint planning session.

"The lack of ticket notifications is impacting more customers, and I would like that addressed before we begin adding the time-tracking features"

You are looking for a waterfall/frAgile project structure to drive out a fantasy Gantt chartt for management, and letting developers focus in smaller chunks of iterations.

There are a handful of Gantt plugins for JIRA that I think would meet your needs. https://marketplace.atlassian.com/search?application=jira&cost=&hosting=&marketingLabel=&q=gantt

EazyBI is a really nice general reporting solution. But there are also free and paid plugins focused on traditional PM and gantts.

Graeme Milligan February 12, 2014

sorry to disagree but a project burn down is a central part of any AGILE project and I find your tone a little insulting!

please check your facts before you add stuff like this.. as an example check out http://www.allaboutagile.com/track-your-agile-projects-with-a-project-burndown-chart/agile-project-burndown-chart/

I agree that a sprint burndown is useful in telling the project owner about the progress within a sprint but a project burndown is required to inform the PO as to the expected end date of the project!

By this I mean that I want to start with all of my stroies in the back log and set an end date. I then want a trend line to indicate what my velocity shoudl be (as indicated by the steepness of the line) in order to complete all stories in the backlog. I then want to chart my actual progress on a sprint by sprint basis to be plotted and the end date to be estimated based on this (as in the lnk above).

If you want another example check out the version chart in JIRA AGILE and you will see a burn-up of exactly the same information. All I need is to convert this to a burn down as this is what management are used to seeing.

EddieW
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 12, 2014

Still disagree. The idea of Sprint, Release, and Epic burndows are well known concepts and supported by the tool. Projects however contstantly change, with stories being added and groomed from the backlog based on need prioty and value.

I would not trust anything I read on that website.

To your point, Agile is about time-boxing delivery and focusing on the highest value items in that time. Not trying to drive out a list of fantiful estimates and dates before the developers get into the project where all estimates fly out the window if they were written months in advance.

Driving out expected progress for a given release is a much narrower and reasonable focus, and sure to be more accurate.

Graeme Milligan February 12, 2014

I am sorry but I still think you are wrong! I have trained a number of AGILE teams and have performed complex organisational change projects to introduce AGILE to several large organisations so I kind of know what I am talking about here.

Can you explain why this website is unreliable? or please do a search on google for project burndown and look at the images produced, this is a common concept to agile and is covered on the mountaingoat site (somewhere).

I am hoping we are talking on cross purposes and this is just a misunderstanding. Perhaps what I am talking about is the release burndown?

The whole point of a project burndown is to estimate the end point of the project i.e. how many sprints will it take to complete the backlog. This gives the PO the option to remove points from the backlog or to increase the velocity (by increasing team size or reducing quality (bad idea)) to allow him to meet a pre-defined end date. As you say this mean that the team focus on the highest value user stories and can drop the lowest priority stories when the burndown indicates they will not complete the backlog in the time available.

Hope this clears up what I am looking to do?

Dave Collins February 12, 2014

@GraemeI agree with your point that Eddie is being somewhat condescending, and actually doing nothing buy sniping quotes from some Agile website.

-------------

To my point, why I am here searching. It is ridiculous to have avaiable a Burndown chart for the Sprint that is underway and using the 'Agile Sprint Burndown Gadget', or the Report > Burndown Chart. The method that is utterly useless would be giving Story Points to the Parent OR the Task. They are not calculated with any logic.

eg: I have a User Story with 5 Sub-Tasks. I give the Sub's each 1 Story Point. The Parent should aggregate the Points from its Sub's to reflect the over all effort. Then, as Sub's are resolved, the reflection of that should reflect in the Burndown.

As it works now, only resolving the Parent will burn down the Story Points. Pretty silly.

EddieW
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 13, 2014
EddieW
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
February 13, 2014

Ok, consider this. Agile is about managing Products. And _products_ dont end!! The lifecycle of an appliation, website, server, document -- doesn't "end" until the very last user stops using it, or the company issues a Sunset/End of Life notice.

Releases have planned end dates, Epics have scoped features, and both can be rolled up into a cross-sprint burn down.

The article you refer to on mountain goat is a release burndown. http://www.mountaingoatsoftware.com/agile/scrum/release-burndown

But "projects" are a waterfall concept in my opinion because they focus so heavily on a start and end date (PMP defines both as a requirement of a 'project') and the triangle of constrain (scope, time, cost).

But a Product's ambition is endless, and have no planned end. Features are delivered based on their priority, as the team has capacity. The product is constantly growing, evolving, and delivering more value.

""The whole point of a project burndown is to estimate the end point of the project i.e. how many sprints will it take to complete the backlog""

The backlog should never (rarely) be empty unless there is not possible means to improve the product. Users and the team should continue feeding improvements into the backlog (continuous improvement is a core concept). You should be using Epic or Release burndowns to estimate when a particualr theme, scope, or set of features will be delivered.

Some teams continue to use Agile even if a product enters maintenance only mode. Kanban boards are ideal for this sort of delivery.

Brad Rosenberg May 14, 2019

Are you saying that Agile Scrum and Jira in particular should not be used for working on projects, @EddieW ?

Suggest an answer

Log in or Sign up to answer