Uploaded image for project: 'Jira Software Data Center'
  1. Jira Software Data Center
  2. JSWSERVER-1969

As a GH user I would like to see a cumulative flow diagram

XMLWordPrintable

    • We collect Jira feedback from various sources, and we evaluate what we've collected when planning our product roadmap. To understand how this piece of feedback will be reviewed, see our Implementation of New Features Policy.

          Form Name

            [JSWSERVER-1969] As a GH user I would like to see a cumulative flow diagram

            Nicholas Muldoon [Atlassian] added a comment -

            Hello,

            Resolving this as fixed as a CFD was released in GreenHopper 5.2. There is an ongoing discussion in GHS-2450 and also on the kanbandev Yahoo Groups if you are interested, it touches on the ordering of the columns from the task board mapping.

            Thank you.

            Regards,
            Nicholas Muldoon

            Nicholas Muldoon [Atlassian] added a comment - Hello, Resolving this as fixed as a CFD was released in GreenHopper 5.2. There is an ongoing discussion in GHS-2450 and also on the kanbandev Yahoo Groups if you are interested, it touches on the ordering of the columns from the task board mapping. Thank you. Regards, Nicholas Muldoon

            Jacques Chatenet added a comment -

            My pleasure Steve, love your blog

            Didn't have time yet to test but seems does pretty much the job, except, should re-order the items.
            (Done job should be put at bottom of chart)

            See here:
            http://confluence.atlassian.com/display/GH/Viewing+the+Cumulative+Flow+Chart?focusedCommentId=223217050&#comment-223217050

            Jacques Chatenet added a comment - My pleasure Steve, love your blog Didn't have time yet to test but seems does pretty much the job, except, should re-order the items. (Done job should be put at bottom of chart) See here: http://confluence.atlassian.com/display/GH/Viewing+the+Cumulative+Flow+Chart?focusedCommentId=223217050&#comment-223217050

            Steve Lane added a comment -

            Thanks for the citation, Jacques

            Is this one not resolved with the release of 5.2?

            Steve Lane added a comment - Thanks for the citation, Jacques Is this one not resolved with the release of 5.2?

            Jacques Chatenet added a comment -

            1 more vote.
            In our case, CFD is more useful than Burn Down Chart because whatever the best intents have a "frozen Sprint Backlog", in average 25 % of our scopes used to changes during sprint.
            Weekly, we readjust accordingly workload vs Actual Capacity.
            But as the end, current Burn Down charts may be "harmful" because they look too.... good!

            Main reason is because they don't reflect cost of changes and cutted scopes/targets.
            More details here
            http://www.soliantconsulting.com/blog/2009/07/burndowns-considered-harmful/

            As current workaround to reflect changes: we check side by side with "alternate" Burn down Charts that visualize the removed or added stories
            (we use 2nd field "Fix version" call "Initial Affectation")

            Thanks!
            J.

            Jacques Chatenet added a comment - 1 more vote. In our case, CFD is more useful than Burn Down Chart because whatever the best intents have a "frozen Sprint Backlog", in average 25 % of our scopes used to changes during sprint. Weekly, we readjust accordingly workload vs Actual Capacity. But as the end, current Burn Down charts may be "harmful" because they look too.... good! Main reason is because they don't reflect cost of changes and cutted scopes/targets. More details here http://www.soliantconsulting.com/blog/2009/07/burndowns-considered-harmful/ As current workaround to reflect changes: we check side by side with "alternate" Burn down Charts that visualize the removed or added stories (we use 2nd field "Fix version" call "Initial Affectation") Thanks! J.

            hugo lassiege added a comment -

            Hi,

            I would like to add my 50 cents to this issue.
            This kind of diagram would be very useful, especially in a "kanban" context. In Kanban you work "lean" and it's more a flow than a series of sprint. The flow diagram would be usefull to check waste in the process.

            In this purpose, it could be interresting to have worklog types like in Minyaa (http://www.minyaa.com/time/). Worklog type could give more usefull information about the flow than just the different status of your issue. I'm maybe wrong but I'm not sure you could see waiting time in a diagram that just use the status.

            We could have maybe 2 kind of diagram :

            • one flow diagram that describe the process represented by status
            • one flow diagram that describe the process by worklog types (developpement time, waiting time, testing time, etc...)

            hugo lassiege added a comment - Hi, I would like to add my 50 cents to this issue. This kind of diagram would be very useful, especially in a "kanban" context. In Kanban you work "lean" and it's more a flow than a series of sprint. The flow diagram would be usefull to check waste in the process. In this purpose, it could be interresting to have worklog types like in Minyaa ( http://www.minyaa.com/time/ ). Worklog type could give more usefull information about the flow than just the different status of your issue. I'm maybe wrong but I'm not sure you could see waiting time in a diagram that just use the status. We could have maybe 2 kind of diagram : one flow diagram that describe the process represented by status one flow diagram that describe the process by worklog types (developpement time, waiting time, testing time, etc...)

              Unassigned Unassigned
              nmuldoon Nicholas Muldoon [Atlassian]
              Votes:
              4 Vote for this issue
              Watchers:
              3 Start watching this issue

                Created:
                Updated:
                Resolved: