Index
[Downloads (PDF, HTML & XML formats)]
[Other versions]
Documentation for GreenHopper 6.2.x. Documentation for earlier versions of GreenHopper is [available too].
管理図には、製品やバージョンあるいはスプリントのサイクルタイムまたはリードタイムが表示されます。管理図の横軸( x 軸)は時間を、縦軸( y 軸)は課題がステータスで消費した日数を示します。
管理チャートは、現在のスプリントから得られるデータを今後のパフォーマンスの決定に使えるかどうかを確認するのに役立ちます。課題のサイクル タイムの分散が少ないほど、その平均値 (または中央値) を今後のパフォーマンスの指標として使用することへの信頼度が高くなります。
Note that the Control Chart is board-specific, that is, it will only include issues which match your board's Filter.
Issues which are currently in statuses that are not mapped to one of the columns of the board will not be included in the Control Chart (even if those issues were in one of the mapped statuses earlier).
On this page:
Click Refine at the top right of the chart to select which column(s) to include.
The control chart includes all issues that spent time in any of the selected columns and are no longer in any of the selected columns. Therefore, selecting the To Do and In Progress columns will normally show you the cumulative time from issue creation to completion (as you will only see issues that spent time in these columns and are not located there anymore — that is, you will see all issues that are currently Done).
If you select only the In Progress column you will see the time an issue has spent in development. That is, you will only see issues that passed through In Progress but are now either located in To Do or Done. Issues that moved directly from To Do to Done won't show up; neither will issues that are still In Progress.
If you only select the last column (typically called 'Done'), you will only see issues that moved in and out of the Done column — which in most cases is not very useful. Your completed issues won't show up, as they are still located in the Done column. Selecting the last column will therefore often not make much sense, unless perhaps your rapid board maps to only part of your workflow.
Click Refine at the top right of the chart to select which swimlane(s) to include.
Click Refine at the top right of the chart to select which Quick Filter(s) to apply.
Click the date range at the top of the chart to select the timeframe.
Each issue is displayed at the last time it moved out of any of the selected columns, as the control chart only shows a single data point for each issue. The date range selector simply filters out issues that don't match that date.
Even though an issue might have been updated during a selected time range, it won't show up in the control chart unless it has been "completed" during that time.
So, for example, if you have an issue that moved on day 1 from To Do to In Progress, then on day 2 from In Progress to To Do, then on day 3 from To Do to In Progress and then on day 4 from In Progress to Done, and you select the To Do and In Progress columns on your control chart, the issue will show up as a dot on day 4, and on day 4 only.
If you now choose a date range that only covers day 2 and day 3, the example issue won't show up even though it moved through your selected columns during that time.
31 Comments
Anonymous
Jun 21, 2012This document says "Note that the control chart is Rapid Board-specific, that is, it will only include issues which match your Rapid Board's Saved Filter." This is exactly the behavior I'd expect, but not what we're seeing on our control chart. A lot of the issues included in our chart are for a deprecated product that was definitely not included in our Greenhopper Sprint (we don't even have as many issues on our Rapid Board as we see on the control chart).
All the noise is making our control chart very inaccurate. Anyone have any ideas?
Shaun Clowes
Jun 22, 2012The Control Chart in a Scrum Rapid Board does not currently use Sprint information, i.e. it shows all issues that match the boards saved filter regardless of the Sprint.
For now you could work around this by adding a Quick Filter to select the issues you care about and using that in the 'Refine...' option of the chart.
Thanks,
Shaun
Anonymous
Jun 22, 2012Thanks for the help! I misunderstood your documentation where it says “the control chart is Rapid Board-specific, that is, it will only include issues which match your Rapid Board's Saved Filter”. I thought that this was referring to the sprint backlog that is created from the rapid board’s filter, but I see that it includes all issues from the whole filter (that is, our whole product backlog). Creating a filter that picked up only items from the current sprint worked like a charm.
Anonymous
Aug 05, 2012How can i tell the cumulative time for each issue type by this chart?
e.g. - how much time "Bugs" were in "TO DO "/ "In Progress" / ....
Shaun Clowes
Aug 05, 2012That's easy enough. Just configure a Quick Filter that selects the issue types you're interested in. You can then use the 'Refine' button on the Control Chart to filter to just those issues.
Thanks,
Shaun
Sharon Peterson Misgen
Sept 04, 2012Just a note. Clicking the links 'cycle time' or 'lead time' above takes the reader to a page where the only content is a link back to this ('Viewing the Control Chart') page. It would be helpful to have more content and/or definition than this.
user-67732
Oct 02, 2012The issue I am having is viewing metrics for previous releases. Once a project is released, I am unable to view the cycle time metrics for that release. Better yet, I would like to be able to specify a date range and look at cycle times for all items that were in progress during that time. Any way to do this?
Shaun Clowes
Oct 03, 2012Hi Amanda,
I've answered your question in your answers.atlassian.com post. Regarding your desire to specify a date range, just click on the times in the heading of the control chart and choose any dates you wish. If you are not seeing these options please check you're on the latest version of GreenHopper (6.0.3).
Thanks,
Shaun
Anonymous
Oct 03, 2012This may or may not be a helpful comment, but I have read the documentation above and all the comments and still have no clear idea of what is being displayed on this chart nor what the data is useful for. It says the vertical axis indicates cards but it is clearly marked Days, a measurement of time. The points on the chart are the issues, presumably they are being plotted horizontally on the date they left one of the defined states at a vertical point that indicates how long it spent in that state. But if that is the case then the mean for that date is simply the average of how long all the issues that transitioned on that date spent in that state. Since the issues will be of widely varying complexity I do not see the value in taking the average of this time. If that is not what the average is the average of (and this is not stated anywhere clearly that I can see), what is the average being taken from? If the purpose of the chart is to predict future performance ("The less variance in the cycle time of an issue, the higher the confidence in using the mean as an indication of future performance") then surely these values have to be correlated to the story point measure of the issue's complexity?
As you can see I am completely at a loss as to what this is for. It may be an issue with me being slow, or it may be that this documentation has falling into the old trap of being useful only to people who already understand what is being explained.
Shaun Clowes
Oct 03, 2012Hi,
Thanks for comment. You're right about the "vertical axis indicating cards" part of the documentation was incorrect, I've fixed it now.
This control chart is one of the key mechanisms by which a Kanban team optimizes their lead time and cycle time. The individual dots on the chart represent the amount of time an individual issue spent in the selected statuses (if you select all columns apart from Done you will get cycle time, if you select all statuses other than In Progress and Done you will get lead time). The moving average line shows the trend of recent cycle/lead time.
Most Kanban teams do not estimate issues, thus issue count is the only way to measure cycle/lead time. There are two takes on the differing story size problem, the most obvious is to break down stories until they are all of similar size. Alternatively you can consider the 'stable state' of the team, that is, the team will mostly be dealing with the same mix of small/medium/large stories over time, as a result the cycle time is still predictive of the amount of time it will take to get n issues with that mix completed.
Thanks,
Shaun
Anonymous
Oct 04, 2012Thanks, that makes it very clear
Anonymous
Jan 10, 2013Hello,
Thanks for the information. I have some comments/questions regarding your response:
I have found that Kanban backlogs often contain a lot of work that should not be prioritized immediately; that would be non-value-added work for a product owner. As a result, Kanban boards may have an additional work state: Backlog/To-Do, Selected, In Progress, Done. (Individual teams will redefine the specifics of In Progress to match their workflow.) The product owner only prioritizes and moves items to Selected based upon capacity of the team. Thus, Lead Time is measured from Selected to Done. Measuring Lead Time starting with the Backlog inflates the actual team's cycle time.
Regarding the control chart, having the scatter diagram of cycle time versus date is useful for new, unstable teams. More stable teams might find it more useful to have a frequency distribution chart of cycle time, showing counts versus cycle times. Any plans to add that for Kanban?
Lastly, is there a chart for monitoring WIP over time without looking at the Cumulative Flow Chart and subtracting by hand?
Thanks!
Shaun Clowes
Jan 10, 2013This depends on your perspective and unfortunately lead time and cycle time don't mean the same things to all people. I take the view (that is reasonably widespread) that lead time measures 'customer annoyance time', i.e. how long on average will my customers have to wait for me to deliver the expected result (including prioritization effort). Of course, that's only really applicable when Kanban is used in a service queue style environment, if you're using it for general software development then I tend to agree with your approach. In any case, you can easily measure this in the control chart, just unselect the 'Backlog/To-Do' status in the Refine section.
No plans, but you should be able to get a feel for this viewing the control chart across a long period (note that the shaded sections represent standard deviations so give you a feel for the distribution).
You shouldn't need to subtract. Just use the Refine button to select only the WIP statuses. The chart will then show the WIP across the timeline.
Cheers,
Shaun
user-1bcb2
Nov 06, 2012What issue types are included in the control chart? All? Just stories and Epics? Some other sub-set? Please clarify.
Shaun Clowes
Nov 07, 2012All issue types (including sub tasks) are included unless you define filters to ignore them.
Thanks,
Shaun
user-1bcb2
Nov 07, 2012Thanks Shaun. That's odd and, for whatever it is worth, inconsistent with Scrum velocity which if I understand correctly is based on stories and epics only. Wouldn't it make sense to exclude bugs for example...?
Shaun Clowes
Nov 07, 2012Nope, the Velocity chart will take in to account any issue (not sub tasks) that have an estimate value. You can easily achieve the same outcome if you wish in the control chart by defining a quick filter then applying it from the 'Refine...' button.
Cheers,
Shaun
user-1bcb2
Nov 07, 2012Really? The documentation pretty clearly say's "all completed stories" and does not mention other issue types. See: "You can estimate your team's velocity based on the total Estimate (for all completed stories) for each recent sprint"
It also appears that only stories and epics have an "estimate" field that is specific to the rapid board (and tallied in the sprint plan (vs. the "original estimate" field that all issue types have which does not appear to be tallied up in any rapid board views)...?
Sorry if I am dim, but this is all quite confusing and I could really use some clarification.
Shaun Clowes
Nov 07, 2012Hi Paul,
Agreed that the "for all completed stories" bit is confusing. Basically the velocity report will show the sum of the estimate for all issues (that are not sub-tasks) at the start of the sprint. By default the Story Point field is only associated with Epics and Stories, so those are the only ones that would appear in the velocity chart for a board configured with Story Points as the estimate value, but you could easily apply the field to any other issue types you wished.
The Original Estimate is treated in exactly the same way as Story Points except that the Original Estimate field is always available for all issue types. The velocity chart for a board configured to use Original Estimate as the estimate value will simply show the sum of the original estimates for the issues at the start of the sprint.
Hope that clarifies a bit.
Cheers,
Shaun
eciryanb
Nov 08, 2012I like the control chart and the potential it provides to show a good overview of how various tickets are moving through our workflow on a time basis. What I don't understand, however, is how time is really logged. I've set the JIRA time-tracking settings to say that a day is eight hours. But this chart (and others) is obviously not taking that setting into account. If a developer starts a ticket ("in progress") late in the afternoon and then closes it early the next morning (maybe two hours of time overall), the ticket will say it was "in progress" for 16 hours. But it wasn't. Having developers move tickets in and out of statuses every day seems like overkill.
I used to think that when JIRA said "1 day" it meant eight hours... but then I'm not sure how any ticket can have more than "7 hours, 59 minutes" before turning over a day - but all of my tickets go up over 8 hours, so I'm really confused. My developers work 8 hour days, not 24 hours... so I'm not sure how it's helpful to me that the system reports they worked on a ticket for 24 hours... but it was really only 8.
I really have searched (I think) on the way JIRA reports time and uses the time-tracking settings, but there just seems to be very little detailed information about it.
What am I missing?
Jim Kreuziger
Nov 22, 2012I believe that the control chart is not measuring time spent on tasks, but rather the total elapsed time from "Open" to "Closed" (moved out of "Resolved"). So if your developer logs 2h on a ticket that was put "In Progress" in the last 2h of the work day. He leaves work, and comes back 10h later. He then works on something else the first 2h of the morning, and then puts in another 2h before closing the ticket. That's 2h + 10h + 2h + 2h = 16h.
You are correct that the control chart shows a good overview. I'm a noob at this, but I see it as a way to really track WIP and validate my attempts to reduce it.
Jim Kreuziger
Nov 22, 2012I really like this chart. The only real complaint is that the colors make the chart almost unreadable. You have the "Cycle Time Mean" as a nice blue line, and the "Standard Deviations shaded". Only problem is that there is so little contrast between standard deviations that I can't tell what happening.
user-86a2e
Dec 16, 2012Hi, We want to model our data in other reports -is it possible to connect to the GreenHopper database tables and extract the data, which we could then do what we liked with?
Any help much appreciated. Thanks, James.
Rosie Jameson [Atlassian]
Jan 06, 2013Hi James, you may like to vote/watch/comment on GHS-4288 - Getting issue details... STATUS
Alexander Fedtke
Feb 02, 2013Hi we using the kanban control chart with version 6.1.2 we have following status and (columns):
open (to do)
in progress (in development)
resolved (ready for branch)
When i refine the control chart to give me the lead time for in development column (time issues spent in progress status) i got the cycle time of the "to do" column (time issue spent in open status). I checked this in the detail view of an issue in the tab transition summary. There i can see that the time shown in the control chart is the "time issue spent in source status of open".
Is this a new bug?
RenjithA
Feb 01, 2013Probably you should be posting this query in Answers (with screenshots too)
From your description, it appears to be showing correctl. When you say the lead time for development, isn't it the time that is spend in the Open status?
Alexander Fedtke
Feb 02, 2013Sorry i misused lead time when i mena the cycle time anyway. When I select in the control chart via refine the "development" which is defined in the rapidboard by showing all issue which have status "in progress" than i asume that i should get time spent in status in progress right?
Pål Werdenhoff
Feb 27, 2013Hi,
Using the greenhopper REST API I am able to get the following JSON output
{"totalTime":[4585000,0,0,634000,3351257000,17894000,75210000,86409000,0,43124992,0],"workingTime":[4585000,0,0,634000,3351257000,17894000,75210000,86409000,0,43124992,0],"leaveTimes":[1358430112000,-1,-1,1358430746000,1361782003000,1361799897000,1361875107000,1361961516000,-1,1362004640992,-1]
The parameter names seems intuitive enough, but I would love if anyone can give me an explanation anyway, as well as some details on how to express these times/dates into a readable format? I can´t seem to map these times to the days/hours/minutes I am seeing per status in the cycle chart for an issue.
Shaun Clowes
Feb 27, 2013It sounds like you're using internal REST endpoints that are subject to change, so please be aware of that.
For cases like this I'd recommend looking directly at the GreenHopper source code, all commercial licensees (i.e. anyone not in the 10 user tier or on a community/open source license) can access it from their account page on https://my.atlassian.com.
Thanks,
Shaun
Pål Werdenhoff
Mar 04, 2013Thanks for a fast reply Shaun Clowes. I am using this rest/greenhopper/1.0/rapid/charts/controlchart?rapidViewId=92 to get this output. I have excluded the swimlane and column parameters here though. Are all the REST functions in this wadl considered internal, and subject for change?
/rest/greenhopper/1.0/application.wadl
Daniel Eichling
Feb 28, 2013Hi, I've noticed in our control charts, similar to the one with the picture illustrated in this article, has an aggregated mean of X days that when viewing 2 week windows seems to assume 2 days. This is OK except for weekends, and even when we tell the control chart to exclude non-working days from the chart, it still seems to affect the aggregated mean. Is there a way to fix this and are we doing something wrong? The line with this behavior seems a little useless and we generally ignore it since it feels so innacurate except for 2 or 3 days out of each week.