Hello, I'm trying to implement something in Plans and I'd like the community advice on best practices. Basically, we want to estimate our projects at different levels: Initiative, Epic and Story, and check if it matches. By matching, I mean that the sum of estimates in Epic should ideally be the same as the estimate on their parent Initiative, and so on. We would also like to be able to make reports on that, e.g take the mean difference between the direct-estimate and the sum-of-children-estimate for example. For now we're populating 3 different fields with Automations: * A0 is the direct estimated value on Initiatives * A1 is the direct estimated value on Epics, and is the sum of children-epics-A1-values on Initatives * A2 is the direct estimated value on Stories, the sum of children-stories-A2-values on Epics the sum of children-epics-B2-values on Initatives As you can tell, it's kind of complicated and I'm not a big fan. I know that Structure would offer a more flexible way to do this but then the result wouldn't appear on the Work item view and it may be a problem for us. I don't know about what BigPicture offers. What are the industry's best practice in this regard? Do you think it can prove useful or is this totally irrelevant? Should we consider a different approach? Thanks! Simon

nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Estimation at different hierarchical levels

slucchesini

Hello,

I'm trying to implement something in Plans and I'd like the community advice on best practices.

Basically, we want to estimate our projects at different levels: Initiative, Epic and Story, and check if it matches. By matching, I mean that the sum of estimates in Epic should ideally be the same as the estimate on their parent Initiative, and so on. We would also like to be able to make reports on that, e.g take the mean difference between the direct-estimate and the sum-of-children-estimate for example.

For now we're populating 3 different fields with Automations:

A0 is the direct estimated value on Initiatives
A1 is the direct estimated value on Epics, and is the sum of children-epics-A1-values on Initatives
A2 is the direct estimated value on Stories, the sum of children-stories-A2-values on Epics the sum of children-epics-B2-values on Initatives

As you can tell, it's kind of complicated and I'm not a big fan.

I know that Structure would offer a more flexible way to do this but then the result wouldn't appear on the Work item view and it may be a problem for us. I don't know about what BigPicture offers.

What are the industry's best practice in this regard? Do you think it can prove useful or is this totally irrelevant? Should we consider a different approach?

Thanks!

Simon

Accepted answers

Marc -Devoteam-

Hi @slucchesini

In my opinion estimations are not don on levels above story.

Work types aboe story are based on time realtion in my point of view.

An Epic should be based on a time fram from 1 to 3 months, An Initiative for up to a year or a little over.

Work type beneath Epic are in a Sprit and a sprint has a duration and the team acting on the sprint has a capacity, the capacity has an avarage value of sotry points.

This what the team can accomplish, in a sprint.

You can do a roolup of the estimations on Epic level and on Initiative level with automations, but you should not estimate theses levels.

Jeremy Hermes

Hey @slucchesini
Both Structure and Structure.Gannt together is kind of a 'replacement for' Plans , but I have yet to see widespread adoption of working in Structure for everything -- folks do seem to gravitate towards Plans, and so far no bridge between the two

Tempo Capacity Planner is another add-on useful for this but in the end we all are special snoflakes and need more customization than it affords

Then there is Jira Align ($$$)

I have gone down this road, and ran into lots of problems keeping those calculated fields accurate as Jira projects came and went, moved issues between Initiatives and Epics, and generally "change" happened (the word "Original" just doesn't mean what it used to)

Yeah so is Original Estimate useful at higher levels in issue type hierarchy ? Maybe not as much as having man hours per team or Jira project to work with.

In my experience, reporting on worklogs at the Initiative is much more valuable to the business end of things
Unfortunately, the best solution I have found for that is carting off the worklogs and issue keys to a postgres db and crunching the hierarchal summation there

gluck,
Jeremy

All comments

Marc -Devoteam-

Hi @slucchesini

In my opinion estimations are not don on levels above story.

Work types aboe story are based on time realtion in my point of view.

An Epic should be based on a time fram from 1 to 3 months, An Initiative for up to a year or a little over.

Work type beneath Epic are in a Sprit and a sprint has a duration and the team acting on the sprint has a capacity, the capacity has an avarage value of sotry points.

This what the team can accomplish, in a sprint.

You can do a roolup of the estimations on Epic level and on Initiative level with automations, but you should not estimate theses levels.

slucchesini

Thanks for your insights! I get your approach but then how do you come up with a project's budget? Do you make it totally independant of the estimate time spent?

Marc -Devoteam-

Hi @slucchesini

Yes.

When a project is confimed, creating stories to provide the work to the teams, estimaitons can change while the project is realized.

Are you saying you already created all stories and Epics with estimations before the project is stated adn you use this as budget?

slucchesini

No, but we try to make it match more or less. We tend to think that a project will last e.g one year with 5 people / week so that makes 260 MD, and then when we split the work into stories we try to compare to see if we had a good estimate of the workforce needed.

Jeremy Hermes

slucchesini

Thanks for your insights! If anything, it's good to know that there's no perfect solution and the question stays open.

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Unanswered
Groups
Help

Find more posts tagged with

jira

cloud

jira-cloud

estimate

plans