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; } } }

Rapid Board time estimates with sub tasks

Brad Albrecht

I have recently transitioned my projects over to Rapid Board with the latest GreenHopper updates. I use time for estimates so when I am building a sprint, I can see how long the estimated issues are going to take, and keep it under 2 weeks per dev.

Some of the issues already have sub tasks with estimates for various reasons. We have been allowing Jira to calculate the estimate and remaining on the parent taks and it has worked fine before Rapid Board. Now, when I am trying to set up a sprint, any issue with sub tasks does not show the calculated value and I can't actually see what amount of work the parent issue represents.

If I change the parent task estimate manually, when I add other sub tasks, they get added to the values, and the math is all wrong. It seems that the new Rapid Board doesnt want me using Jira issues the way I have been, yet using auto calculated sub tasks seems to make so much more sense if I dont use a Rapid Board.

I have read that Atlassian thinks its working fine, so it must be something I am misunderstanding about how to use the Rapid Board. Any suggestions on what I should be doing different?

Accepted answers

sclowes

Let me start by saying that in GreenHopper 6.0.3 (which is due out in a week or so) on boards that are configured for 'Time Tracking' the sum of the remaining estimate for the stories and sub-tasks will be shown in the sprint footer next to the sum of the 'estimate' value for the stories. So this will help achieve what you're looking for here.

But if you'll indulge me I'd like to provide a full explanation of why we we've offered 'Original Time Estimate' as an 'Estimate' value and not 'Remaining Estimate'. Some of my discussion refers to agile concepts that anyone reading probably knows well but I've included it because the context is important. Note that the discussion refers to the best practices we've implemented as the main path in GreenHopper, you can choose not to use this approach if you feel it's really not suitable.

Estimation is separate from Tracking

In Scrum there is a distinction between estimation and tracking. Estimation is typically performed against Primary Backlog Items (PBIs, usually stories) and is used to work out how long portions of the backlog might take to be delivered. Tracking refers to monitoring the progress of the sprint to be sure it will deliver all of the stories that were included. Tracking is often performed by breaking down stories in to tasks and applying hour estimates to them during the planning meeting then monitoring the remaining time in a burndown during the sprint.

Estimation is all about Velocity

The primary purpose of applying estimates to the PBIs is to use that information to work out how long it will take to deliver portions of the backlog.

In traditional development environments teams would estimate items in 'man hours' and these would be assumed to be accurate. They could then count up the hours in the backlog for a project, divide by the number of people on the team and hours in the week to reach a forecast date. Of course, these estimates often proved to be wildly inaccurate because they did not take in to account the natural estimation characteristics of the team (for over/under estimation), unexpected interruptions or the development of team performance over time. The inaccuracy of the estimates combined with the significant cost of the time spent trying to 'force' them to be accurate makes the 'man hours' approach difficult if not impossible to make work.

So in the Scrum world most teams do not try to achieve estimation accuracy, instead they aim to achieve a reliable velocity. The velocity is a measure of the number of estimation units that a team tends to complete from sprint to sprint. After their first few sprints most teams will achieve a reasonably consistent velocity. Armed with velocity and estimates on the PBIs in the backlog teams can look forward to predict how long portions of the backlog will take to complete.

The key is that it does not matter what the estimation unit is, just that from sprint to sprint it becomes reasonably predictable. For example, teams can choose to use 'ideal hour' estimates but it's neither necessary or expected that those hours will have any close relationship to elapsed time. If a team has 'man hour' capacity of 120h in each sprint but a velocity of 60h that makes no difference because the 60h velocity can still be used to estimate the number of sprints that portions of the backlog will take to complete and therefore the elapsed time. Many people then start wondering where 'the other 60 hours' went and implying that there is something wrong with team productivity. But that's usually got nothing to do with it, a team's estimates merely represent their view of how hard items will be and they're always polluted by the team's natural behaviour (for example over/under estimation) as well as organisational overhead etc. The velocity is all that matters from a planning perspective.

Since the units are not related to time, most teams now choose to use story points (an arbitrary number that measures the complexity of one story relative to others) as their estimation unit. Story points clearly break the mental link with time.

Inaccurate Estimates are good, as long as they are equally Inaccurate

Velocity will only reach a stable state as long as the team estimates each backlog item with the same level of accuracy. In fact, it's probably better to say that each item should be estimated to exactly the same level of inaccuracy. At the risk of repeating the obvious, the goal of velocity is to be able to look at a backlog of not particularly well understood stories and understand how many sprints it will take to complete. This requires a similar level of uncertainty for all of the estimates that are in the backlog.

One of the counter intuitive implications is that teams should estimate each item once and not change that estimate even if they discover new information about the item that makes them feel their original estimate was wrong. If the team were to go ahead and update estimates this 'discovery of new information' will happen regularly and result in a backlog that has some items that have higher accuracy but most that don't. This would pollute velocity because sprints with a larger percentage of high accuracy estimates will complete a different number of units compared to those with a lower percentage of high accuracy estimates. As a result the velocity could not be used for its primary purpose, estimating the number of sprints it will take for a set of not well understood stories in the backlog to be completed. Therefore it's critical to use the first estimates so that the team's velocity realistically represents their ability to complete a certain number of units of not well understood work far ahead in to the future.

But what about when teams realise they've gotten it wrong?

Consider the following scenario:

Issue X has an original estimate of 5 days.
The issue's estimation was too optimistic and they realise it's actually 15 days before the next sprint is planned.

Some people would argue that using the original estimate will endanger the sprint's success because the team will take in what they think is 5 days of work in to the next sprint when it's actually 15

However, the inaccurate estimate of 5 days is unlikely to be an isolated occurrence, in fact the estimates are always going to be wrong (some very little, some wildly so). Often this will be discovered after the sprint has started rather than before. As long as the team estimates the same way across the whole backlog this will work it self out over time. For example if they always underestimate they may find that for a 10 day sprint with 4 team members they can only really commit to 20 days of their estimation unit. If they have established a stable velocity this has no effect because from a planning perspective we can still estimate how much work we'll get done in upcoming Sprints with good certainty.

But doesn't that break the Sprint Commitment?

When it comes time to start a sprint, the team can use the velocity as an indication of items from the backlog they can realistically commit to completing based on the amount they have successfully completed in the past. However, many people immediately question how that can be right when the original estimates will not include information about work that might have already been done or discovered information about how hard the work is.

As an example, consider the following scenario:

An issue has an original estimate of 10 days.
The team works 5 days on the issue in the current sprint.
The team discovers a bad bug somewhere else in the project and decide that fixing that bug in the current sprint is far more important than completing issue X as planned.
The sprint gets finished and the issue returns to the backlog.

In the next sprint the team would be tempted to update the estimate for the issue to 5 days and use that to make their decision about whether to include it in the sprint. The implication is that they might not include enough work in the next sprint if they used its original estimate of 10d. However, the reason that the task was not completed previously is because of unplanned work, it's unrealistic to assume that won't happen again in the future, perhaps even in the next sprint, thus the 10d is a realistic number to use in absence of certainty. As a result the cost of the unplanned work that may happen is eventually accounted for in the original estimate. Even if the work does turn out to be insufficient for the next sprint the team will correct that by dragging more work in to the sprint.

In the same example, consider if this were the only issue in that sprint and will be the only issue in the next. If the issue is completed in the second sprint and we use the remaining estimate the velocity will be (0d + 5d) / 2 = 2.5d, but the team can clearly complete more work than that in future sprints. If we use the original estimates the velocity will be (0d + 10d) / 2 = 5d. The use of the original estimate accounts for the fact that the team cannot commit to 10d in every sprint because unplanned work will likely make that impossible, it also realistically accounts for the fact that unplanned work will not happen in every sprint.

Why not estimate on sub-tasks and roll that up for Velocity and Commitment?

Many teams break down stories in to sub tasks shortly before the sprint begins so they can use the stories for tracking. This raises the possibility of using the sum of the estimates on the sub-tasks as a way to decide which issues to commit to in the sprint (and potentially for velocity).

As described above, tracking is really a separate process from estimation and velocity. The estimates that are applied to the sub tasks are clearly higher accuracy than those that were originally applied to the story. Using them for velocity would cause the velocity to have both high and low accuracy estimates, making it unusable for looking looking further out in the backlog where stories have only low accuracy estimates. In addition, only items near the top of the top of the backlog are likely to have been broken to tasks, so using task estimates for velocity means that the velocity value could only ever predict the time to complete the backlog up to the last story that has been broken in to tasks.

Using the sub task rollup to decide the sprint commitment would also be dangerous because unlike the velocity value it does not take in to account the overhead of unplanned work or interruptions.

Conclusion

Many industry leaders are moving away from hour estimates of any sort. This makes sense because the main questions to be answered are 'How much work can we realistically commit to completing this sprint?' and 'How long will this part of the backlog take to deliver?'. A story point approach based on original estimates can deliver the answers to these questions without the anxiety around 'accuracy' that teams feel when asked to estimate in hours.

The GreenHopper team itself uses the approach described in this article and has established a reliable velocity that we have used to plan months in advance, even when new work has been encountered during those months.

We recommend this approach because while it is sometimes counter-intuitive it is also powerful, fast and simple.

All of that said one of the key precepts of Agile is finding the way that works for you. So GreenHopper does support the alternatives described above including the use of remaining estimates for sprint commitment, hours for estimation and hour estimates on sub-tasks.

All comments

sclowes

Estimation is separate from Tracking

Estimation is all about Velocity

The primary purpose of applying estimates to the PBIs is to use that information to work out how long it will take to deliver portions of the backlog.

Inaccurate Estimates are good, as long as they are equally Inaccurate

But what about when teams realise they've gotten it wrong?

Consider the following scenario:

Issue X has an original estimate of 5 days.
The issue's estimation was too optimistic and they realise it's actually 15 days before the next sprint is planned.

Some people would argue that using the original estimate will endanger the sprint's success because the team will take in what they think is 5 days of work in to the next sprint when it's actually 15

But doesn't that break the Sprint Commitment?

As an example, consider the following scenario:

An issue has an original estimate of 10 days.
The team works 5 days on the issue in the current sprint.
The team discovers a bad bug somewhere else in the project and decide that fixing that bug in the current sprint is far more important than completing issue X as planned.
The sprint gets finished and the issue returns to the backlog.

Why not estimate on sub-tasks and roll that up for Velocity and Commitment?

Using the sub task rollup to decide the sprint commitment would also be dangerous because unlike the velocity value it does not take in to account the overhead of unplanned work or interruptions.

Conclusion

We recommend this approach because while it is sometimes counter-intuitive it is also powerful, fast and simple.

Brad Albrecht

Thanks for the very detailed explanation. This is what I was looking for.

As a suggestion, having this available for new customers would be very helpful. My team has a heavy waterfall background and we do not necessarily follow (or know) all the "rules" of scrum. Having a clear indicator of how the features are intended to be used in cases like this were lots of people have questions is very helpful.

Danielle Zhu1

This is great. Shaun, thanks for this well-written answer and for sharing the GreenHopper team's practice!

Wow, nice one, Shaun!

Keyhan Hadjari1

Hi, I have some comment to the estimation and how it should be done. In our company (100 000+) we define stories as just holders of tasks and a story estimation and remaining is just sum of its tasks.

When we do our planning we split story to tasks and time estimate, during the sprint we finish of tasks and stories.

Green Hopper presumes that you are just planned for a story and not task and that during the sprint we will burn storys remaining time and not tasks. In this way then stories are going to just be empty boxes with no estimation and logging, since logging work on a task will not remove time from stories remaining time.

This solution also leads to statistics not being so detailed about teams work, like how much time was put on certain subtask type, or what sub task took too much time to handle since those stats are hidden in the story.

I suggest you make the option for teams like ours that do estimate each task so that the story will include just the tasks sum of original estimate of its tasks during planning. During work if a task is added then only the remaining time of the story would be increased only and original estimate unchanged. If the sprint finishes with some tasks left unfinished in a story then the story would be put in the backlog and its original estimate would be changed to the sum of the original estimate of its remaining tasks in it.

sclowes

Hi Keyhan,

If you operate this way (only ever apply estimates to stories once you have broken them down in to tasks) you will only be able to look ahead in the backlog and predict the amount of time needed to get there up to the last story you have broken down. If you only break down stories during planning you will be unable to look more than a sprint ahead and predict how long it will take to deliver.

GreenHopper does not presume that you burn stories remainign time and not tasks. If you enable time tracking the burndown chart will show the burndown of the time estimates against the tasks. For example, if have a story A with tasks A1, A2 and A3 the burndown will show any remaining estimate you burn down on A1, A2 and A3. You can see the information about how long certain sub tasks took in the burndown.

We will not change the original estimate for the story, but you are welcome to either ignore it (i.e. leave it 0, causing the velocity chart to show 0 for each sprint) or edit it to equal the sum of the remaining estimates of the tasks. You can do this easily by copying and pasting it on the story level during planning.

Thanks,
Shaun

Keyhan Hadjari1

Hi Shaun thank you for quick answer. Let me clarify a few things.

1. We split the story into sub tasks during planning just before we kick off the sprint. Before that like you say the estimate is on story as you said. But still you should have an option that then during the planning of the sprint be allowed to change the behavior to switch from story holding the estimate to it be just sum of its sub tasks.

2. Today we use the burndown chart and see when we log work and burn down sub task and it works like you say,

3. Leaving story with no estimation leads to velocity = 0 at the end of sprint. We have also tried putting the estimate manually to sum of the children , but when the sprint is finished and you look at amount of work, then you will have double the value since the estimate of a story is added to estimate of all the children.

My suggestion is not going to replace your way of doing things, it could be an option just like different kind of estimation you support today. And if you look at the registered bugs and discussion in confluence site you see that many people would like this behavior.

sclowes

Hi Keyhan,

Leaving story with no estimation leads to velocity = 0 at the end of sprint. We have also tried putting the estimate manually to sum of the children , but when the sprint is finished and you look at amount of work, then you will have double the value since the estimate of a story is added to estimate of all the children.

No, the velocity chart never shows the sum of the children, it only ever shows the value in the parent. So if you set the Original Estimate on the parent to the sum of the children you will not double count in the velocity chart, it's just that the first time you do this the Remaining Estimate for the story will be automatically set to be equal to the Original Estimate by JIRA so you'll need to clear it to avoid having the burndown chart double count.

Thanks,
Shaun

Keyhan Hadjari1

Sorry I was not clear there, when looking at statistics of Stories the amount of work put on the story is double. I do not mean the velocity here but general statistics of the finished stories.

We have been now thinking of yet another way of doing this to pass this shortcoming, and that is to not to put any estimation on sub task, and use them just to move around in the task board. Also logging the work done in the subtask in the story itself. I think this will solve most of issues BUT it means it will be a bit more difficult to go back and see what has been done in a specific sub task. Then you have to look at a stories work log and search for work logged for the sub task. Also the powerful statistics tool in greenhopper and Jira can not be used as good as before.

sclowes

I'm really not sure what you are saying here and I think there must be some confusion. If the 'double' counting is not happening in the velocity or burndown charts where is it happening?

To show you what I mean, I've put together some screenshots below. Please Note: You will see different behaviour if you have legacy mode enabled for time tracking in your JIRA instance. It is not recommended to use legacy mode (and it has not been the default for many years).

Here's an issue on a board configured for Original Time Estimate and for Time Tracking. I've gone ahead and created two sub tasks with estimates of 3 hours. You can see that the parent is showing the sum in the 'remaining' box:

Now if I go ahead and copy that 6h to the Estimate field it will double the reamining time because JIRA is copying the original estimate to fill the remaining field.

To fix that I just edit it out of the remaining estimate:

Now, during the sprint I update the remaining time on those sub tasks like normal and they will then update the burndown chart:

(Sorry for the "Remaining Time Estimate" overlapping the heading, I had to resize the page manually to prevent it being too large).

The Velocity chart looks exactly as you'd expect (i.e the 6h of remaining estimate was completed)

The net result is that you can achieve the result you're looking for today with minimal change to the way you work.

Thanks,
Shaun

Jonathan_ugu3v4

@Shaun Clowes

When I set an original estimate for the story and set it back to zero in the remaining estimate for the parent, the original estimate is also set back to zero - so nothing really happens there?!?

please fix this problem, let your customers decide how they will handle their estimations..

What you are not considering is that it is possible to plan your stories with storypoints in the long term and only plan the time estimates ind the sprint planings right before a sprint and use a burn-down on those time estimates.

that's how we do it - it's not possible to plan the whole project with time estimates - that's why the whole story point thing was invented! but during a sprint you want to track things on time basis.

sclowes

Hi Jonathan,

Can you please check if you have Legacy Mode enabled in your JIRA instance as discussed above? That's the only reason this would happen (i.e changing the remaining estimate affecting the original estimate).

On your desire to use story points for long term and time for sprint tracking, we definitely support this. Just enable 'Story Points' as the Estimate unit for your board but enable Time Tracking as well in the board configuration. This will allow you to burndown hours in the sprint but keep track of story points over longer periods.

Thanks,
Shaun

Jonathan_ugu3v4

hi,

you were right, legacy mode was active - I didn't really get that there was a change in this regard. I'll try it again with legacy disabled.

when I set the estimate to story points - what exactly does this do? just change the basis for velocity calculation and what's shown on the right hand of my issues in planing mode? it doesn't interfere with my hours burndown charts?

can i switch between those estimate modes anytime or would that mess with the calculations?

on the general issue here:

this workaround seems to work but I don't get it why you won't support to automate this by showing the sum of all subtask time estimates in those parent issues that don't have an estimate of their own. It's pretty time consuming to do this with the manual workaround...

sclowes

Hi Jonathan,

When you set the estimate unit to story points you:

Tell GreenHopper you want the velocity chart and the sprint report to show story points
Let GreenHopper warn you when you start a sprint with issues that do not have a story point estimate chosen (since that will affect the velocity chart)
Get GreenHopper to show you the story points on the right on the cards and in the detail view

When you switch on Time Tracking you simply tell GreenHopper that during the sprint you'd like to have the burndown be based on hours (attached to issues and sub-tasks). This causes GreenHopper to show the remaining time estimate in the sprint footer on plan mode and in the detail view. It also causes GreenHopper to show the remaining estimate at the bottom right of the card in work mode.

You can switch estimate modes whenever you like but the problem is that the calculations are only as good as the data. For example, if you switch to Story Points but most stories in past sprints did not have story point estimates you'll get useless results.

this workaround seems to work but I don't get it why you won't support to automate this by showing the sum of all subtask time estimates in those parent issues that don't have an estimate of their own. It's pretty time consuming to do this with the manual workaround...

I'm not sure what you mean. If time tracking is enabled we do show the sum of the remaining estimate of the sub-tasks and the parent issue on the right in the detail view (and in the sprint footer). This isn't the estimate (i.e. the value used by velocity) because of all of the points discussed above (i.e. you could only plan as far as you'd broken down in to sub-tasks, you'd be mixing high and low accuracy estimates and distorting velocity).

Thanks,
Shaun

Nathan Shewmake

Hi Shaun, Thanks for that suggestion. This workaround does handle most of what I'm trying to accomplish, albeit at the cost of a bit of extra work (you say it's "minimal" but it still seems like unnecessary hassle from my perspective). However, there is still another problem with this approach, which is when you click on the story, it now shows the original estimate as double. To me, it seems like the best solution would be to give the users the option to roll up the Original Estimate from sub-tasks the same way it does for the Remaining Estimate. This would be more intuitive and easier to maintain for users who want to use the tool this way. Thanks, Nathan

Hans-Hermann Hunfeld

Hi Shaun,

we have the same problem here as the actual behavior is just confusing! After reading the complete explanations i also agree with you that estimate and tracking are to be separated, but the problem is the different meaning of the original estimate between JIRA and GreenHopper!

As most of the others we do backlog estimation on story points or hours (depending on how agile our teams are) and we do also freeze the original estimate while starting work to have a baseline. In both cases shortly before the sprint will start we create the according subtasks and estimate them in hours.

For "Storypoint-Teams" it seems to work but team using hours getting in troubles. The original estimates from the subtasks (tracking effort) are added to the remaining estimate from the parent (estimate effort) until i went through each task to eleminate the parent s estimate. But, going to approx. 20 parents for each sprint is far away from being smart, it s more like a workaround.

In my opinion this is a design bug as the same field is interpreted in a different way! I would suggest to change JIRA s behavior to reflect GH idea of estimates, as example in case of having subtasks and checkmark the "summarize from subtasks" ignore the remaining estimates (which are filled from the original estimates automatically) Another option would be to add another field for GH estimation which reflects the expected behavior.

Another part which would benefit from this change would be that usually the teams get an user allocation for projects, as example developer A is supposed to work the next 6 months (-> 6x20d = 120d) on that part of the project (-> Epic) and we could note that time on the epic itself. At the moment i have to manually recalculate the remaining effort manually after each sprint has finished...

What do you think?

Christen Lorensen

Might be a stupid question, but can we get the burndown report to burn down based on sub-tasks, if I give the sub-tasks story points?

I like to have tasks grouped, and have these grouped even further by epics. It is a bit of a mess having to many stories just piled together.

Ie. we want to make a new feature on our site, say a mini game "pack man". This takes about a sprint. So we make an epic for that. A task might be "As user I controll pack man with keyboard" which might take a week, and lastly there might be 8 subtasks to this.

The burndown will be a week behind when the task i burned down. It is hard to figure out if one of the subtasks are stuck and there are problems.

Albert D

We use Jira and GreenHopper view to browse and manage issues and sub-tasks. Jira accamulates sub-task original estimates but GreenHopper accamulates only remaining estimates. We cannot go ahead with this.

IT STOPS US BUYING IT!

Can it be implemented as a setting which would allow to accamulate sub-task original estimates to parent original estimate in GreenHopper view to make it be consistent with Jira view?! Please, just allow people do it if they need it.

Hans-Hermann Hunfeld

Hi Shaun,

i understand you explanation, but still we re the opinion that your mentioned "workaround" to go through all stories and delete manually the parent s remaining estimate cannot be the solution in a long run!

Why don t catch up the user s feedback and add an option how GH should handle such cases? Each time we re preparing sprints i have to explain our users again and again how Atlassian thinks this should go but no-one (including me) does really understand why this has to be so complicated...

Please, keep an eye (or better an ear) on your customer and think about how to ease up this situation, thanks!

Regards,
Hans-Hermann

Ivar

We have been giving sub-tasks storypoinst for several years. Now of a sudden, GH tells me "The following issues does not have estimates" because the stories doesn't have SP's, only the sub-tasks.

Extremely annoying, and I do not like to change our process when it works so great for us .

Jordan Paul

Shaun,

Here are some screenshots which illustrate what I feel to be an issue with how the rapid board is currently implemented:

Here I have added a bunch of sub-tasks to a story with no original estimate. You can see that in the Estamation Statistic bubble is empty, yet the remaining time for the story is 4 hours.

At this point, I would really like an option for the Estimate to not be "unestimated". I see this as being a relatively simple thing - If only I could select "Σ Original Time Estimate" as the "Estimation Statistic" instead of the current "Original Time Estimate". This is how things can be done in JIRA - why not greenhopper?

After reading some of your comments above, I then attempted to set the Story estimate to the Remaining estimate. Here's what I got:

Whoops, now there is apparently 8 hours remaining. Somehow, Greenhopper has decided to add the Story estimate to the Sub-task estimate to create some kind of psuedo-sum. To me, this feels like a bug! Fortuntately, I can "fix" it by editing the "Parent:" value to be an empty field (or entering in 0, both methods arrive at the same result):

So, now I have the correct Estimate and the sub-tasks are all estimated as well, but this just feels wrong. I have an "Unestimated" Parent in my remaining calculation yet _clearly_ my parent has an estimate. How is this state even possible, and why should I have to do this? Again, this just feels like a bug.

I'd really appretiate a response to this matter. If preferred, I can be reached offline.

Cheers,

Jordan Paul

unknown

I agree with this post. This is a very frustrating and confusing behaviour.

admin ase

We are switching now from the classic to the agile board and we would like to have also this feature. This seems to be something logical for everybody. We don't really care where you show it, but it is for us a very importat parameter and we would like to have it in the list overview and not in the details pane. We want to see all the stories with the sum of the estimated hours of the subtasks.

From the point of view of the agile it can be so horrible but our customers want to know it in hours, our management want to have it in hours, our project budgets are in hours. We can't convert hours in story points and vice versa, we have to works with hours, that you find it stupid, illogical or whatever, we can't change it. So please just show somewhere in the story the sum of the estimated hours of the subtasks.

Dennis Klemann1

Add me to the list of people who see a great value in having the option(!) to add up estimates from a task and its sub-tasks in GreenHopper as well, for the reasons mentioned several times in this thread.

Btw.: I only signed up so that I could write in this thread. I hope this stresses once more that this topic is important for us.

adam vernon1

I just started using Jira on my current project, and I immediately ran into this issue. I had used the software in the past, but not this newer version. I was rather surprised to see Shaun post that this is working as intended, and that I'm supposed to double-count the time and then manually remove the double-counted time from the remaining estimate. It should work one way or the other-

1. The sub-tasks estimates should roll up to the parent, avoiding the double-counting problem alltoegether. It seems Atlassian is unwilling to do this because of their notion of how velocity is used in relation to the backlog, which I disagree with, but it is what it is. Or just make it an option in the board configuration!

2. Or, Attlassian can give us the option to automatically exclude the parent estimate from Remaining when sub-tasks are present. They already have a special UI for this case (the parent/sum representation of Remaining). In the board configuration, there could be a checkbox to the affect of "Exclude parent Original Estimate from Remaining when sub-tasks are present".

This problem is made worse by what appears to be a related bug. I edited a task during a sprint to change the type from Bug to Story, and it re-calculated the Remaining, putting the parent's Original Estimate back into it, and creating a big spike in my burn down. I manually removed it, so the line is back where it belongs, but the spike is still there. Very hokey.

I was expecting to be a big fan of this software, but these hassles are making it a pain.

Julien Mrad

I have a problem with the current planning board. We usually estimate stories using story points, but during sprint planning, after we break stories down to tasks, we estimate them using ideal hours. This is exactly what Scrum suggests. However, after the team choses the stories for the current sprint during planning, and after filling out the ideal hours estimates of the tasks, one should be able to know whether the sprint work is within capacity. So there should be a way to see the total ideal hours per task type. One example where this is necessary (not just optional) is if a team member was on vacation for the sprint being planned. The capacity would decrease. The only way to deal with this is if we can see the total tasks estimates per task type. The task type is important because we have developers, designers, analysts and QAs in the team. So the total alone would be useless.

Determining whether the sprint work is within capacity is part of Scrum best practices so I think this should be included in the planning view of the Scrum Board.

Julien

Jordan Paul

I much agree with this, however I would say that being able to see total hours for a sprint by task type is secondary to seeing total hours per user. This gives you the ability to do group allocation planning as well as developer allocation planning.

Julien Mrad

So is there a way to total hours for a sprint per user during planning? Or anything else that can help me achieve my goal?

Jonathan_ugu3v4

I was always under the impression they want you to pay for another 3rd party plugin to achieve that in an overview-way.

what should work is to make a quick filter for every team-member and then klick through the quick filters (setting board estimation to hours first) for each person. would be really nice if they would provide a more comfortable feature for that, e.g. a dashboard gadget

Hans-Hermann Hunfeld

We re using a filter which collects all efforts of the new (to be started) sprint, put it in the workload pie chart and work on two screens.

Not smart (i m still convinced that this a design bug) but working....

Christen Lorensen

Can't you use the pie chart gadget, and create a filter for that sprint. Oh no if it is a sprint in planning you can't, there is no field for planning sprints. But if you put a version or labels on all issues in the sprint then you can.

Workarounds workarounds

In my experience what scrummasters do a lot in Scrum/Agile is to count numbers. Sum up numbers from different estimate, recalculate numbers, because a scope change. And so on. Why is Jira - Agile so bad at it (when you look away from reports and dashboards)? The numbers are there, it has to be the simplest thing to do? It would be awesome just to select some issues and it would show a sum of the issues in a floating box or something like that.

Hans-Hermann Hunfeld

Oh no if it is a sprint in planning you can't, there is no field for planning sprints

For sure you can filter for any planned sprint, this was added some versions ago (and before done by a free plugin)

Christen Lorensen

Ok, that's true. Now planning sprints have a number. Wow have not noticed that, cool. That makes stuff easier for us.

Rog1

We're having a similar problem, one of our teams break down stories just before sprint planning adding estimates to subtasks and thus remaining time. This estimate is more informed and thus must be more accurate. It can go up or down, sometimes drastically.

Previous estimates are useful guidelines but not as accurate, they are the same though, both estimates of the same thing, they can still be used for release/roadmap planning - the velocity of the better estimated stories can still be applied to the whole backlog - in fact it's a better, more accurate velocity, and should have a smaller standard deviation.

The team, quite rightly, does not want to have to manually sum estimates from subtasks and manually change the story estimate. But still want to use the new estimate for velocity

So firstly a "replace estimate with sum of subtasks" feature on the story would be useful - in plan mode (right mouse click on story > replace estimate, or a "sum to estimate" button on the top of the subtasks list in the detail, or even a "use sum of subtasks).

Secondly some Stories have already been worked on. If a 3 day story only has 1hr remaining this has implications as to priority, so would be useful to see this in the sprint backlog

To solve this issue above, if you showed Remaining Estimate (story+subtasks) in backlog alongside estimate you would have the two pieces of information you need - seeing the total time remaining is crucial for sprint planning but then you also need to see the detail to set priority in sprint.

Kumaran C_o7fbqh

I am also looking for a solution. Our problem is we need to estimate on the sub-task level during planning mode and then log work against sub-task during work mode. We want to see the burndown chart for everyday scrum meeting. Can you suggest?

I tried the below options

Have the Estimation Statistic based on Story Points and use Remaining Estimate and Time Spent for Time Tracking. Update the story points to be same as remaining hours at the end of planning. Below are issues I am facing with this approach

In-Progress and Done points/hours in the plan mode doesn’t show up when the time spent for sub-task is updated
It affects Velocity chart since we estimate in sub-task level and the original estimate for parent is 0

Have the Estimation Statistic based on Original Estimate and use Remaining Estimate and Time Spent for Time Tracking. This leaves to the question of whether we need to estimate the parent issue or estimate only the sub-tasks. Both approach have it’s own plus and minus

If we estimate only the sub-tasks and leave the parent original estimate with 0. This has the same disadvantage as the previous approach.
If we estimate only the parent and log work against sub-task, this does not reduce the remaining hours for parent. Burn down chart looks flat.
Finally tried with estimating parent and sub-task. Now the remaining estimate in burndown chart is doubled

I am now left out with the only option to create tasks instead of sub-task. We will have to manually create tasks and link them to parent and we will not be able to create sub-tasks from Plan mode screen. Can anyone suggest me a solution?

Ubisoft1

Hello,

I have made a workaround

I did a little something its not perfect at all should any of you do better just put it here.

- It add a button left of PLAN mode

- It work only for certain user since it can create a load on the isntance (get the issues data in rest)

It add the sum of subtask instead of story point/time estimate when you click on it. Also add a custom field (we have another kind of priority system)

Add this code into the Announcement banner

&lt;script type='text/javascript'&gt;
AJS.$(document).ready(function () {
    var username = AJS.$('#header-details-user-fullname').attr('data-username');
    console.log(username);
    if (username == 'name1' || username == 'name2(changeme)') {
        var path = window.location.pathname;
        console.log (path);
        if (path.substring(path.lastIndexOf('/') + 1).indexOf('RapidBoard') &gt; -1) {
            AJS.$('#ghx-modes').before('&lt;button class="aui-button" id="add-ubi"&gt;Show CF and Aggregate Time&lt;/center&gt;');
                AJS.$('.add-ubi').on('click', function () {
                    $('add-ubi').trigger("click");
                });
                AJS.$("#add-ubi").click(function () {
                    //AJS.$("#add-ubi").toggleClass("active");
                    //AJS.$("#add-ubi").remove();
                    AJS.$('.ghx-issues &gt; div').each(function () {
                     try {
                            console.log('Found issue list in sprints');
                            var row = this;
                            var issueKey = AJS.$(this).attr("data-issue-key");
                            //console.log('Found issuekey' + issueKey);
                        if (issueKey)
                        {
                            
                            AJS.$.getJSON(AJS.contextPath() + '/rest/api/latest/issue/' + issueKey, function (data) {
                                console.log('Got data for - ' + issueKey);
                                if (data.fields.customfield_10222 || data.fields.customfield_10222 != null)
                                {
                                    var value = data.fields.customfield_10222.value;
                                    if (value.lenght)
                                    {
                                    value = value.replace("'", "\'");
                                    var actions = AJS.$(row).find('.ghx-end');
                                    AJS.$(actions).before('&lt;style type="text/css"&gt; .ghx-issue-compact .ghx-end-ubi{position:absolute;right:-20px;top:5px;}&lt;/style&gt;&lt;div class="ghx-end-ubi"&gt;&lt;span title="Ubi Priority"&gt;' + value + '&lt;/span&gt;&lt;/div&gt;');
                                    }
                                }
                                if (data.fields.aggregatetimeoriginalestimate)
                                {
                                    var value2 = data.fields.aggregatetimeoriginalestimate / 60 / 60 / 8;
                                    var actions2 = AJS.$(row).find('.ghx-end .aui-badge');
                                    AJS.$(actions2).html(value2.toFixed(2).replace(/[.,]00$/, "") + "d");
                                }
 
                            });
                        }
                     }
                        catch (ex)
                        {
                            console.log ("ERROR");
                        }
                    });
                    AJS.$('.js-issue-list &gt; div').each(function () {
                        try {
                            console.log('Found issue list in backlog');
                            var row = this;
                            var issueKey = AJS.$(this).attr("data-issue-key");
                        if (issueKey)
                        {
                            console.log('Found issuekey' + issueKey);
                            AJS.$.getJSON(AJS.contextPath() + '/rest/api/latest/issue/' + issueKey, function (data) {
 
                                console.log('Got data for - ' + issueKey);
                                if (data.fields.customfield_10222 || data.fields.customfield_10222 != null)
                                {
                                    var value = data.fields.customfield_10222.value;
                                    console.log("we are inside of value" +issueKey)
                                    value = value.replace("'", "\'");
                                    var actions = AJS.$(row).find('.ghx-end');
                                    AJS.$(actions).before('&lt;style type="text/css"&gt; .ghx-issue-compact .ghx-end-ubi{position:absolute;right:-20px;top:5px;}&lt;/style&gt;&lt;div class="ghx-end-ubi"&gt; &lt;span title="Ubi Priority"&gt;' + value + '&lt;/span&gt;&lt;/div&gt;');
 
                                }
                                if (data.fields.aggregatetimeoriginalestimate != null || data.fields.aggregatetimeoriginalestimate != 'undefined' || data.fields.aggregatetimeoriginalestimate != "" || data.fields.aggregatetimeoriginalestimate.lenght != 0)
                                {
                                    var value2 = data.fields.aggregatetimeoriginalestimate / 60 / 60 / 8;
                                    var actions2 = AJS.$(row).find('.ghx-end .aui-badge');
                                    AJS.$(actions2).html(value2.toFixed(2).replace(/[.,]00$/, "") + "d");
                                }
 
                            });
                        }
                    }
                            catch (ex)
                    {
                        console.log ("ERROR");
                    }
                    });
        });
    }
}
});
&lt;/script&gt;

So here is it I made it quick but ajust it to your need

Martin Poirier

Ubisoft

Moriah Chandler

Related to the epic/story/subtask hierarchy mentioned above.

Working with support from Arsenale Dataplane, we are now able to view a report that includes epics, the stories in those epics, and the subtasks for those stories. Though we are using Dataplane (a paid addon), the scheme for setting up a scripted field that can be used to "segment by" epics is still useful without it.

How Dataplane solved the problem for me:

Install Script Runner addon (free).
Create a new Script Runner custom field ("Scripted Field") in JIRA, called "Master Epic" (or something similar). Here's Arsenale’s own Dataplane primer on how to set up and use Scripted Fields. Here's a more general Script Runner primer on how to use a Scripted Fields. You are going to use this field to report on the Epic that the issue is a part of, regardless of whether the issue is a parent or a sub-task issue. Scripted Fields use programming script written in a language called Groovy. It's virtually identical to Java.
After creating the field, go to the Admin>Addons tab.
Click on “Script Fields” under the Script Runner section on the left.
Click Edit.
Enter the following script:
Reindex JIRA.
If you are using Dataplane, reindex it also.
In Dataplane you can create a report that uses this scripted field to “segment by”.

import com.atlassian.jira.component.ComponentAccessor;
import com.atlassian.jira.issue.CustomFieldManager;
import com.atlassian.jira.issue.fields.CustomField;
import com.atlassian.jira.issue.Issue;
 
CustomFieldManager fieldManager = ComponentAccessor.getCustomFieldManager();
CustomField epicLinkField = fieldManager.getCustomFieldObjectByName("Epic Link");
CustomField epicNameField = fieldManager.getCustomFieldObjectByName("Epic Name");

if (issue.isSubTask())
{
    issue = issue.getParentObject();
}

Issue epicIssue = (issue.getIssueTypeObject().getName().equals("Epic")) ? issue : issue.getCustomFieldValue(epicLinkField);

return (epicIssue != null ? epicIssue.getCustomFieldValue(epicNameField) : null);

Anthony Sayce

+1 They need to fix this

Marius George3

Fix please.

Vijay Kumar

Hi, I have a question for which i am hoping to get clarification asap as my sprint has already started.

In the 'plan' mode, I see 0 as the estimate in gray bubble (in table having list of issues in scope for sprint). In the issue view on the right side of the screen, I see estimate as 0d. However, when I open this issue in a separate tab, I see that the issue has an estimate.

Q1. How come the issue actually has an estimate, but is not visible in the sprint table or on the right side?

Q2. Is it necessary that every issue in the sprint table have an estimate in the gray bubble? Reason I am asking is because if I enter an estimate in plan mode, then this estimate will get added to the actual estimate that exists (and is visible) in the issue detail view. Isn't that like double-counting?

Please help.Screen Shot 2015-08-12 at 4.45.25 PM.png

Screen Shot 2015-08-12 at 4.45.25 PM.png

David Skreiner2

Please stop suggesting expensive plugins as workarounds for Atlassian bugs.

Welcome!

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

Quick Links

Find more posts tagged with

jira

jira-software