Rally Software

 Using the Iteration Health app, we've run into an issue. Oct. 23, 2017 was a Monday, and the getDay() function is returning that as a 0 Date, and Sunday as a 6. Therefore the last Monday is being excluded from the iteration. Notice that the start date is 10/9/2017, and the end date is 10/23/2017, which is 11 weekdays. But the last Monday is not being counted and it is showing #Days as 10. The Last Day Completion Ratio and Last Day Acceptance should be the same in this instance, but that last Monday's Acceptance stats are not being counted as the 0 day results are being discarded. This is Rally's native app. We've modified it plenty and thought it was something we did but then I ran the original version and got the same results. Can someone provide some insight as to why this is happening please?

Stjepan,

From your screenshot the discrepancy you circled is on the Iteration above the Iteration that ends on 10/23.  Is that the screen shot you meant to post?

Michael

Yes, sorry, I just circled the wrong row for completion and acceptance ratio that correlates to the 23rd. But the issue is happening on every iteration, so any Monday would have this issue. (every weekday is always off by one)

In the log you'll see that since the last day, Monday OCT 23rd is being counted as Day 0, the acceptances that occurred on that day are not being counted in the ratio. Therefore the acceptance ratio is less than the completion ratio for every iteration, which in reality should not be the case. Most of the time they should be identical as we make sure to accept anything that's completed by iteration end.

The app is pulling data as if the iterations are ending a day early, which is the Friday before. So there's some issue in the native Rally app where the displayed Start and End Date (as column headers) is correct but it's not matching the data that's being extracted, which is incorrectly stopping on the Friday before. It displays Mondays generally correct as the last DATE of an iteration, but the data extraction stops calculating as of the Friday before based on getDay().

The only thing I can think of on our end is that our iterations overlap by one day. So the last Monday of one is also the first Monday of the next iteration. Is there an issue with concurrent iterations in the native rally apps not being supported? But that still doesn't explain why Monday is being counted as Day 0 and the entire getDay() function is returning values off by one. Or does it?

Stjepan,

Thank you for the confirmation and clarification.  I don't have the answer off hand, but I know who might.

morky01, can you weigh in on this question?

Michael

Misetic I think this is happening because of the timezone shift.  Iterations begin at midnight and end 1 minute before midnight in the default timezone of the workspace.  In this scenario, it looks like your timezone is 8 hours ahead of the workspace's default timezone so Sunday is calculated as the beginning of the last full day of the iteration, thus returning the 0 as the day of the week.  Also, since the iteration started on Sunday in your timezone (8 hours before midnight on Monday), then the first full day of the iteration was also a Sunday, resulting in 10 days instead of 11 days.   

This seems like it might be a bug so I would submit an issue to that repo.  In the meantime, I would modify the health utilities to take into account the timezone shift.

Kristy  

Thank you

corkr03 has the right answer.  My bet is it's a timezone issue- I bet this app was written prior to the changes around timezones we've made as part of the larger i18n/g10n effort.

This app is included in the community app catalog and the proper way to report these sorts of things is via a github issue as suggested above:

Issues · RallyCommunity/rally-iteration-health · GitHub 

Kyle

Thank you, I have opened up an issue on github