Uploaded image for project: 'JIRA'
  1. JIRA
  2. JRA-3009

Calculate issue estimates using subtask estimates

    Details

    • Feedback Policy:

      JIRA feedback is collected from a number of different sources and is evaluated when planning the product roadmap. If you would like to know more about how JIRA Product Management uses customer input during the planning process, please see our post on Atlassian Answers.

      Description

      A problem we currently have to workaround is the fact that we sometimes log high-level features that we then split into many smaller tasks, which we then link using a "subtask" link. I'm certain many companies do something similar.

      The problem is that since for JIRA links are meaning-less, effort estimated on the high-level task won't be kept up-to-date with the effort involved in subtasks, etc.

      In order to workaround this problem we have to specify quite a complex procedure for our developers.

      If instead JIRA detected (or defined) this "subtask" links between issues, it would know it needs to add/substrack effort accordingly, etc.. and it would save developers & managers the effort.

      1. rendition of feature enhancement.jpg
        110 kB
      2. screenshot-1.jpg
        461 kB
      3. subtasks.png
        21 kB

        Issue Links

          Activity

          Hide
          btekab Belai Beshah added a comment - - edited

          Our burn down chart in greenhopper was not what we expected to be. We then realized that the original estimate on the issue was the one that was skewing it since it is added on top of the subtasks estimate. nDoes this mean that the original estimate for an issue needs to be set to zero once it is broken down to sub-tasks or do people just create another field to keep track of the high level estimates?

          Show
          btekab Belai Beshah added a comment - - edited Our burn down chart in greenhopper was not what we expected to be. We then realized that the original estimate on the issue was the one that was skewing it since it is added on top of the subtasks estimate. nDoes this mean that the original estimate for an issue needs to be set to zero once it is broken down to sub-tasks or do people just create another field to keep track of the high level estimates?
          Hide
          pburkholder Peter Burkholder added a comment -

          I'm having a problem similar to Belai's.

          At the start of each sprint I set aside a 16h task for "Production Support", but I don't enter any subtasks because I can't know, a priori, what they will be.

          I would like to log the work done on each subtask as they come in, but doing so throws off my Greenhopper burn down.

          I want to keep these tasks in the same project as our development work, so any adjustments made during the sprint because of too many fires to fight, or t0o few, are aggregated with our total work.

          Show
          pburkholder Peter Burkholder added a comment - I'm having a problem similar to Belai's. At the start of each sprint I set aside a 16h task for "Production Support", but I don't enter any subtasks because I can't know, a priori, what they will be. I would like to log the work done on each subtask as they come in, but doing so throws off my Greenhopper burn down. I want to keep these tasks in the same project as our development work, so any adjustments made during the sprint because of too many fires to fight, or t0o few, are aggregated with our total work.
          Hide
          woodj Julian Wood added a comment -

          Yes similar to Belai and Peter, I am having this same problem.

          In fact I am doing exactly what Belai is suggesting as a work around - setting the original estimate to zero once a story is tasked out with more specific estimates. Obviously this is not ideal, and we are losing information by doing this. Adding the estimate from the subtasks to the estimate for the story just does not make any sense at all.

          I think it has been suggested before, but this is how I would expect it to work:

          1. Create a story with an original estimate (a placeholder).
          2. At some future time, the story is (sub) tasked out. As soon as the story has one subtask, the sum of the subtask estimates should be what is used everywhere. The original estimate should be maintained as a separate field.

          I see there is still JIRA-11756 which is open, and addresses this problem, but it is over 2 years old!

          Show
          woodj Julian Wood added a comment - Yes similar to Belai and Peter, I am having this same problem. In fact I am doing exactly what Belai is suggesting as a work around - setting the original estimate to zero once a story is tasked out with more specific estimates. Obviously this is not ideal, and we are losing information by doing this. Adding the estimate from the subtasks to the estimate for the story just does not make any sense at all. I think it has been suggested before, but this is how I would expect it to work: 1. Create a story with an original estimate (a placeholder). 2. At some future time, the story is (sub) tasked out. As soon as the story has one subtask, the sum of the subtask estimates should be what is used everywhere. The original estimate should be maintained as a separate field. I see there is still JIRA-11756 which is open, and addresses this problem, but it is over 2 years old!
          Hide
          loganbarnett Logan Barnett added a comment -

          This is highly desirable to work in Greenhopper as well, but I can't find how to input estimates for subtasks. These aren't time estimates I'm talking about, but abstract story point estimates. How would I go about doing this? Or do we need to make another ticket?

          Show
          loganbarnett Logan Barnett added a comment - This is highly desirable to work in Greenhopper as well, but I can't find how to input estimates for subtasks. These aren't time estimates I'm talking about, but abstract story point estimates. How would I go about doing this? Or do we need to make another ticket?
          Hide
          bruce.henry Bruce Henry added a comment -

          Why, oh why, does this force us down the estimate in time path. When I estimate in time I have to go down one of two paths:

          1. Estimate in "real" hours where a 1 hour task should be done in 1 hour and a 40 hour task should be done in about a work week.
          2. Estimate in ideal hours where a 1 hour task will get done in about 2 hours (because of email & interruptions) and a 40 hour task will take about 2 weeks.

          The problem is that in #1 I end up spending an endless amount of time arguing with management about "why don't our devs get 8 hours of work done per day?" and in #2 I end up spending an endless amount of time arguing with management about "why are you planning for our devs to only do 4 hours of work per day?"

          In both situations I find myself wishing that I had just recorded story points and told management that "this team gets work done at the rate of about 23 points per day" and that's pretty good because your happy with the output, rather than focusing on the number of hours of work done per day. Sigh... very frustrated.

          Show
          bruce.henry Bruce Henry added a comment - Why, oh why, does this force us down the estimate in time path. When I estimate in time I have to go down one of two paths: 1. Estimate in "real" hours where a 1 hour task should be done in 1 hour and a 40 hour task should be done in about a work week. 2. Estimate in ideal hours where a 1 hour task will get done in about 2 hours (because of email & interruptions) and a 40 hour task will take about 2 weeks. The problem is that in #1 I end up spending an endless amount of time arguing with management about "why don't our devs get 8 hours of work done per day?" and in #2 I end up spending an endless amount of time arguing with management about "why are you planning for our devs to only do 4 hours of work per day?" In both situations I find myself wishing that I had just recorded story points and told management that "this team gets work done at the rate of about 23 points per day" and that's pretty good because your happy with the output , rather than focusing on the number of hours of work done per day. Sigh... very frustrated.

            People

            • Assignee:
              nick.menere Nick Menere [Atlassian]
              Reporter:
              paco Paco Vidal
            • Votes:
              209 Vote for this issue
              Watchers:
              102 Start watching this issue

              Dates

              • Created:
                Updated:
                Resolved:

                Time Tracking

                Estimated:
                Original Estimate - Not Specified
                Not Specified
                Remaining:
                Remaining Estimate - 0h
                0h
                Logged:
                Time Spent - 8h
                8h