Advanced Roadmaps - Option to "Use sprint dates when issues don't have start and end dates"

[Doug Levitt]

I am curious how people are using the "Use sprint dates when issues don't have start and end dates" feature in Advanced Roadmaps

It seems quite useful.  However:

We would prefer, when a Story begins, to track its Actual Start Date and then have Advanced Roadmaps calculate its end date (based upon sprint dates).  But it appears like both the "start date" and "end date" must be empty for this automatic calculation. 

Anyone know why?

Let's give an example.  Imagine I had a "Story" that began in Sprint 1, but wasn't finished.  Now it's in Sprint 2.

If I leave the dates empty, Advanced Roadmaps will show this "Story" starting with Start/End dates from Sprint 2.  Which is not accurate.

However, if I populate the Start Date (with its actual Start Date), then Advanced Roadmaps leaves the End Date unset (even though it could inherit the End Date from the end date of Sprint 2).

I am curious what people actually do for these dates.  As a note, we have no intention of anyone changing the dates in Advanced Roadmaps itself.  As that will generate other issues (based upon the way we currently use Jira).

Thanks,

Doug Levitt

Agile Coach

[Dave]

Hi @Doug Levitt,

The behaviour isn't exactly as you've described as you've not included the impact of the issue state. If an issue is in Sprint 1 and moved to an In Progress status but is not resolved before the sprint is completed then the dates shown on the roadmap will span all sprints until the issue is resolved.

See this example screenshot:

Here you can see that "Issue1" spans both "IC Sprint 1" and "IC Sprint 2" because it has been started but not finished.

In your example, if you didn't actually start working on the issue in Sprint 1, why would you want the start date to indicate that you worked on it in Sprint 1? If you have started work on the issue then the expectation is that it would be moved to an in-progress state and then the dates would be reflected to incorporate that sprint.

At the moment we expect users to either plan based on sprint assignment or with dates (for each issue) but not both and I believe this is the first time I've heard any request for this to change.

Typically I just use sprint assignment (combined with roll-up dates) to generate the roadmap for my team but I do occasionally set a specific start or end date when something needs to be started or finished at a specific time.

There is a school of thought that agile teams should really only be planning to the granularity of sprints, but we recognise that this won't necessarily meet everyone's needs (and wouldn't be possible with Kanban teams).

Dates based on sprint assignment also work well with how teams might move issues on a backlog - this means that dates can be inferred independently of the planning team.

At the moment there are no plans to combine sprint dates and date field settings with how an issue is rendered on the timeline. The only exception to this is if you change the plan configuration so that "Due Date" is not used as the end date of the issue. In this case "Due Date" can be used as a deadline and a warning will be shown if the sprint assignment indicates scheduling beyond that date.

Regards,

Dave

[Doug Levitt]

@Dave - Thanks for the reply.  I now better understand how you were envisioning that the tool would be used.

One of the things I was trying to do was display the Actual Start Date on the timeline.  As an example, say the Sprint started on Mar 1 and ended on March 15.  And Story #1 began on Mar 8, I want hoping to depict that (on the timeline).  I can partially do that (by setting a Start Date using Automation, when Story #1 moves into "In Progress").  However, Adv Roadmaps won't infer that the "worst case" End Date is March 15.  I guess I can use Automation to set that as well, but it's a bit of a pain (because there are a bunch of corner cases to account for).

So, maybe I need to "punt" on having an "exact" Start Date (the Start of Sprint is not that granular, particularly on a 2 week Sprint).

Thanks,

Doug

[Dave]

@Doug Levitt- by actual start date are you looking to see the date that an issue change state from a To Do status to an In Progress state? If so would you want to display this to compare against the planned start and end date (which might be set via field or sprint).

I've always thought that it would be useful to compare transition dates (I when issues were actually started and finished) with the dates that they were planned to so that you can modify your plans based on current progress (and also see how well your plans track against reality) but I'm not sure if this is quite the use case you're describing?

My concern over mix-and-matching actual and planned data for the same visualisation is that it might be hard to distinguish which is which.

I'm really interested to understand the use case here because it sounds like the difference between using Advanced Roadmaps for planning as opposed for reporting? However I could be completely misunderstanding the requirement here and am very happy to be corrected if so!

Regards,

Dave

[Doug Levitt]

Hi @Dave ,

I suppose I was thinking of MS Project (which i haven't used for ~ 10 years), where there is a planned start/end date and there is an indicator when the item actually started and ended.

Example: http://howtomicrosoftofficetutorials.blogspot.com/2018/09/track-tasks-using-project-2007.html (see picture).

To my understanding, in Advanced Roadmaps, there is no "true" planned start/end date.  Rather, Advanced Roadmaps is inferring those dates from the Sprint Start/End Dates.  But that's not the Planned Start/Planned End Date.  That, actually, is: Earliest Possible Start Date or Latest Possible End Date.  And, we don't depict what the Actual is.  We need to use the Status to know if something started or if its Done.  That works (I suppose).  It would be more useful though, if we could display more fields AND the timeline could scroll.  Maybe the timeline can scroll, but I hadn't figured out how to do that.  As I want to display about 6 fields PLUS the timeline.

In any event, I think I understand how you envisioned it would work.  It would be great to have some comprehensive use cases describing how real software teams are using this.  I am particularly interested in how its being used where teams own the planning, but organizations want to use Adv Roadmaps to simply identify planning gaps (and if gaps exist, the users update how PBIs are assigned to Releases and Sprints).  Also, it would be helpful if you could eliminate the 5000 issue limit.  With 25+ Teams, we are nearing it (and have to eliminate SubTasks to make it work).

Thanks for listening and providing your feedback.

Doug

[Rob Horan]

@Dave Dates comprise many of the biggest issues with Advanced Roadmaps.  For users who have a full understanding of the tool, these are likely non-issues.  However, its been my experience that many do not understand how date inferral works in Advanced Roadmaps, and the documentation, while extremely detailed, does not covey understanding - for a tool that provides such a high-level view of the data, that level of information is ironically missing from the documentation.  

There are guides, sure, and those work when everything is absolutely perfect.  But more so, those guides ALWAYS assume people are estimating in story points.

There need to be troubleshooting guides - deep, detailed guides on what to look for when things are off.  When there are dates that are added to issues because of external factors, such as sprint dates, there need to be indicators and tooltips.  There need to be ways to isolate these issues, so they can be examined separately.

Please see https://community.atlassian.com/t5/Advanced-Roadmaps-questions/Why-is-Advanced-Roadmaps-miscalculating-sprint-capacity/qaq-p/1974521

[Rob Horan]

@Dave  regarding your comment "it sounds like the difference between using Advanced Roadmaps for planning as opposed for reporting" I'm curious as to why  Advanced Roadmaps shouldn't be the go-to for both planning AND reporting?  What's the point of a plan if it can't be used for reporting?  I understand scenarios represent what if's but apart from that, plans can change at any time, with any tool, but reports always need to be made.

[Matt Parks]

@Dave  I know this topic has been around for a bit, but I had a question about the functionality.

Typically, we put Target start/end dates on our epics, but we have configured the plan to use the sprint dates if no dates are provided (which is often the case for the stories in the plan).

However, it appears that, if a story carries over to a new sprint, the new sprint dates are not reflected in the plan, but the original sprint dates.

Is this expected behavior or are we running into a bug? To clarify, I'm running Jira Data Center, not Cloud.

[Michelle Melancon]

Hi @Matt Parks , 

The Target start/end dates should reflect the updated sprint dates if you have sprint dates inferred enabled in the plans settings. 

I'm not sure if you are referring to the story dates or epics but any manual date that you set on the epic will not be overwritten with any roll-up dates. You'd have to remove what was manually set to see the forecasted roll up. 

I also could be misinterpreting the issue LOL. Let me know! 

[Max Merkel]

Hey @Michelle Melancon

we have the same problem that @Matt Parks is addressing.

In our plan, we have the following option enabled: Use sprint dates when issues don't have start and end dates

Example:

• Issue A was started in Sprint 1 but was carried over to Sprint 2, Sprint 3 ... Sprint n.
• Issue A has no start or end dates set

When looking for the issue on the roadmap, it will show the start/end dates of the sprint where it was started. This behaviour deviates from what Dave wrote in his first reply (Issue A should have start date from sprint 1 but end date from Sprint n).

Plan:

Ticket GE4-10281 with active sprint ending April 17 and no start/end dates:

[Michelle Melancon]

@Max Merkel  Ok Thanks for the detailed description. Very helpful! 

In AR if you have the "Use sprint dates when issues don't have start and end dates" enabled you'll see the sprint dates in the target end date populated with the s lozenge as you also show in your screenshot. This correctly reflects the updated target dates when a story is not completed in a single sprint. However, it is NOT a set target date, its showing the sprint dates more as a reference, which is why you don't see the target end date populated on the issue itself in Jira. 

You would have to set that date and save it to jira to show it as a set target end date. 

I hope this helps! 

Michelle