I was wondering if there is a way to show the different types of burndown charts from the classic boards on the rapid board. To me it seems like there is only one burndown chart available and to see another measurement I have to reconfigure the boards estimation.
Am I missing something, or is there really no way the get the classic boards behaviour?
Thanks in advance,
We've tried to streamline it so that users say upfront how they want to burndown so they don't get a bunch of options that aren't relevant to them when they go to look at their burndowns.
In the future we'd like to add addition 'Refine' options to the chart so you could potentially change the chart interactively, but for now I'd recommend creating a second board, you can then quickly swap between the two boards using the Agile menu dropdown.
You can change the "Estimation" setting in the configuration of the board to time tracking and then get the hour burndown.
@Shaun Clowes [Atlassian]
So basically you are saying "users could be stupid, so try to not confuse them". I think Atlassian is going a strange way here with the rapid boards.
After being forced to show them more prominently in 5.1 and encouraging my users to use them, I get questions on a daily basis like "this was easy in the classic boards, but how to do that on the new boards". Sadly most of the time I have to say "Sorry, I hope that will be included soon..."
Thanks, but I have my board set to use Story Points as its "Estimation Statistic" and "Remaining Estimate and Time Spent" for Time tracking and I'm still getting a point burndown. If I change the estimation statistic the graph is unchanged. Does it only take effect on new sprints?
@Thomas H.: That's actually the opposite of what we're attempting to do, we're trying to allow teams to define boards that work exactly the way they do without requiring individual users to configure things.
In this case, most teams decide how they plan to do estimation and burndowns in advance. In fact, they must do so because they need to apply estimates and potentially breakdown tasks and hours in order for the charts to be able to display that information. So basically the new boards ask you to configure the way you want to do estimation and tracking in advance, this allows us to provide a warning when the sprint starts if those bits of information haven't been filled in as well as preventing the need to ask the user what unit they want for the burndown because the team has already decided what it is.
The behaviour of the classic boards in this area is very unintuitive. Why should every user in a team that accesses the chart board have to work out which sub-board and estimation unit that the team is using? That's all pretty much pre-known based on how the team works.
Our user survey shows that the majority of users do pick an estimation and tracking unit then stick with it, so we hope that the need for switching the units of the burndown only affects a small set of users which is why I'm suggesting the workaround of using multiple boards.
I'm not sure if this particular issue is one that you refer to when you comment about your users saying "this was easy in the classic boards, but how to do that on the new boards". We're certainly working on improving the new boards daily, there will always be some parts of the old boards that users miss, but we hope that the advantages will outweigh the disadvantages.
My team currently has two issues somewhat related to this. We estimate based on Story Points, but track remaining time. In our world we work in "days". When estimating the Story Point value we loosely relate a man-day per story point. We load up our sprint based on total story points and team capacity. When we build the sprint we populate the Remaing time of each story using units of days accordingly. They may or may not match the initial story point value.
So my first issue is that even though all our remaining time estimates are in units of days, the reports show hours. We find hours very confusing to deal with since 5.5 hours is a day. We just don't work that way. We would much rather see, 1.5d or .2d or whatever as long as everything shows with a "d" at the end. Having a config feature of the rapid board tell the reports to show time in days would be great, and I can't imagine that beigng too difficult.
The second issue deals with user stories that don't get completed and need to move to the next sprint. When this happens, the Story points are the original estimate, but the remaining time could be small (ie., it was almost done). This messes up the aggregates in planning mode and we need to manually compensate for this when loading up the sprint. Not sure if anything could be done to address this, but I just wanted to point out that it's an issue.
For our teams, we estimate by Story Points, but had been using the Issue Burndown chart on the Classic Chart Board to track intra-sprint progress (we don't track actual hours spent). We were also using the Statistics Burndown Chart in Story Point mode to track the progress of an entire release.
Neither of those charts is available in the new Rapid Board. For the time-being, we're using the Cumulative Flow chart for intra-sprint progress, and resorting to the Classic Chart view for the burndown chart for an entire release. It's frustrating that for all the UI improvements of the new board, key features like these chart views are not available.
Lack of Dashboard integration of the Rapid board charts is also frustrating. We have an overview dashboard that shows the burndowns for all projects in a single view, but it uses the older Statistics Burndown Chart.
I’m a designer on the Jira team. For a long time, I’ve fielded questions from other designers about how they should be using Jira Software with their design team. I’ve also heard feedback from other ...
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!
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