Why don't the PI and Iteration fields export cleanly from Jira Align?

[WRW26]

When you export stories out of JA into Excel (via .xml format) there are 56 fields that export.  The 'Program Increment' field does not export just the PI number, i.e. 1, 2 or 3.  Instead it concatenates the Program Name + (increment) Short Name + the start and end date in parenthesis.  It turns out looking something like this: My-Program PI3 (10/24 - 12/18). It does not export the simple single-digit 'Program Increment #' field.  So in order to sort or filter anything in Excel you have to first come up with a complicated formula in another field to parse out the Increment #.  This seems crazy.  Agile is all about Increments and Iterations/Sprints.  So why wouldn't the Increment field export cleanly without all the extra garbage?

Anyone who works with complicated Agile/SAFe projects has hundreds if not thousands of user stories to deal with.  Trying to track, analyze and report on these projects is not feasible in Jira Align alone and requires the help of Excel. I don't know of any RTE's, Scrum Masters, Product Owners, Architects, Testers, etc. that don't export data in to Excel on a frequent basis.  I am not sure why Atlassian has crippled us with the lack of data exported.

The same situation happens with the Iteration number.  It also concatenates several fields together in the export which requires complicated data parsing after the fact just to get a simple Iteration number like 1.2 or 3.4.

And lastly it also happens with the start and end dates for the iterations.  As you can imagine, a multitude of formulas and metrics key off the iteration dates.  But the dates do not export by themselves.  They export as concatenated strings as described above.  And they do not even denote the year.  So when you have a lot of project data over 2 or more years you cannot even write logical Excel formulas to surmise the year. This is extremely prohibitive.

From what I have witnessed over the last 6 months the above scenarios causes our large corporation hundreds of hours a month in copying and pasting data and writing macros just to deal with the simple fact that Jira Align does not export these fields in their simple form.

If someone knows of a way to remedy this then please let me know and excuse my rant.  But if there is indeed NOT a way to change this behavior then I have to wonder what in the world the developers are thinking not including the most basic Agile building block fields in the export - Increments, Iterations and Iteration Dates.

[Peter Jessen]

Hi @WRW26,

I am not sure why you are seeing what you are seeing, as this has never been an issue for me. I just did a sample export of some stories.

In my export, column K (titled Release by default and Program Increment in this instance) of the Story tab clearly shows the Program Increment Title field (ex: 2020.1). In my experience, this makes more sense that the Program Increment # field, because most organizations name their PIs in a logical manner, but don't always do so in the Program increment # field. Based on experience, most people know the PI name, but not the PI #. One option might have been for Jira Align to add both fields, but that seems a bit redundant with minimal value add.

By the way, the Program Increment # field is not a simple single digit field. It is an eight character alpha-numeric field. You can confirm that by navigating to Program -> MANAGE -> Show All+ -> Program Increments, then open any PI and check the Program Increment # field length.

Regarding the Sprint and Sync Sprint fields, they are clearly defined and there are recommendations for how to configure them. The concatenation you are describing is based on how the Jira connector is configured. Sprint names can also be modified in the Sprint list by Scrum Masters, Super Admins, and others with the appropriate rights.

I'm not sure what field you mean by Iteration Number. Are you talking about the simple one-up index field or the Iteration Short Name field? The index is worthless for exporting, as it provides no context. If five teams create five new sprints each in Jira at the same time, there is no guarantee their five sprints will each be sequential in the index, as Jira Align adds the sprints to the table (and the one-up index) as it crawls the boards. The Iteration Short Name field is a 15-character alpha-numeric field.

I've been doing complex data analysis in Jira Align and Excel with Jira Align data for four years now and have not personally run into the issues you are describing. While I certainly agree the export templates are not perfect by far, they are certainly far more useful (in my experience) than your post leads one to believe.

Have you and your organization explored using the Jira Align Leo BI functionality (https://agilecraft.com/bi)? Based on what you are describing, that may be an option that makes sense.

Regards,

Peter

[WRW26]

Peter, thanks for taking the time to write such a thorough response.  I appreciate it as I am still learning the inner workings of Jira Align.

I work for a large IT corporation and we have dozens of ARTs established in Jira Align under several portfolios.  Because I do reporting across the enterprise I am exposed to a large number of program setups by a variety of RTEs in Jira Align.  No matter which of these programs I export out of, I experience some of the same shortcomings without fail.  Now, maybe this has something to do with the setup of our instance of JA at the enterprise level.  And perhaps that is why I am seeing exports differently from you.  But I will try to more specifically detail my issues based on your feedback.

Your description of the Program Increment # field in JA setup is indeed in line with what I see and know.  It allows for 8 characters (alpha or numeric).  However, this field does not get included in the export.  Many of my program RTEs simply put a single digit number in this field for the PI.  So I would expect to see that same single digit PI # field in the export.  Instead Jira Align concatenates the Program Name field with the Short Name field and then appends the PI start and end dates in parenthesis (but with no year).  So instead of simply seeing ‘PI3’ or just ‘3’ in the Program Increment export field, I instead get ‘Project-Name PI3 (1/28 – 3/24)’.  This makes it very difficult to do reporting for many reasons: Very long headers, alpha-numerics do not sort properly, pivot tables do not make good assumptions with alphanumeric data, filtering is confusing for users not familiar with the program.  I truly understand your comment about many people knowing the PI name but not the number.  But many people also see it the other way around.  Why alienate those people?

When I referred to the iteration number I was referring to the ‘Sync Sprint/Sync Iteration’ field in the export.  Yes, scrum teams have the ability to name their own sprints uniquely, and this shows up in the ‘Sprint/Iteration’ field in the export.  But the ‘Sync Iterations’ is the same across all teams and is the cadence followed by the program for the PI.  For me this field is also exported as a concatenation of (Increment Anchor) Short Name + Iteration start and end date in parenthesis (again with no year).

Maybe all of this concatenation is related to what you referred to as the ‘Jira connector’.  Again, maybe our enterprise configuration is set up differently than yours.  I am not familiar with the ‘connector’ and will need to ask one of our admins.

One thing I am sure of, however, is that the export does not include fields that clearly identify the iteration start dates separately from the end dates. Those are combined in one field and do not indicate the year, just the month and day.  This makes it impossible to run crucial analysis on how far ahead or behind user stories are compared with their due date (the iteration end date).  I would be curious to know if in your exports you are able to see any fields that show the start or end iteration dates in mm/dd/yy format for each user story exported?

Again, thanks for your time above.  Jira Align is a great tool.  I just need to figure out how to work around some of its inconsistent implementations.