Index
[Downloads (PDF, HTML & XML formats)]
[Other versions]
Documentation for GreenHopper 6.2.x. Documentation for earlier versions of GreenHopper is [available too].
This page only applies to Scrum boards.
About Estimation and Tracking
Many Scrum teams separate estimation (which is used for measuring the size of a backlog and calculating velocity) from tracking (which is often the burndown of hours used during the Sprint to be sure we're not way off the pace necessary to complete the stories in the Sprint timebox), and use different units for each. A common approach is to estimate tasks in Story Points, then track tasks using hours. GreenHopper therefore gives you the flexibility to set your estimation and tracking statistics differently, depending on what best suits your team.
Product teams often need to be able to estimate how long a product will take to deliver. This is tough because the backlog may stretch many months into the future, so the team can only provide a very rough estimate in conditions of uncertainty without wasting days breaking the work down. However, from sprint to sprint as they work through the stories the team will develop a cadence of completing <x> units of work they had 'rough estimated', i.e. their velocity. This means that they can relatively accurately estimate how long portions of the backlog will take to get done with simple rough estimates that the team can produce way before they even consider doing them. However, to make this work the team needs to estimate stories with a consistent level of uncertainty. The team also needs to track the amount of estimation units they have actually fully completed from sprint to sprint because this number is the one that tells us with relative certainty how much we can fit into each future sprint and have conviction that they will all be completed.
Choose your own Estimation Statistic and Tracking Statistic
In GreenHopper, you can choose which type of units (e.g. Story Points, Issue Count) will be used for estimating and tracking issues. You do this by choosing an Estimation Statistic, then choosing to either use the same units for your Tracking Statistic or to use time-tracking. Each board can have a different type of Estimation Statistic and Tracking Statistic.
- The type of Estimation Statistic you select affects which units are used by the 'Estimate' field, which appears at the right of each issue in Plan mode: (Note that the 'Estimate' field is editable when an issue is in Plan mode, but not editable once the issue moves into Work mode.)
- The type of Tracking Statistic you select affects which units are used by the 'Remaining' field, which appears at the bottom right of each issue in Work mode:
View your Velocity and Burndown
A team's velocity is based on the Estimation Statistic — ie. for each sprint, the velocity is the sum of the Estimation Statistic for completed stories. Velocity is shown in the Velocity Chart and also on the Sprint Report, in the Estimate Statistic column header of the "Completed Issues" table (e.g. "Story Points (12)" means that 12 Story Points were completed in that sprint). Please note that the values for each issue are recorded at the time when the issue moves into the sprint. Changing the Estimate value afterwards will not be reflected in the Sprint Report, but will be shown as scope change in the burndown. Velocity is also used in the Version Report, to predict Release Dates.
The Sprint Burndown Chart is based on the Tracking Statistic. If you are using Story Points as your Tracking Statistic, then the Burndown Chart shows the Story Points per story (ie. stories burning down the Estimate Statistic are only burnt down on the graph as they are completed); whereas if you choose the Time-tracking option you are shown partial burndown (ie. the number of hours currently used and remaining each day).
Setting the Estimation Statistic
To set the Estimation Statistic for a board:
- Select Agile > Manage Boards from the top navigation bar, then click the Configure link corresponding to the board of interest. Note that only the owner of a board (or a person with the 'JIRA Administrators' global permission) can configure a board.
- Click the Estimation tab.
In the Estimation Statistic field, choose one of the following options:
Estimation Statistic:
Explanation:
Story Points
Estimation will be based on the number of Story Points per issue. This is the most commonly used option.
(
Note that, by default, the Story Points field is only available to issues of type 'Story' or 'Epic' — you can change this as described in GreenHopper JIRA Configuration.)Business Value
Estimation will be based on the Business Value of each issue.
Original Estimate
Estimation will be based on the JIRA 'Original Estimate' field (for details see the JIRA documentation Logging Work on an Issue). By default this is specified in minutes, but it can be hours/days/weeks depending on your JIRA system configuration (for details see the JIRA Time Tracking documentation).
Issue Count Estimation will be based on the number of issues in the sprint. The 'Estimate' field will not be editable. <Custom Field> Estimation can be based on any numeric custom field in your JIRA system.
Screenshot: the 'Estimation' tab (click to enlarge)
Enabling Time Tracking
To set the Tracking Statistic for a board:
- Select Agile > Manage Boards from the top navigation bar, then click the Configure link corresponding to the board of interest.
- Click the Estimation tab.
In the Time Tracking field, choose one of the following options:
Tracking Statistic:
Explanation:
None
Tracking will be based on the Estimation Statistic.
Remaining Estimate and Time Spent
Tracking will be based on the JIRA 'Remaining Estimate' and 'Time Spent' fields (for details see the JIRA documentation Logging Work on an Issue). By default these fields are specified in minutes, but you can use hours/days/weeks depending on your JIRA system configuration (for details see the JIRA Time Tracking documentation).
Note that this is fundamentally different from using the Estimation Statistic for burndown in that values do not burn down when an issue is completed — instead, values only burn down when users enter Time Spent or set the Remaining Estimate to a new value.
Overview
Content Tools
Apps
Log a request with our support team.
Raise an issue for our developers.
See answers from the community.
Tweet, blog and update our documentation.
Except where otherwise noted, content in this space is licensed under a Creative Commons Attribution 2.5 Australia License.
67 Comments
Mike ambrosone
Jun 05, 2012Hi,
The Rapid board is really simple to use but we have an issue with one thing. When configuring the field "Estimation Statistic" to "Original Time Estimate" we noticed the following:
Is there any configuration I need to set?
Anonymous
Oct 01, 2012I have created an ticket for this problem. (https://jira.atlassian.com/browse/GHS-5653)
The problem is, that they don't plan to change this behaviour.
Anonymous
Jun 13, 2012I have the same problem.
Anonymous
Jun 14, 2012What does it mean if I don't see the Estimate tab? I see Filter, Columns, Swimlanes, and Quick Filters, but that's it. Please advise. Thanks!
Rosie Jameson [Atlassian]
Jun 19, 2012Can I ask which version of GreenHopper you are running? The Estimation tab was introduced in 5.9.7, and the Tracking option was added in 5.9.8.
Anonymous
Aug 29, 2012I don't see the estimation tab either and I am using Atlassian GreenHopper (v6.0.1)
Nicholas Muldoon [Atlassian]
Aug 29, 2012Hello,
That sounds like you are on a Kanban board. Please go to the Getting Started page and create a Scrum board.
Thank you,
Nicholas Muldoon
@GreenHopperTeam
Anonymous
Jun 15, 2012I have the same issue - I believe its permission related
Lucas Nelson
Jun 18, 2012Same issue as Mike. It's ignoring the original estimate, time spent, time remaining of the sub-tasks of the Story tickets in the Sprint. This renders the Rapid Board burndown chart useless for our team
as we use sub-tasks for the Sprint Backlog. This is not the only case of sub-tasks not being supported around the Rapid Board functions. Here's hoping they've just not got around to it yet.
Anonymous
Jun 26, 2012I have the same problem... You cannot breakdown Workitems work in subtasks so the Workitem effort can be assigned to more than one person at the same time. It's useless at all.
TylerA
Jun 22, 2012Hey folks. This issue has been detailed in GHS-5283 - Getting issue details... STATUS
Add comments and vote to get the GreenHopper team to take notice!
Anonymous
Jun 26, 2012Hey ...
That issue is not reachable.... Greenhooper does not work at all.
Dejan Pazin
Jun 27, 2012I also can't see the GHS-5283 issue, but would like to vote for it.
Anonymous
Jul 05, 2012Please make this issue external visible.
Anonymous
Jul 10, 2012We would really like to see GHS-5283 in the next release of GreenHopper!
Markus Pulch
Aug 08, 2012Hi, I also cannot see/vote this issue. Having subtasks times not aggregated is a blocker for us.
Rob Barreca
Aug 15, 2012I have the same request as Mike and cannot see this issue. I'd love to vote on it!
Anonymous
Jun 25, 2012It looks as though this is only available for a scrum board not a kanban board (no estimation tab). Is there any way to have this on kanban. We currently use the kanban board to do a lot of our scrum work as the scrum board is still way too immature to work with.
Anonymous
Jul 10, 2012Hello, yes this would be such a nice feature. It's painful to keep track manually of the summed up time estimates of each sub-task in order to get an estimate for each story. Also, open access to the issue so we can vote on it would be lovely. thanks!!
Anonymous
Jul 12, 2012Yeah I just signed up for greenhopper and noticed the same problem. Too bad it doesn't show the estimate for the task.
They should definitely change this!
Markus Pulch
Aug 08, 2012Is there any option to use the Remaining Estimate instead of Original Estimate?
Use Case: a story with Original Estimate of 20h was not finished within a sprint (Remaining Estimate is 4h). While finishing the sprint the story is added to the top of the backlog and shown as 20h. For sure this has an impact on the Team commitment.
Is there any option to change this behavior? If there are subtasks existing then in ideal case it should show the aggregated Remaining Estimate. So it would be great to have an additional option of 'Remaining Estimate' in the 'Estimation Statistic' dropdown
Georgi Mitov
Jan 20, 2013Fully agree with Markus. We have exactly the same issue. It makes a lot of sense to display the Remaining estimate when using a time-based estimations.
Atlassian Support: How this can be achieved?
Rosie Jameson [Atlassian]
Jan 29, 2013You may like to watch/vote/comment on GHS-5794 - Getting issue details... STATUS
Anonymous
Aug 13, 2012I agree with Markus. I would like to use remaining estimate instead of original estimate in the planning mode.
Anonymous
Aug 14, 2012Hi!
How can we track how much time was planned for a person in the sprint vs. the person's individual capacity? On the Classic Planning board I can at least create a statistic based on Remaining Work and set a max value. Then I can see the grey bar on the planning board that shows per person which work will fall off the plate.
How can I do this with the new rapid board? There seems to be absolutely no ability to see how many hours were planned per person and how many hours are remaining in the sprint per person.... Or am I missing something?
Thanks!
Anonymous
Sept 03, 2012I have the same issue. I don't have a way to realize how many hours were planned per person during a planning and how many hours were spent by a person during the sprint.
Moreover I can't use old JIRA reports because they are based on a version field (Green Hopper uses a sprint field instead of it).
Michael Bennette
May 14, 2013I have been waiting for this to be built into GreenHopper for years. For a team that chooses to estimate tasks, it's helpful to see all the of time estimates rolled up. THEN compare that to individual capacity that can be set somewhere. That way if someone is over or under-allocated, we can make the changes accordingly in the sprint planning meeting.
As a SM, it's been embarrasing for me to say multiple times now that GH does not compare this for us. I have had individuals or teams often ask me "How do I know if I've signed up for too much?". I have to use a separate spreadsheet to compute capacity and then compare to that to estimates by adding it all up manually. If we don't do this, then indeed we risk over allocating an individual. As a SM, part of my job is to make sure the task ownership is not imbalanced.
Does anybody know if there is a request already logged for this so we can vote on it? Or if Atlassian has any plans to implement this? It looks like GHS-5774 - Getting issue details... STATUS might be one logged but this is a minor priority so I'll have to keep looking. In my opinion this is important feature to have. I had this in RallyDev and it was very useful and I would love to see that in GH.
Tom Kotecki
May 14, 2013Hi Michael,
The reason capacity planning is currently not present in GreenHopper is because it goes against the idea of team commitment - as opposed to commitment from a collection of individuals.
Having said that, we do realise some users end up capacity planning anyway and we plan to address this at some point in the future. I don't have any concrete timeframes at this point, though.
Hope this helps
Tom Kotecki
Product Manager, GreenHopper
Anonymous
Aug 14, 2012Hi,
The documentation says "Alternatively, you can choose any numeric custom field on your JIRA system". How do you do that? None of my custom fields show up in the drop down.
Thanks for any help!
Anonymous
Aug 31, 2012We need to have a way to have the burndown chart be based on total issues (tasks, sub-tasks) for the y-axis in the current sprint but also be able to enter an original estimate and remaining estimate on a per task basis. Is there a way to do this??
Dimi
Sept 24, 2012Hi,
If i configure Estimation statistic = "Estimate time and Tracking"= "Remaining estimate and Time spent", i see only Issue Count, and Estimate summary in Sprint footer.
But in example, the footer of sprint contains also the sum of Remaining hours.
How can I get this shown be me?
I am currently using Greenhooper V.6.0.2
Thanks
Dimi
Sept 28, 2012Ok,
i found it out. This feature was implemented first in v. 6.0.3 on Greenhopper
Thanks anyway.
Anonymous
Oct 18, 2012Unfortunately, the total count of remaining hours is being expressed in weeks, days, hours. This would be useful if there is only 1 person doing the work...
It would be more useful to display the total number of hours, especially since this can be compared against the team's calculation of available hours.
Anonymous
Dec 04, 2012Agree! Can this be configured or are we stuck with the sprint estimate displaying in weeks and days? Would love to see this in hours!
Anonymous
Dec 05, 2012You can change the format of the displayed time in your time tracking configuration.
This changes the time format for the whole JIRA.
Keyhan Hadjari
Sept 28, 2012Hi, When creating a Story with original estimate and then adding sub tasks to it, the sub tasks add to the remaining time but not the original estimate.
The way the estimate calculation is now it is impossible to create sub tasks to the story in sprint planning and finish them off in the sprint and have correct statistics. Either you have to set the original estimate of the story to 0 and so you get a faulty velocity but correct remaining time when finishing sprint or you set original estimate but you get faulty remaining estimate for story since it is calculated as sum of subtasks + original estimate.
Please fix this by allowing original estimate time of a story to be sum of its subtasks before the sprint begins. After the sprint begins, if a sub task is created then add its estimate to the remaining.
O. Segal
Sept 29, 2012I have a question regarding the Time Tracking using "Remaining Estimate and Time Spent" -
Do values burn down for stories only, or also for sub-tasks? (coming to think of it, the question is also relevant to using the "None" time tracking, in which burndown is based on original estimation).
Thanks.
Jeremy Johnson
Oct 02, 2012Is it possible to display both the totals of Story Points and Original Estimate for a sprint in the Plan view? We've estimated the story points and now the team wants to know the total number of hours estimated before making a commitment. This is our first sprint, so we have no baseline on which to establish confidence of our velocity in Story Points. As a workaround, I can just change the board configuration to use Original Estimate–just wondered what others do.
Anonymous
Oct 18, 2012Has anyone responded to this request? Seems like it would be a pretty simple, but potentially quite valuable, addition to allow us to show both Story points and the Original Estimate (and even Estimated Remaining) time.
Jeremy Johnson
Oct 18, 2012No response.
Anonymous
Oct 09, 2012It would be nice, if JIRA would consider sub-tasks if the estimation set to "issue count" (We have a limited number of user stories and a lot of sub-tasks)
Kirsteen
Nov 02, 2012I have just started using JIRA 5 (was JIRA 4 in last company) and want to track sub-tasks by time in a sprint. We go into the sprint with the points we believe that we can do in the sprint, but break them into tasks which are estimated in hours/days and assigned to team members. I could do this in version 4, but not version 5 it seems. Can anyone help me? I am considering the "custom field". Thanks!
Nicholas Muldoon [Atlassian]
Nov 16, 2012Hi Kirsteen,
Have you got Time Tracking turned on for your board? Instructions can be found on Configuring Estimation and Tracking.
Thanks,
Nicholas Muldoon
@GreenHopperTeam
Anil Pillai
Nov 20, 2012Nicholas Muldoon [Atlassian], We have a situation where we need to change the estimate of an issue within the current sprint. E.g. We start off with say story points 4, but 3 days into sprint, we might find more details and find out htat we either need to bump it to 8 or down to 2 based on the level of work. Any idea how to make that field "editable" in the current sprint. Currently the only way I can do it is (a) remove it from sprint (B) change the estimate and (c) add it back in sprint. That is non-intuitive. Shouldnt this be reflecting reality whereby in many cases we go with an estimate, and need to change it based on the level of work required.
I am the administrator. Can this be editable by any team member for their current tasks in a sprint?
Many thanks!
Nicholas Muldoon [Atlassian]
Nov 20, 2012Hi Anil,
Generally a team would not change the estimate of an issue once it is in a sprint - this is an estimate, a guess, and all estimates in the backlog will have a similar level of uncertainty. If you re-estimate an issue once you know more about it during the sprint it then has a higher level of accuracy than all the other estimates in the backlog. Ultimately this will lead to uncertainty around the teams velocity.
So, long story short, I would recommend that you do not re-estimate the issues once they are in a sprint. You can still re-estimate during a planning meeting of course - that is prior to commitment.
If that doesn't convince you then I recommend you use the 'e' keyboard shortcut to bring up the Edit dialog and change the estimate there.
Thanks Anil,
Nicholas Muldoon
@GreenHopperTeam
Anil Pillai
Nov 20, 2012Thanks Nicholas Muldoon [Atlassian]. Let us try what you recommended, and see how it goes. Along similar lines, I did try to "e" (cool feature thanks!) and noticed that the estimate is only available in terms of time (original/new estimate) and not in terms of story points. Is there a way we can set the estimate to story points. Later on we might try playing poker, and something like this will be handy. Thoughts?
Cheers
Nicholas Muldoon [Atlassian]
Nov 20, 2012Let me know how you get on.
For story points, see earlier up this page for instructions on how to change your board to use story points for estimation.
Thanks,
Nicholas
Anil Pillai
Nov 21, 2012Sure thing. Will do. Thanks again.
Anonymous
Dec 06, 2012what confounds me, as early on in this set of posts, that the current behavior of stories with subtasks (i.e. subtask estimate times are NOT rolled up to the story) breaks the burndown chart, as the burndown chart target line displays the STORY orig estimate. What are we doing wrong?
Rosie Jameson [Atlassian]
Dec 18, 2012If you have enabled Time-Tracking, then you shouldn't be experiencing this. Can you please contact http://support.atlassian.com ?
Kevin
Jan 16, 2013We are adding sub-tasks to a story to capture time estimates from the team, and had been capturing a time estimate at the story level for system testing time. I'm curious how others are capturing system test time needed and whether they are considering that part of the sprint effort or separate?
Andy Grace
Feb 26, 2013Is there any way to get story points (or whichever estimation used) total to appear in each column on the planning board (so we would see To Do x points, In Progress y points, Done z points etc?
Rosie Jameson [Atlassian]
Feb 26, 2013You may like to watch/vote/comment on GHS-4917 - Getting issue details... STATUS (unless I have misunderstood your requirements, in which case can you please contact http://support.atlassian.com ?)
Andy Grace
Feb 26, 2013Thanks Rosie
I don't have access to the external link of that issue - my requirement is just to total up the points in the column and display at the top - is this the same or should I raise another?
Andy
Rosie Jameson [Atlassian]
Feb 26, 2013I think the issue is a good match for what you describe, and would recommend that you add what you've just said as a comment on the issue, and also vote for it
Don Ambridge
Mar 15, 2013I don't see the Estimation tab in my configure screen at all??
Rosie Jameson [Atlassian]
Mar 17, 2013Can I ask which version of GreenHopper you are using? (The Estimation tab was introduced in version 5.9.7)
If you are using 5.9.7 or later, and not seeing the Estimation tab, can you please contact http://support.atlassian.com for assistance? Thank you
Don Ambridge
Mar 15, 2013I don't see the Estimation tab in my configure screen at all??
Tom Wilhelm
Mar 20, 2013Maybe someone can help me understand how this is supposed to work.
I have a project up and running, using Story Points as the estimation value and Time Tracking turned on.
Issues in the Backlog are all given Story Points and velocity is determined from there. All good. The question is about establishing remaining estimates at the beginning of a Sprint to let us do Tracking.
We drag our stories into the proposed Sprint. We create subtasks for each in order to break down the work and allow us to assign to multiple developers. The remaining estimates on the subtasks should roll up to the remaining estimates on the issue. Which they do, but only AFTER the Sprint starts. The problem I'm having is that BEFORE you start the sprint, you can only set Remaining Estimate on the issues and not the subtasks. And if we wait until after starting the Sprint to do our remaining estimation at the subtask level, any changes (from 0 to whatever) for Remaining Estimates counts as a scope change in the burndown chart.
What am I missing here? Do we have to set a Remaining Estimate at the issue level, THEN start the Sprint, THEN remove the issue level estimates while adding subtask estimates? That can't be right, can it?
Any advice would be appreciated.
Kelsey
Mar 25, 2013Yes I have exactly the same problem, including the issue mentioned by others where a story runs across multiple releases and sprints, advice would be appreciated.
Rob Bastian
Apr 24, 2013I realize it's verboten in strict Kanban to use estimations but that's how we roll at my company. Could you please make the Kanban boards configurable for hourly/story point estimates. I'd owe you one.
Thx!
rb
Rosie Jameson [Atlassian]
Apr 28, 2013You may like to vote/watch/comment on GHS-7265 - Getting issue details... STATUS
Andy Clapham
May 28, 2013Different question re tracking:
I'd like to try a burn down of story points pro-rata against the sub task completion. So say a story had 3 sub-tasks, and a story-point estimate of 9, each time a sub-task is resolved, the burn-down moves 3 points. We don't want to use time-tracking, and only estimate at the story level; but we think this might improve the ability to see if a sprint is on track.
To generalize, it sounds interesting to have some extension point for the value being graphed in burn-down charts. I.e. rather than burning down on a field, to be able to provide a plug-in to provide a value to burn-down on.
boardtc
Jun 10, 2013The documentation begins
Prior to GH 6 one could have a burndown chart of the story points left and also the time left. Since one estimates in story points it is also common to see the story points burndown and also track the remaining time. To see both the story points burndown and also the remaining time one has to toggle the tracking statistic between none and Remaining Estimate and Time Spent. It should be possible to configure so both burndowns can be seen without having to toggle configuration.
I created a story for this, please vote:
GHS-9148 - Getting issue details... STATUS
Carl Abelin
Jun 18, 2013If I add time to an issue via 'Log work' and chose a different date than the one given in 'Date Started' the time is not used in the Burndown Chart nor listed in the list below the chart.
Is this how it should be and in that case why? It messes things up if people forget to report time when they should.
Carl Abelin
Jun 18, 2013If I add time to an issue via 'Log work' and chose a different date than the one given in 'Date Started' the time is not used in the Burndown Chart nor listed in the list below the chart.
Is this how it should be and in that case why? It messes things up if people forget to report time when they should.
lku
Aug 13, 2013Hi All
https://www.atlassian.com/software/greenhopper/overview mentions t-shirt estimation. How is it possible to configure such estimation with some statistics available?