Project Burdown in Greenhopper

[Ryan C Meinzer]

How can I get a burndown by project using story points? We do not have assigned versions, we are only two sprints in, but I would like to see a project burndown.

[Deleted user]

https://jira.atlassian.com/browse/GHS-9063

This was requested here. And since Atlassian won't let me change email addresses, and I changed jobs, I dont have access to this question any longer.

[Midori]

+1 ... many valid points are raised here.

In case you need a short-timeframe solution and can't wait until all these get implemented in Greenhopper (ah, sorry, JIRA Agile), consider coding them with the JIRA PDF View Plugin. It is shipped with a simplistic "burn down chart" template to use as starting point.

You can merge any arbitrary set of issues with that template, so you can get the burn down on any granularity: per project, per version, per sprint, per anything that can be coded as a JIRA filter.

Also, you can compute the burn down in mere issue count (this is how the factory default template works) or in story points (requires some scripting).

Burn Down sample PDF

[Olga Tenenika]

+ 1 from our company

[Doug Varn]

I'm a fairly new GH user and this is killing us as well.

[Ryan C Meinzer]

I tried poking atlassian on this, a long time ago, but nothing came back. I just dont understand how we dont have a simple SCRUM dictated project burn down.

[David Witherspoon]

Ryan - The new Scrum boards released 'officially' on 5.10 do exactly that. They get away from having to use versions as sprints. If you are still using task and planning boards you should look to migrate away from them to get what you need with the tool

https://confluence.atlassian.com/display/GH/GreenHopper+5.10+Release+Notes

[Ryan C Meinzer]

Ok I totally agree and we are not using versions as sprints in the new versions. Hence missing the Project Burndown ability. Like I told Darren, it would be great if Greenhopper could do that using the actual sprints instead of the versioned method.

[Alastair Bain]

We need this as well (a whole project burndown chart), using the new version of Greenhopper (V6.01). It's very confusing for our users currently, they can select "Greenhopper Burndown Chart" from the dashboard gadgets but it doesn't function correctly.

[Greg Stumph]

In an ideal world, what we want is the following:

- A way to display a story-point burndown for an entire release in a Rapid board chart (Fix Version is probably still a good metric for this, as long as we can set the start/end dates for the chart somehow).

- Burndown by Issues chart in Rapid board

- The ability to display any/all Rapid board charts in a Dashboard.

[Greg Stumph]

The problem is that in Classic mode, you can use the Statistics Burndown Chart in Story Point mode to view a burndown for an entire release, based on the date ranges of a Fix Version. You can't do that in any of the Rapid Board charts. Also, we used to use the Issue Burndown Chart in Classic Mode to view a burndown by Issue for a single sprint. That's also not available in the Rapid Board charts (no matter what estimation method you use for the board).

We're using Greenhopper 6.0.8, and this is our current process:

- Set up Fix Versions on the Classic Planning Board with the appropriate date ranges for our releases.

- Assign the Fix Version for all Stories in a release as appropriate

- Use the Rapid Board to create Sprints, and assign stories to them. (We use Fix Version filters to manage the backlog in Plan mode, so we can see just the stories for release 3.0, or 3.5, or 4.0, etc.)

- For intra-sprint progress chart, use the Cumulative Flow chart in the Rapid Board (acts as a "burnup" chart for issues and sub-tasks). Problem; you can't use this chart on a Dashboard.

- For project burndown chart, use the Statistics Burndown Chart by Story Point chart in Classic mode.

Obviously this is pretty klunky, and we'd prefer not to have to use the Classic mode at all. Another concern I have is that the only way to set start, end, and release dates for a Version is on the Classic Planning board; you can only set an end date for a version via the Admin/Projects/Versions UI. So if/when the Classic mode goes away completely, there won't be a way to set start/end dates for a Fix Version (but I suppose that won't matter so much since the Classic charts would be gone at that point anyway).

[Darren Martz]

If you are using the classic greenhopper (plan/task/chart are separate menu options), then you need to setup a heirarchy of versions. Each version is a sprint with the root version being your ship version with a targetted ship date. The charts will project to the ship date if you choose that root version.

> Construction (start/end dates)

> > Sprint 1 (start/end dates)

> > Sprint 2 (start/end dates)

> > Sprint 3 (start/end dates)

If you set that up, the charts work well. If you do not put in the dates, the charts do strange things. The heirarchy can be setup at any time inside the cards on the right side. The default is "parent: none".

You also get a velocity bar graph showing each sprints story point velocity over time.

The key is to use versions for sprint tracking.

[Ryan C Meinzer]

Darren,

Thanks for the input. From an Agile standpoint, that is crazy as that is NOT Agile, even a little.

That said, I understand how you are setting up the work around. Too bad Greenhopper can't do this using the actual Sprints. Perhaps in the future!?

Rally and Collabnet both support this very basic Agile chart.

Thank you again.

[David Witherspoon]

Ryan - Don't think you've provided enough detail to get a qualified answer. What version of Greenhopper are you using? If you are using an older version "fix version" is what it's going to be based on. The newer releases have sprint reporting more fully integrated

[Ryan C Meinzer]

Sure thing David,

Version is 5.10.5.

Looking for a burndown for the entire product, not one based on versions. We have not assigned verisons as we have not decided on a release point yet.

We are ending our 4th sprint tomorrow, and I would like a project level burn down of all the work done vs all the work in the PBL. So, not a release burn down, but a project burn down.