Caching issue with Release drop down on Kanban Board

[Cory Archer]

Our users have noticed a missing release in the Release time box drop down in one of our Kanban boards.  It appears to be a caching issue because if they refresh the page or click the left/right arrow on the time box, the value shows up.  We've not experienced this issue until this week, so wondering if something has changed with the configuration.  

I've attached a screen shot for reference.  

Attachment(s)

Rally Caching Issue.docx   118 KB 1 version

[System]

Hey @Cory Archer, what dates are this "Maintenance Release" set for and on which project? I can't tell exactly what's missing from your screenshot without seeing the Release on the Plan --> Timeboxes page. ​

------------------------------
John Streeter
Customer Support Lead | ITSM & Rally Software
------------------------------

[Cory Archer]

Hi @John Streeter, the start date is 1/1/2019 and then end date is 12/31/2019.  I've attached another screen shot showing the time boxes I have set up.  The project is Release Management.​  The "Maintenance Release" option is there, it's just that it doesn't always show up in the drop down unless you refresh or toggle through them individually.  It seems like I can't all my time boxes to show up in the drop down at the same time.

Attachment(s)

Rally Releases.docx   361 KB 1 version

[System]

Hey @Cory Archer thanks for the additional info. 

So the reason that Maintenance Release isn't showing is because it's not deemed a "current' nor "near future" release ​in comparison to the other releases. That dropdown only shows 6 releases at a time (for performance reasons) so it chooses the most likely selections. 

I would guess that since your Maintenance Release started way back in January, it won't show up typically unless you search for it or it's the currently-selected release.

------------------------------
John Streeter
Customer Support Lead | ITSM & Rally Software
------------------------------

[Cory Archer]

Ok, thanks for the info @John Streeter.  If I did want it to show up all the time, would you recommend I keep adjusting the start date forward on the release each month?  I really didn't want to make a bunch of maintenance time boxes because that would clutter the drop down.  ​

[System]

I guess it depends on what you're trying to do with those releases. What is the use case for assigning items to the Maintenance Release if it's not a true timebox? 

I would think that having timeboxes that more accurately reflect the work that your teams are doing would be far more useful and worthwhile than a "placeholder". Plus, some of the other functionality like Capacity Planning, Release Tracking, etc etc doesn't really work well when you don't use the release with a real timebox. 

If you set the Maintenance Releases to reflect accurate dates of those releases, they wouldn't be too cluttered in dropdowns - they would rather show along with those other releases.

------------------------------
John Streeter
Customer Support Lead | ITSM & Rally Software
------------------------------

[Cory Archer]

Your points are valid for normal Rally use cases.  Our use case is not typical.  We have monthly releases that are scheduled and known a year in advance.  Those are the monthly release time boxes you see in the drop downs.  However, we also have ad hoc "maintenance releases" that occur throughout the week, and those release dates are not known until someone comes to me and says "I need this application released tomorrow."

To address those ad hoc releases, I created one annual Maintenance time box to tie all those stories to so we can facilitate getting them to production. Once they are released to production, I re-assign them to the Archive release time box so they are out of the normal maintenance time box view.  

I know this is not how the standard releases functionality was set up to work, but it was the best we could come up with for the ad hoc requests without having to mess with the time boxes the scrum teams are used to working with.  

Also, it's probably important to mention that all of the scrum teams work within a parent project called 'TIG Scrum Teams'.  I set up a new project outside of TIG Scrum Teams called 'Release Management'.  Release Management is where I do all the release tracking and release time boxes. 

I think you've given me all the information I need regarding why the time boxes aren't all showing in the drop down.  I think we'll just have to work around that since we are handling our release management outside the normal Rally standard.

Thanks for your help!

[Matt Seitz]

Short answer:  for tracking application delivery events, use Milestone timeboxes, not Release timeboxes.

In the Rally data model, Release timeboxes are fixed, internal timeboxes, just like Iterations.  Rally wants you to use Milestones to track when new versions of software will be released to customers, and which Features or User Stories will be included in those customer deliveries.

[Matt Seitz]

And yes, the name "Release" for these fixed internal timeboxes is confusing.  Originally, there were no Milestone timeboxes, and the Release timeboxes were also used for tracking customer deliveries.  But people ran into the same kinds of issues you are running into.  So Rally added the Milestone timeboxes for tracking customer deliveries.

Now, the "Release" timeboxes are meant to track fixed timeboxes with larger scope than Iterations, usually a few months long.  They are meant to fulfil a purpose similar to the "Program Increment" in the Scaled Agile Framework (SAFe):  https://www.scaledagileframework.com/program-increment/

I have been told that Rally has considered renaming the Release timeboxes to make it clearer that they are not meant to track customer deliveries.  But that would involve changing terminology that long-time Rally users are accustomed to, and a lot of code and documentation changes.