Issue Burdown Chart, Ideal Issue Burndown: How it is drawn?

Lucas Brugé

We're using Jira with Greenhoper, and we've ended our first sprint ok, with no problems on this matter.

But on the second one, we're getting a wrong 'Issue Burdown Chart' because we don't know where messed up with the issue creation. We've an 'Ideal Burdown' (the redline) that's show only one Issue for the spront (I think that's the one that we have to finish on this second sprint from the first), but the issues we've created for this sprint (51) are all detected as 'New Issues' (blue line). We want that some of thess Issues (the ones that conforms our product backlog for this sprint) conforms the redline (ideal burdown), and some othres not (as new issues).

Sorry if it's too basic, but I can't find documentation on this, and I don't know we're messed up.

Thanks in advance.

Lucas

Lucas Brugé

There's no way to do it for moment. The altassian team told me that it's a limitation of product by now (http://confluence.atlassian.com/x/2I6EDQ): "As mentioned above, since GreenHopper assumes that the planning of a sprint is completed no later than its start date, the initial 'Number of Hours' values of the green and red curves (at x=0) do not change. This is done deliberately to indicate if the accuracy of time estimates needs improvement during the sprint planning phase."

I'm ok with that, we all must to complete the sprint backlog BEFORE it begins, there's no question about it. But some times we can't change start date of the sprint (it would be false for all kinds of metrics and/or to our client), and I wouldn't like to instruct the teams to file all the issues on weekends or in extra hours (that was our case) to meet greenhooper's needs . I think that this situation may ocurr on different teams, specially in teams (like us) who are learning this methodology (and Greenhooper).

Another little detail, it's that the reference that altassian gave me, it's from the latest Greenhooper's documentation (5.8); and as a nerd I am, I was looking on the 5.0 documentation, which is the version we have and it lacks of that information.

As Altassian suggested me, I'll like to propose this as a new feature: The ability to "declare" which Issues conforms the sprint backlog... it's no so rare that some one in the team "forgets" to file an Sprint Backlog Item (Issue)... and some times our clients, may have internal issues too...

Regards.