Create
cancel
Showing results for 
Search instead for 
Did you mean: 
Sign up Log in

How extract the startDate and endDate of a future Sprint?

Doug Levitt March 5, 2021

Hi Automation for Jira Experts,

A colleague of mine -- using the Jira API -- has created a number of future Sprints, setting the startDate and endDate.

Then, after an issue is added to a future Sprint, I want to set 2 custom fields -- PlannedStartDate and PlannedEndDate based upon the startDate and endDate of that future Sprint.

This is easy to do, when an issue is assigned to only 1 Sprint.  However, occasionally some of our issues are associated with one or more previously closed Sprints (as the team didn't finish the work in the originally planned Sprint).

As an example, below is the JSON from such an issue:

"customfield_10006": [
{
"id": 2579,
"name": "AgileExample 149 (ends 7/27)",
"state": "future",
"boardId": 260,
"goal": "",
"startDate": "2021-01-01T00:00:00.000Z",
"endDate": "2021-01-02T00:00:00.000Z"
},
{
"id": 2246,
"name": "AgileTest 2",
"state": "closed",
"boardId": 260,
"goal": "",
"startDate": "2021-01-03T20:14:00.000Z",
"endDate": "2021-01-17T20:14:00.000Z",
"completeDate": "2021-01-26T18:38:47.127Z"
},
{
"id": 2278,
"name": "Snoopy 242 (ends 1/17)",
"state": "closed",
"boardId": 260,
"goal": "This is the sprint goal...",
"startDate": "2024-01-03T20:00:00.000Z",
"endDate": "2024-01-17T20:00:00.000Z",
"completeDate": "2021-01-30T00:23:16.746Z"
}
],

Things would be simple if the "future" sprint was always the first in the list (or the last in the list).  As then I could use list.first or list.last function as described here <link>.

However, after some testing, I realized that there is no guarantee where the "future" Sprint will occur (and hence I don't know which element in the list to pull the startDate and endDate).

Question - Is there a way to "walk" the JSON object, looking for the startDate and endDate matching the element where state = "future"?

Thanks!

Doug

 

2 answers

0 votes
Bill Sheboy
Rising Star
Rising Star
Rising Stars are recognized for providing high-quality answers to other users. Rising Stars receive a certificate of achievement and are on the path to becoming Community Leaders.
March 8, 2021

Hi @Doug Levitt 

What do you plan to do with PlannedStartDate and PlannedEndDate, and when do you plan to use that information (relative to the sprint start timeframe)?

For example, if you do not plan to do anything until after the sprint starts/completes, you could just set the values based on the trigger Sprint Started.

However, if you want the information before the sprint runs, you definitely need to get the data from the REST API.  The sprint startDate and endDate do not appear to be available in the smart values within automation rules until the sprint begins.

Perhaps instead you are calling the REST API with a webrequest from within a rule...Once you have the complete sprit information, you could probably use match() and RegEx to pull out the Future state sprints.

Best regards,

Bill

Doug Levitt March 8, 2021

I plan to render the dates in Advanced Roadmaps. 

I am planning to set the Adv Roadmaps Start Date to the date a Story went in progress, if set.  Otherwise, I will set to Planned Start Date.

I am planning to set the Adv Roadmaps End Date to the date a Story is marked done, if set.  Otherwise, I will set to Planned End Date.

As a note, I have implemented a "sort of" solution.  It's kind of a hack.  I am setting Planned Start date to: {{issue.customfield_10006.startDate.max}} and Planned End date to: {{issue.customfield_10006.endDate.max}} - Basically, I am assuming that the closed sprints have an earlier date (than an open or future sprint).  Generally speaking that should be the case.

Like Bill Sheboy likes this
Darryl Lee
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 8, 2021

Oh that's a good hack. Glad you figured out out.

Dave
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
March 8, 2021

Hi @Doug Levitt ,

I'm on the Advanced Roadmaps team and I'd to understand your use case for this feature further. Something that I've been keen for us to add to Advanced Roadmaps is to have an additional bar on the timeline to show when issues transitioned into and out of an "In Progress" workflow states (the idea being that you'd be able to compare when you planned work to happen with when it actually happened). It sounds like this is sort of what you're trying to do here? (except you're going to capture the actual dates to replace the planned dates). I'd love to understand further about why you want to do this.

Also, additionally I just wanted to check that you were aware that there is a configuration setting on Advanced Roadmap plans that allows the roadmap to show the start and end dates of issues based on the sprints that they were assigned to. I thought that was worth mentioning because it also sounds somewhat related.

Regards,
Dave

Doug Levitt March 8, 2021

Hi @Dave 

So - a caveat.  I am not an expert in using Advanced Roadmaps.  I have seen several videos and have played with it for several hours.  It seems like it can be a useful tool for visualization - of both timelines (using a Gantt chart) and dependencies.

I want the Gantt chart to display for Epics + Stories:

a) If the Epic/Story hasn't begun, show the Planned Start Date.  If the Epic/Story has begun, show the Actual Start Date

b) If the Epic/Story hasn't completed, show the Planned Completion Date.  If the Epic/Story has completed, show the Actual Completion Date

Note: The term "Planned Start Date" and "Planned Completion Date" is probably the wrong term.  Think of it as the bands (for earliest start and latest end date). 

We essentially schedule "Release Trains" every 8 weeks (basically 4 sprints, I am trying to rally the troops to do this every 4 weeks).

A "Release Train" is assigned a Version.  A Version has a Start/End Date.  Each Epic goes into a Version and inherits the Start/End Date (as "Planned Start" and "Planned End").  If an Epic is too large, it gets split, part in Version 1, part in Version 2.

An Epic is a container of Stories (and Bugs).  We pre-allocate the 4 Sprints for each Release Train.  We are using Jira API to set the start/end date for future sprints.  It's annoying you can't do this via the GUI or Automation.

We assign the Stories (and Bugs) in an Epic to 1 of the Sprints in the Release.  Each Story inherits the Start/End from the Sprint (as "Planned Start" and "Planned End").  If a Story is too large, it gets split.

With this arrangement, I replan NOT by dragging start/end dates in Advanced Roadmaps.  I really want to avoid that (as that introduce conflicting information).  Imagine if I changed the dates of an Epic, but it stayed in the wrong release.

Instead, I will update the data in Jira and use Adv Roadmaps for visualization.

I would be more than happy to explain in more detail (say in a call).

Doug

Like Dave likes this
Dave
Atlassian Team
Atlassian Team members are employees working across the company in a wide variety of roles.
March 9, 2021

Thanks for that detailed explanation @Doug Levitt - much appreciated!

It sounds like you're using a Release / Version to represent something similar to a Program Increment? This is one of those situations where probably having a hierarchy of iterations in Jira would be incredibly useful.

It sounds like you can have multiple epics in each your release trains? Rather than assigning dates I wonder if just assigning sprints to issues (and using the ability to infer the start and end date of the issue from the assigned sprint) would help, you can then also set a plan to "roll-up" the dates from child issues to its parents - this would mean that you wouldn't have to assign dates directly to an epic necessarily. If the epic was assigned to a release then the release marker on the timeline would be modified to indicate when it was off-track (i.e. because the epic end date extends beyond the release date).

I'm also wondering whether the auto-scheduling functionality provided by Advanced Roadmaps might help as well here. You would lose some of the manual control you have but by assigning epics to releases and giving them a start and end date it would try to fit the stories into the available epics. If you give the release a start and end date then it should potentially achieve what you're looking for.

I just thought I'd share that as food for thought. I can reach out to one of our PMs and see if they're interested in setting up a call to discuss your use case as it sounds like it might be overlapping with some additional concepts that we're looking into,

Regards,

Dave

Doug Levitt March 16, 2021

Hi @Dave 

Assuming the following, how would your recommend we set things up:

a) We have Agile Release Trains which include a set of Epics

b) Each Epic must fit into a single Release.  If the size of an Epic is too large (to fit into a Release), the Epic is split

c) A Release (i.e. Fix Version) is associated with a Start Date and Release Date

d) Each Epic is assigned to a single Fix Version

e) An Epic contains PBIs (Stories, Bugs, etc.) that also exist in that same Release (aka Fix Version)

f) Within Advanced Roadmaps, we want to display an Epic's actual Start Date if that Epic has started (we set the Start Date using Automation for Jira when the first PBI is started) and display an Epic's actual Finish Date if that Epic is Done (we set the Finish Date using Automation for Jira when the last PBI is completed) 

g) Within Advanced Roadmaps, we want to display the Epic's planned Start Date if the Epic has not yet Started and the Epic's planned Finish Date if the Epic has not yet Finished).  The planned Start Date and planned Finish Date will be based upon the Release (aka Fix Version) the Epic is assigned to.

h) We can do the above (display one date or another, by introducing a new Custom Field - Advanced Roadmaps Start Date and Advanced Roadmaps Finish Date).  We use Automation for Jira to populate both.  It sets to Actual (if set)  Otherwise, it sets to Planned.

i) The PBIs will be assigned to Sprints.  It's possible that some PBIs assigned to an Epic may not be assigned to a particular Sprint.  As an example, someone forgot about a PBI needed to complete a Feature (aka Epic) and its agreed it must be included in that Release

j) We want Advanced Roadmaps to "figure out" when the Sprints will occur.  If a PBI in a Sprint occurs after the Epic's planned Finish Date, we would see a warning.  Theoretically, a PBI should not be in a Sprint which occurs after teh Epic's actual Finish Date.

k) We do not want to change the start/end date of an Epic by dragging the timeline in Advanced Roadmaps (as that breaks our entire model).  Wny?  Essentially, we are moving the Epic without actually editing the underlying data (the assigned Release).  Rather, we want to change the start/end date of an Epic by assigning it to a different Release.  That would be a cool feature in Advanced Roadmaps.

l) We are doing the above across 20+ Teams

m) We originally plan to use this for visualization and dependency management

Again, if you have suggestions, we are quite open.  Also, I am move than happy to speak with you directly if you are curious about how real customers (who are trying to "be" as agile as possible) are using your products.

 

Doug Levitt

Agile Coach

0 votes
Darryl Lee
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 6, 2021

Huh.

I was reading "How can I iterate through a multi-select field in an Automation for Jira flow?" and thought, huh, would there be a way to keep "popping" sprints off of a copy of the "stack" until you hit the one with future? 

Like say you assigned {{checksprint}} to {{customfield_10006}}

And initialized {{futuresprintid}} to ""

Then did something like:

IF {{check.first.state}}="future" block...

THEN set {{futuresprintid}} to {{check.first.id}}

ELSE

Advanced Edit, and remove the *first* element from {{checksprint}}, using the the "update -> remove" function?

---

The thing is, I think this will only run once, as there's no outer WHILE check.first.state !="future" loop or anything like that.

I guess you could code it as a series of ELSE-IFs for the maximum number of Sprints you think users might select for an issue?

It's ugly, but hey, that's what I do. :-}

Darryl Lee
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 6, 2021

The original poster wrote:

You can use "re-fetch issue data" and continue the rule if there are more "Teams".

The other option is to change a different field so it will run a different automation rule as long as "Teams" is not empty.

Hrm. I kind of don't think re-fetch issue data is going to refresh a smart value variable.

But maybe the idea of using a different field to store the temp value would work.

Sorry, have some other stuff to play with today so I can't test this out for ya.

Doug Levitt March 7, 2021

@Darryl Lee Thanks for your response.  I am somewhat surprised they didn't provide a way to interrogate a list structure (to find a particular entry in the list).

Darryl Lee
Community Leader
Community Leader
Community Leaders are connectors, ambassadors, and mentors. On the online community, they serve as thought leaders, product experts, and moderators.
March 7, 2021

Hey yeah, it'd be nice if there was a method to filter or select.

Oh look, there's bugs filed for this:

https://codebarrel.atlassian.net/browse/AUT-1241

https://jira.atlassian.com/browse/JRACLOUD-76040

Doug Levitt March 7, 2021

@Darryl Lee - Thanks.  I added a comment to JIRACLOUD-76040, documenting a use case.

Suggest an answer

Log in or Sign up to answer
TAGS
AUG Leaders

Atlassian Community Events