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).
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.
@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).
@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!
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.
If you already heard about Smart Commits in Bitbucket, know that you just stumbled upon something even better (and smarter!): Genius Commits by Better DevOps Automation for Jira Data Center (+ Server...
Connect with like-minded Atlassian users at free events near you!Find an event
Connect with like-minded Atlassian users at free events near you!
Unfortunately there are no Community Events near you at the moment.Host an event
You're one step closer to meeting fellow Atlassian users at your local event. Learn more about Community Events