Documentation for GreenHopper 6.2.x. Documentation for earlier versions of GreenHopper is [available too].

管理図には、製品やバージョンあるいはスプリントサイクルタイムまたはリードタイムが表示されます。管理図の横軸( x 軸)は時間を、縦軸( y 軸)は課題がステータスで消費した日数を示します。

管理チャートは、現在のスプリントから得られるデータを今後のパフォーマンスの決定に使えるかどうかを確認するのに役立ちます。課題のサイクル タイムの分散が少ないほど、その平均値 (または中央値) を今後のパフォーマンスの指標として使用することへの信頼度が高くなります。

コントロール チャートの表示

  1. 上部ナビゲーションバーで Agile リンクの下矢印をクリックし、表示されるドロップダウンメニューから目的のボードを選択します。

  2. Click Report, then select Control Chart from the drop-down at left. The Control Chart for your current sprint will be displayed (see screenshot below).
    • グラフの上にカーソルを置くと、移動平均の値が表示されます。
    • By default the chart will select all column(s) other than the first and last (usually the 'To Do' and 'Done' columns). Since the chart shows the average amount of time each issue spent in each of these columns this means that the default chart shows cycle time. To re-draw the chart to show lead time use Refine (as below) and select all columns other than the last
    • To re-draw the chart excluding a column(s) or swimlane(s), or to apply a quick filter, click Refine (see below for more details).
    • To select a different timeframe (past week/past month/past 3 months/past 6 months/all time/custom), click the date range at the top of the chart (see below for more details).
    • To include Non-Working Days in your Cycle Time calculations, select the check-box below the chart.

(info) Note that the Control Chart is board-specific, that is, it will only include issues which match your board's Filter.

(warning) 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:

関連ページ

スクリーンショット: 管理チャート

 

 

Refining the Control Chart

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

  1. Anonymous

    This 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?

    1. Shaun Clowes

      The 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 

      1. Anonymous

        Thanks 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.

  2. Anonymous

    How 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" / .... 

    1. Shaun Clowes

      That'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 

  3. Sharon Peterson Misgen

    Just 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.

  4. user-67732

    The 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?

    1. Shaun Clowes

      Hi 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 

  5. Anonymous

    This 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.

     

    1. Shaun Clowes

      Hi, 

      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 

      1. Anonymous

        Thanks, that makes it very clear

      2. Anonymous

        Hello,

        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!

        1. Shaun Clowes

          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.

          This 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. 

          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?

          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). 

          Lastly, is there a chart for monitoring WIP over time without looking at the Cumulative Flow Chart and subtracting by hand?

          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 

  6. user-1bcb2

    What issue types are included in the control chart? All? Just stories and Epics? Some other sub-set? Please clarify.

    1. Shaun Clowes

      All issue types (including sub tasks) are included unless you define filters to ignore them. 

      Thanks,
      Shaun 

      1. user-1bcb2

        Thanks 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...?

         

        1. Shaun Clowes

          Nope, 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 

          1. user-1bcb2

            Really? 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.

            1. Shaun Clowes

              Hi 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 

  7. eciryanb

    I 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?

    1. Jim Kreuziger

      I 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.

  8. Jim Kreuziger

    I 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.

  9. user-86a2e

    Hi, 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.

    1. Hi James, you may like to vote/watch/comment on GHS-4288 - Getting issue details... STATUS

  10. Alexander Fedtke

    Hi 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?

     

    1. RenjithA

      Probably 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?

      1. Alexander Fedtke

        Sorry 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?

  11. Pål Werdenhoff

    Hi,

    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. 

    1. Shaun Clowes

      It 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 

      1. Pål Werdenhoff

        Thanks 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

  12. Daniel Eichling

    Hi, 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.