That sounds like a bug, please contact support (https://support.atlassian.com) for assistance.

I'm confused. I have a hosted version of JIRA and recently upgraded Greenhopper to 6.1.3.2. I see the check box on the Sprint Burndown chart to exclude non-working days, but it seems to have no effect for me even after adding the four weekend days within our current sprint as non-working within the Greenhopper Admin page.

Am I missing something, do something wrong or is this still broken?

Hi All,

Just a quick update on this: both burndown and (GHS-6128) and control charts (GHS-5118) now support non-working days.

Many thanks

Tom Kotecki
Product Manager, GreenHopper

Hurray, Greenhopper 6.1.1 fixes this. Great work.
https://confluence.atlassian.com/display/GH/GreenHopper+6.1.1+Release+Notes#GreenHopper6.1.1ReleaseNotes-SpecifyyourNon-WorkingDays

Hi Everyone,

Thanks so much for your votes and comments on this feature request, we wanted to provide an update on the status.

We know there are features missing from the new Scrum and Kanban boards. We plan to deliver the burndown (GHS-6128) and control chart (GHS-5118) aspects of this story within the next 12 months.

Just like any Agile team we have ordered the backlog based upon what we believe provides the greatest value to our customers. There are now over 10,000 customers worldwide so we try to find the right balance between the varied needs of this large, and growing, group. It is not an easy task. Thankfully we have many passionate customers that are able to provide feedback to help drive our vision and order the backlog - thank you!

Thanks for your patience, we hope that our open approach to feature requests and backlog ordering allows you to see where we are headed.

Cheers,
Shaun Clowes
GreenHopper Product Manager

We need this issue solved. Please give us a real solution or a date to be solved. We need to evaluate if we continue with jira or change to another tool.

NOTE TO ALL SUPPORTERS OF THIS REQUEST

Stefan Kalhofer (SAP), Stefan Höhn (CSC) and myself (Software AG) will be having a phone conference with Nicholas Muldoon from Atlassian on Thursday.

If you wish to influence a change, TAKE YOUR CHANCE NOW in supporting us.

Please express yourself with respectable comments and votes on GHS-6754 (As an Atlassian (enterprise) customer I request that Rapid Board fulfills some MUST HAVE requirements) and related issues.

Many thanks in advance.

Rainer Mueck

Update:

The meeting took place on 29-Nov-2012. There are no concrete results yet, but there will be a follow-up meeting in one week. So please stay tuned for more updates to come.

I wonder why the priority of GHS-3873 is minor.

At the moment, Rapid Boards are completely useless for SCRUM if weekends and non-working days are treated as normal working days. In other words, we pay a lot of money for a product we can not use!

Shaun, I support Kevin - this issue cause misleading in planning/controlling of the core of SCRUM framework and shall have at least High if not Immediate priority. It's not a good fashion working on cool new features when core is broken.

Just imagine the life of a SCRUM team that starts its 2 weeks sprint on Monday and has 1 holiday on the 2nd week of the sprint. The teams will be happily on track by the end of first week's Friday and will get completely distressed on Monday having no chances to catch up (remember there's also a holiday that RapidBoard displays as a working day). That team will get back to Classic Boards unless non-working days issue is fixed.

Shaun, I agree with everyone that this is an important issue to fix. I don't think the burndown is completely useless, but it really does diminish much of the value. I'm puzzled that GHS-6128 and the others are listed as minor stories. We like and have been using the recent improvements to epics, but my opinion is that an issue related to core functionality (that worked in the past with classic boards) should take precedence. Hopefully by breaking this story up, you will be able to start making progress on it soon. Thank you.

Please fix this issue.

Would love to see this issue resolved

Wow, GHS-3873 is there for more than a year! Does it mean there is no chance to have this one (5117) fixed within coming months, or months is too optimiztic at all?

I'm glad this is at least getting some frequent discussion/attention. We all understand that there us a limited amount of bandwidth and I do love all the other features that have been added. However the classic mode charts aren't an option because I think most people have switched to Rapid Board. Kudos there ... it's ten times better than the old boards. Faster, cleaner-looking, plus the issue preview saves a lot of time.

I do think this chart issue is a bit of a regression. If you were looking to have Rapid Board provide everything the old boards did, plus new features, this is one place where it's worse. My teams are all in one office and work M-F ... we actively discourage weekend work so as to keep people from seeking jobs elsewhere. So the charts look funny with the 2-day "flatline" in the center.

I echo Erwin's statement. Classic doesn't really work anymore with the new structure so we are really without accurate burndowns until this gets resolved. I'm already considering avoiding this feature altogether which sounds crazy given this is a MAJOR component to scrum/agile development. I really don't understand why this is regarded as a "minor" issue when it effectively makes the entire REPORT module useless.

Shaun - I trust you realize the importance of this feature. First of all, the new boards allow the management of one single backlog containing issues from multiple projects. Secondly, we meanwhile use the system attribute "sprint" (instead of a fixversion for each sprint / child versions). Going back to the classic approach isn't an option anymore (too late). You should know that.

From the very first day we knew that the boards aren't that flexible (such as adding/removing attributes to/from the cards) and hence we could prepare for it (the current approach works). But the removal of such an important capability wasn't obvious at all.

Thx.

Hi All,

I've corrected the permissions on GHS-3873 (excluding weekends from the CFD) so it can now be viewed.

Erwin: We work very hard to deliver the features that our customers need, unfortunately this issue is not the top one right now. To reiterate, we have not removed any functionality, the Classic Boards work exactly as they used to, if this is a complete showstopper for you we recommend continuing with the Classic Boards (which do have a concept of non working days) until this is implemented

Fabian: As above, we have not removed anything, Classic Mode is exactly as before, please continue using it if you wish.

Vermilian: We need to implement this functionality separately for each of the charts so there are three user stories (only the backend selection of which days are not working days would be common), like most Agile teams we make stories in terms of the value delivered to users.

Thanks,
Shaun

I understand that you are working on other more important areas right now and that's fine. But keep one thing in mind: This is something that worked in previous versions of Greenhopper but was removed in GH 6. Whoever made that decision should seriously think about it what it means to take away something that a lot of people had already been using and rely on. After reading the documentation I was sure that weekends can be entered via non working days - however, the option does not exist in the GH admin panel anymore.

Also, why is GHS-3873 not accessible?

I cannot open the 3rd ticket. In any case I find this splitting of the ticket very weird and strange.
Why would the weekends be taken into consideration in burndown charts but not in the control chart neither in the cumulative one?
Surely this should be driven by the same config and reflect the same info - weekends should be out, right?

Also why is this ticket rated major (after so many people complaint about it) and the new tickets (at least the 2 I could open) are rated as minor?

@ALL - Pls vote for the respective issues. Thx.

@Attlassian. Just to remind management. Jira/Greenhopper are (meanwhile) mission critical applications. We don't talk about Mickey Mouse usage. Maybe it would be worth considering to put a bit less resources in marketing (= less newsletters, fancy graphics and videos) but much more in functionality.

Thanks in advance for your suppport - Cheers, Erwin

Hi All,

We know that there is a lot of interest in this issue but unfortunately it does cover many different areas (i.e. the burndown, the CFD and the control chart).

• We have created GHS-6128 to cover the burndown charts
• We will use GHS-5118 to cover cycle time in the control chart
• We will use GHS-3873 to cover weekends in the cumulative flow diagram

I'd appreciate if commentary on these areas moved to those tickets.

As I've explained above, we are currently focused on other areas, specifically Epics and detail view configuration, which have been even more requested by customers than this one. We understand that this issue is important to everyone who has commented on this issue, but we have to juggle priorities. We do hope to do something on the burndown chart (GHS-3873) in the nearish future but I cannot provide timelines.

Thanks,
Shaun

@atlassian - this is getting ridiculous. What does it take to get a response from you and to make this actually happen? There is obviously huge demand for this!

We would love to see this fixed in the next version as well.

+1 This issue is critically important as it makes the whole Report Page inaccurate. I feel like I need a second tool (Excel) to calculate this now which is totally lame.

This also causes confusion for us. We'd love to see it resolved.

I agree with all the above comments.
We can't use the reports to assess if our our development in on time or not if rapid boards are expecting the team to work 7 days a week!
Please raise the priority of this ticket, I can deal with bank holidays and such as they only occur every now and then, but a simply weekends in or out must be an option.

Just on Friday I thought our development was on track (remaining time was under the guide line) and today (just a weekend in between) my rapid board is actually showing we are behind!

This is not minor issue indeed. Fix it please!

THIS IS NOT MINOR ISSUE! The priority needs an update. Projects need predictability. Predictability is aided by the use of Agile. Agile is what Jira is heavily based on. Therefore, if Jira does not help drive predictability, the value of the tool significantly drops.

Don't move us from Versions to Rapid Boards when your developing tech cannot support what it is designed to do. This is a critical feature. Please fix.

– duplicate removed –

Any update on this item priority in terms of other requests? Is there a place when this can be seen in a roadmap? Current number of votes (131) - is it not big enough in comparison to other requests?

Our team, too, has complained about this. Please correct this!

+1 This is the first thing all of my scrum masters complained about, even if we are in a distributed environment. We all work Monday to Friday in each office.

Development is complaining that the burndown charts are useless without excluding weekends. If this is an issue for distributed teams, then offer them a way to include weekends but let the rest of us exclude them!

+1 - this is an incredibly important issue that needs to get fixed soon. It makes it very difficult to use JIRA as an agile tool if the core to agile (the burndown) is incorrect. Please fix!

I have to agree with everyone - this is bigger than a minor.
I have to pull all the data and create Excel sheets to show current progress as the burndown is wrong
Really makes it a pain for everyone to see the accurate updates
I really hope this gets fixed soon

+1 for importance of this feature. We have evaluated and purchased GreenHopper based on version 5.9, assuming that Green Hopper 6.0 would be not worse at least, but it seems this is not completely the case. Our choise is now under question. I would say go for the easy option first - just make fixed weekends (all Saturdays and Sundays) out of the report, without yet considering holidays calendar and such types of things.

Shaun,

Without question, I can say that we viewed our burn-downs every day in stand ups... We used them as a gauge to see our progress at a team level, as well as executives creating dashboards to get a quick look at how multiple teams are doing. They were the pulse meter on our sprint. Now the teams and exec's are flying with a flawed dashboard or a lagging indicator at best.

With the new greephopper, reporting, mainly our burn downs, is so worthless we don't even bother showing them anymore at our daily meetings, if at all. Actually I showed one this week and the team laughed. If there's something on your chart you have to train yourself to "ignore" then it shouldn't be there. And with the previous version it worked just fine excluding non-working days. So there's plenty of talk and reasons for why things changed and why they are the way they are, but gauge your success by the results. It seems pretty clear in the above responses, that it's not working. Results for us are that we have stopped using the greenhopper burn down on all of our teams and it appears as though many other organizations are feeling the same results.

Hi Shaun

Everyone, including myself, appreciates the new features. My problem is I can't understand some of the prioritisation decisions. Possibly because we don't see all the user feedback and can only see what is written here. However, on this issue, put it this way, how would you assess an agile software tool that had not ability to report? While for some (and I suggest this is a minority) including weekends fits their working model; as you have suggested, some work weekends or are in different time-zones. But for the vast majority that have normal working weeks, Greenhopper has no reporting we can use. At least I am aware it doesn't work, as has been pointed out, many may not have realised that rapid boards CFD do not work like the agile boards CFD (which correctly excludes these days) and so are working on bad data.

In terms of agile, we can run the day-to-day with greenhopper, but we can't run the process. I have to build spreadsheets of data to capture metrics over time, it's time consuming and particularly annoying when there is a button that claims to do what I want.

Hi mikeohren,

The last thing I want is for you (and other GreenHopper users) to think that we are fighting you. We really do receive hundreds of feedback items every month and we try our hardest to prioritize the issues that will bring the most benefit to the most users (including those who don't know about voting in this forum). Unfortunately there will always be trade offs and sometimes issues like this one get pushed out by other important issues (for example Epics and Detail View configuration).

We really do listen to feedback. I think you previously sent us feedback via the 'Got Feedback' button, and I believe we've implemented most if not all of the items you mentioned, though I understand you probably disagree on this reporting front.

We are trying to be as open as possible in this forum. We know that people interpret silence from Atlassian on these issues as an indication of us not paying attention to the needs of our users but sometimes we simply have to say that we're listening but this issue is not currently top priority. To be completely open in the May timeframe I had been hoping to defer this issue until we were able to introduce a 'team' concept to JIRA so that a team could have working days (or even individual team members could have working hours) and those could be reflected in GreenHopper. This approach would be much more powerful and flexible than some sort of per board working days configuration. However, it is unlikely that a team concept will be implemented in the immediate future, which means we will have to revert to something on a per board basis when we address this.

We are trying to build a whole new experience, in the process we have to make some tough decisions about which features to implement first to bring the most value to the most users. I hope you like some of our progress so far, many users are loving the features we've recently implemented like card colours, detail view configuration, multi sprint planning, simplified workflows and automatic refreshing of the board on work mode. We move fast so we have a whole lot more coming, including improved Epic support which will by itself satisfy well over 200 votes.

We will definitely address this issue, please bear with us.

Thanks,
Shaun

I'm sorry Shaun. I have to disagree.

The reports are broken. Totally useless. This is not a feature request, it is a bug. No other reports work like this. So at the moment, Rapid Boards have no way of reporting.

I find it very disturbing that you are completely at odds with the users on these forums over two or three high voted issues. As product owner you should be representing us, not fighting us and it very much feels like you are fighting us.

Please stop fighting us, it's very unagile and not giving us much confidence in the direction of this product. I have already started assessing alternatives because you refuse to get some of the basics right. At the moment I am feeling pretty unhappy about Greenhopper and I know I am not alone here.

Hi deichling@riotgames.com,

I disagree that the sprint and kanban reports are 'broken'. We use them extensively here at Atlassian, you can tell because we even blog about the results we've achieved. Fundamentally this is about the difference between 'elapsed' time and 'available' time. The control and CFD charts do show accurate information but they include weekends, i.e. the elapsed time from the perspective of the person who logged the ticket. It's not true to say that this weekend time does not exist. In Kanban for example, the overall goal is still to drive down cycle time, one exceptionally good way to do this is not to have items in progress over weekends. Over time the cycle time will come to include the 'overhead' of the weekend.

In regard to burndown charts we simply look at the chart and know that the work remaining line at the beginning of the weekend should be at the same point as guide slope two days later. Of course, in some cases we have developers who will do some catch up work over the weekend or who are in other timezones, so it's important we see the 'weekend' time regardless as things might well happen in this period.

None of this is to say that we don't understand that many users would like to omit this time because they do not have multi timezone teams, never do any weekend work or disagree that cycle time should be measured from the perspective of the reporter of the ticket. We would eventually like to look at this issue but it is not high on the backlog at this time.

I am the product owner for GreenHopper so it's my job to prioritize the backlog, changing the description for the story is unlikely to affect its rank.

Thanks,
Shaun

Hi Shaun,

Thanks for replying to the thread, and I'm sorry if it came across as harsh but your recent reply was the only official reply to this issue other than the initial one of "We don't plan to address this." which came across as very dismissive of such an important issue.

I'll be frank in that I think Epic support is great and something that we need along with customizing the detail view, but it's a new feature where this item is actually a regression. I've given feedback through several of the channels you mention, but the problem was we were new to Rapicboards 3 months ago and frankly I wasn't even aware that this was an issue that we couldn't solve. I also don't think that people understand what kind of effect this is having in their sprint and Kanban reports.

Do you honestly feel that Greenhopper users truly understand that every Sprint and Kanban report for a cycle that goes over a weekend is BROKEN and actually incorrect?

I'm honestly very curious and would love a reply from someone at Atlassian on how you as a company deal with this problem as I'm sure you have agile cycles that go over weekends. How do you address the fact that burndowns aren't showing the correct slope? How do you compensate for the fact that control charts are going to be off 2 days for every issue not completed in the week it was placed in the queue?

If there aren't plans to address this issue from a product standpoint (which seems like a very basic feature request) what is your recommendation to all users of GH?

I think the way this is worded or being viewed could be causing some prioritization issues. What if you placed a story like this on the backlog and see how the team prioritizes it?

"As an agile team using Greenhopper I want accurate Sprint Burndown charts and reports (and/or Control Charts if we use Kanban) that accurately reflect team progress and metrics so that we can properly estimate and react during a sprint and aren't using false data to gauge future capacity."

Hi All,

We are not ignoring this issue and do hope to address it in the future, but it's not currently scheduled. We receive feedback from customers via a large variety of channels including votes/comment in this forum, support, Atlassian Summit, the GreenHopper feedback button, product analytics and our user surveys. We use all of this feedback to prioritize stories as well as fitting work where it makes sense as part of our overall roadmap (i.e. other features we're addressing at that time).

Your votes do matter and we do read every single comment and vote in this forum. We take your feedback very seriously. We regularly review the top voted issues.

When you see the comment about votes in the release notes it's almost always an underestimation as it doesn't take in to account the votes against the many duplicate tickets that get logged for major features or the feedback we've received on the issues via other channels than this forum.

At the moment we are working on Epic support and configuration for the detail view. Together these two items represent well over 300 votes. The other items we are releasing around these two major areas are either supporting stories for these features or smaller items that we can knock over more easily.

Thanks,
Shaun

+1 all across the board. I don't mean to be rude but this honestly is just a regression in featureset from the Classic Boards and I have some teams that refuse to move because of this issue alone. I understand holidays and things causing some trouble but there is absolutely no reason not to allow us to exclude weekends from working days so we get proper burndowns. The way this data is present right now is actually an outright lie as the slope of the "ideal burndown" is taking into account at least 2 days for us that aren't actual working days! Perhaps if we worded this differently Atlassian would take more care about this issue, because the real bug here is:

"Ideal trending lines in Rapid Board Burndowns are INCORRECT and lead teams to think they are doing fine in a sprint when in reality they are NOT!"

Does that sound more important to you guys than "we can't exclude weekends?"

I'm just baffled at how this is ranked MINOR. It's screwing up teams all over the world!

You also claim on every Greenhopper release:

"Your votes and issues help us keep improving our products, and are greatly appreciated.
Please keep logging your votes and issues. They help us decide what needs doing!"

In the last two you say you fixed issues totalling over 90 votes, THIS ONE ISSUE IS 90 VOTES ALONE!

Come on Atlassian, be honest with us and listen to your customers.

+1 on excluding weekends and ability to exclude other custom days as was available in classic. Thanks!

Come on Atlassian...this is a fundamental need! You really need to fix this asap! You tell us that 'Classic' is no longer being supported for new Projects, but you do not have all the needed functionality tied to the Radid Boards yet...really frustrating!

+1 that's a must have, I can't rely on greenhoper burndown chart without this fixed, which make me loss confidence on the tool

+1 here too.

This, to me, is the most annoying problem with the greenhopper plugin.

Might add that having configurable holidays or off-sprint days would also be great, but the weekends are a huge huge must.

This is a shockingly big miss, this totally negates the accuracy of a rapid board burn down. I've found work arounds for most of the other differences between the two systems but I can't switch with this working how it is.

+1 for excluding weekends. Now the graph fools us every time and we are left behind in the middle/end.

I think this should be higher priority and NOT Minor. Currently the Burndown chart is not evry helpful because of the inability to exclude weekends or non working days.

+1 for excluding weekends, especially for our 2 week sprints. Burndown looks ugly and irritating.

+1 for excluding weekends. This is very important to our sprint tracking.

This is very important for us, we need this functionality to show better reports.

If the burndown trajectory was segmented to reflect the weekends and holidays, the burndown chart would then be accurate.