Does Roadmaps use issue estimates to automatically create timelines for projects?

[Anisha Gallagher]

All my stories are already estimated using the original / remaining estimate fields in jira and I was hoping that, when I create a plan, Roadmaps would use the estimates to automatically create a timeline?

Is that possible? 

[Dave · Accepted solution]

Hi @Anisha Gallagher ,

Could I just confirm if you're using Roadmaps or Advanced Roadmaps?

There is an auto-schedule capability in Advanced Roadmaps that will assign dates, sprints, releases and teams to your issues based on the estimates that you've provided. But this capability does not exist in Roadmaps.

Advanced Roadmaps is a premium feature that you access from the "Plans" menu in the top navigation bar. Roadmaps are available from the left sidebar of your project,

Regards,

Dave

[Anisha Gallagher]

Hi @Dave ,

Thank you for your reply, apologies for being so vague!

I'm using Advanced Roadmaps and I have tried using the Auto Schedule option you mention but it doesn't seem to use the issue estimates.

For example a particular issue that is estimated at 8 hours has been auto scheduled with target start / end dates that give it a planned time frame of 22 days. I'm unsure how it's calculated those start / end dates but it seems unrelated to the issue estimate?

Thanks,

Anisha

[Dave]

Hi @Anisha Gallagher ,

Have you had the chance to read through the documentation on this at all yet? It will probably provide a better guide to how it works than an answer I write up myself - please have a read through here: https://confluence.atlassian.com/advancedroadmapscloud/auto-scheduling-issues-998651231.html

However, in general the key things you want to check are that you're setting the correct estimate field (if you're doing this on the issue details, rather than in the plan) and that you have your plan configured to use the right estimation type (i.e. make sure if you're using time-based estimation on the issues that the plan isn't set up to use story point estimation). 

You also want to check the teams in your plan, the velocity that you've assigned to them and the number of members in the team (as this can have an impact on the schedule - it's assumed that only one member of a team will work on one issue at a time for example).

Regards,

Dave

[Anisha Gallagher]

Hi @Dave

Thank you for the documentation, I had read it already and unfortunately it doesn't help resolve my issue. I can confirm that my plan is configured to use time based estimates but I am currently unclear how this is meant to pull through to my Gantt chart?

I'll try to explain what it is I'm trying to achieve and what issue I'm facing:

I have created a project based plan containing a number of epics, each with child tickets within. The child tickets are individually estimated using 'Original Estimate' and 'Remaining Estimate' time tracking fields. 

My Advanced Roadmaps plan pulls through the correct epics and hierarchy, it also pulls through the correct estimate figures in the Estimates (d) / Estimates (h) field.

The problem I face is that the estimates are not reflected in the Gantt itself. For example:

• If I use auto-schedule the Gantt bars all auto-create as 14 day tickets and the real estimates are not reflected. 
• If I don't use auto-schedule and create the Gannt bars myself, all Gantt bars create as 7 day tickets.

I do not understand how to integrate estimates within my Gantt chart without doing it all manually?  It might be worth noting that I am not using next-gen projects.

Thanks,

Anisha

[Dave]

Hi @Anisha Gallagher ,

Thanks for the clarification. The reason for this is that the auto-scheduler works at the granularity of a sprint (the dates assigned would be the expected start / end of the sprint). Where a sprint exists it will also assign the sprint. It sounds like the team in the plan is configured to have 2 week sprints which is why the issues are all 14 days in length.

When you manually drop an issue on the timeline it sets the default width to match the timeline unit being displayed on the timeline (so it sounds like your timeline is measured in weeks). This is done so that the initial issue bar is always a "sensible" width for the timeline scale.

Hopefully that explains the behaviour,

Regards,

Dave

[Anisha Gallagher]

Hi @Dave,

Thanks again, I feel like I'm getting closer to understanding how this works. I have one further questions relating to your description above. 

Assuming I'm not using the auto-scheduler, and my timeline view is in days. If I drop an issue on the timeline it defaults to 1 day, despite that issue actually being estimated at 3 days.

What I'm struggling to understand is if and how my plan can automatically account for estimates and if not, why I ever have to configure an estimate type? 

Thanks,

Anisha

[Dave]

Hi @Anisha Gallagher ,

We made the decision not to create too much tightly coupled behaviour between estimates and the dates on issues. The reason being is that even though an issue might be expected to be a days work that does not always necessarily equate to being a single day on the timeline (you might complete 8 hours work over the space of 2 to 3 days in reality). We find that people do not always work in continuous blocks of time and that there is not necessarily this strict relationship. This is even more important when estimating with points because you Agile practices suggest that there should never be a fixed relationship between the two.

So the estimate field is useful for logging work on an issue and can be used with the auto-scheduler but we do not consider estimates with manually adjusted dates on the timeline.

Hopefully that at least explains the reason for the behaviour, even if it is not quite what you expected,

Regards,

Dave

[Anisha Gallagher]

Hi @Dave

Thank you for taking the time to clear that up for me, I now feel much clearer on this. I completely agree that estimates don't directly translate to hours / days so I appreciate the logic that's been chosen.

Thanks,

Anisha

[Dave]

No worries @Anisha Gallagher - this is great feedback that you've provided. We do recognise that the auto-scheduling results and the relationship between estimates and dates is not completely intuitive and it's definitely something we'd like to improve!

Regards,

Dave

[Mick]

One suggestion that would help me - if there is an estimate on the ticket (either on the ticket itself or a change made on the Roadmap) then that should be the default length of the bar. We can adjust it later but it would help to use this as an initial estimate.

[Atin Choenni]

I completely agree with Mick. For our purpose the timeline is more useful if you can see the estimates visually in the width of the boxes. In the least the admin/project lead should be able to choose which schedule they want to adhere to. Being Sprint cadence, "sensible" timebox width or (Initial) Estimation. This way all approaches are covered.