Cumulative Flow per sprint

[Daniel Tscherwinka]

I just want to list the number of ticket of one particular sprint over sprint time grouped and stacked by ticket states. I.e. a cumulative flow diagram that shows tickets from a selected sprint only.

unfortunately i can neither refine the cumulative flow diagram from the project's reports section (it shows _all_ open- and done tickets regardless which time frame i select) nor i can find a cumulative chart gadget that i can use in a custom board.

How can i get that simple cumulative-flow-per-sprint view?

[Petter Gonçalves]

Hello David,

I think that the way you are configuring your scenario on JIRA is one of the most common and efficient ways to organize your user stories and procedures. 

The status you mentioned for the documentation and rollout of the Stories can be configured in the same workflow, however, configuring two different views (Boards) to display only the relevant statuses for the documentation team and the development team.

I just have one question about this sentence:

Then use the following dashboards:

1. Documentation Dashboard: Takes the user stories from TO-DO until READY

2. Implementation Dashboard: Takes the user stories from DEV to ROLLOUT.

When you say dashboards, are you meaning the dashboards of JIRA itself where you can configure gadgets or you are meaning the kanban/scrum boards related to software projects?

Per your description, I believe that you are talking about a Kanban or Scrum board. If that's the case, you are indeed using a good practice to split both processes of the issue into two boards: one for the documentation and other for the rollout.

The idea of sub-task to make the tests required is also a good practice, however, sub-tasks cannot be estimated on JIRA reports, so if you are planning to use time tracking I would recommend you to use the relation Epic-Stories instead of Stories-Subtasks.

that being said, I believe you are in the correct path to organize your development plan, David.

Please, let me know if you have any specific questions about the scenario you are configuring.

[David Leal]

Thanks, Peterson for your rapid answer. Yes, sorry I meant "Board" instead of "Dashboard" as you correctly interpreted. Thanks for the tip for the testing process. Then for this purpose, we would need to create specific User Stories for testing (for time tracking purpose)? That would duplicate the effort creating a bunch of User Stories of type: Test Case.

The sub-tasks approach can keep the traceability at Story level, and we can identify the number of User Stories tested based on the transition from the state: TEST to DONE for example in the implementation Board. Let's say the Testing team is planning to test for the next Sprint 20 User Stories (there are in state TEST), that represents 50 story points. Then at the end of the Sprint looking at how many User Stories were moved from TEST to DONE provide a kind of the testing team velocity. A User Story can be moved once all the associated tested sub-tasks finished.

Then creating User Stories linked from the Epic (or even linking several US at the same time) for integration testing. For those, such information can be tracked with Jira Reports (i.e. Burn Up/Down Diagram).

Any thoughts (I know both options have pros and cons)? Thanks in advance,