How can I utilize reports like burndown or sprint report with our workflow

[Phil Bergner]

I'm trying to utilize some of the reporting functionality like burndown and sprint report however our workflow doesn't complete stories with a "Done" status at the end of the sprint. Our developers move stories from:
Ready for Development => In Development => Ready for Code Review

I'd like that to be considered complete for the purposes of sprint reporting. Alternative ending statuses may also be "In Code Review" or "Passed Code Review".

Our stories don't reach the status "Done" until they're promoted to a prod environment and reach a "Passed Prod QA" and eventually a "Done" status but that's not completed in a single sprint. It may get merged up and either be part of a monthly or quarterly release.

[Jack Brickey · Accepted solution]

Hi @Phil Bergner ,

To take advantage of those reports you need to rethink your workflow or usage of that as it relates to your scrum board. What many members have done in similar situations is to split their workflow across a scrum and kanban board. So in your example take your final development status and map it to the right most column in your scrum board. Now have a kanban board for your QA team which will start with the last status of your development team and end with the done status. The resolution should only be set once you hit the Done status on the kanban board. 

[Nic Brough -Adaptavist-]

Note that the Scrum board needs to include all the status that could happen after the developers are done with it. 

Otherwise the developers "done" issues will reappear in their backlog when QA get on to them (and it'll make a mess of your burn charts and velocity)

[Phil Bergner]

Right now we have a few scrum boards. The simplified version is:

Dev Board

Ready for Dev (has a few statuses including failed CR and QA) => In Progress => ready for code review

Code Review board

Ready for Code Review => In Progress => Pass/Fail 

QA Board
Ready for QA => In progress => Pass/Failed

Passing/Failing moves them back to the Ready for Dev column on the Dev Board. Will this setup work or is switching QA to a kanban board necessary for this to work? Does it need a separate workflow?

[Nic Brough -Adaptavist-]

You could still use a Scrum board in any of those teams, as long as they're broadly working in a Scrum manner.  It's fine to use Kanban if they work better that way.

Scrum is a planned time-box.  You pick a bucket of stuff to do in a time-box based on "we think we can get these done in this sprint", and ideally get it all done by the end (if you fail, or over-achieve, then you should look to improve your processes, so that you're committing to the right amount of work in each sprint)

Kanban is "drinking from the firehose".  Work comes in, you assess how important it is relative to existing unstarted work and place it in the queue where needed, then the next free person who can do it, picks up the next most important piece of work.

Given the ideal linear path through the workflow:

Ready for Dev => In Progress (dev) => ready for code review => In Progress (code) =>
Ready for QA => In progress (qa) => Done

Note I've removed pass/fail - those are more likely to be transitions back to somewhere at the beginning of the previous board.

Then your boards would have columns something like

QA

• To do: Ready for QA
• In progress: In progress (QA)
• Done: Done

Code review

• To do: Ready for code review
• In progress: In progress (code)
• Done: Ready for QA, In progress (QA), Done

Dev

• To do: Ready for dev
• In progress: In progress (dev)
• Done: Ready for code review, In progress (code), Ready for QA, In progress (QA), Done

The board type is not too important here, it's the point about each team must keep the stuff that they do not care about in the last column on their board.

[Phil Bergner]

Thanks for all the detail. That's essentially the board and column setup I have now.

dev board columns:

In order for "Ready for code review" for example from the dev board to show up as complete on a sprint report do I need to update that status to map to "Done" instead of "In Progress" or am I missing something else?

 

[Nic Brough -Adaptavist-]

No, the sprint reports work off the last column of the board.  That's why I listed all the "after this team has finished" as needing to go into the last column on each board.

[Phil Bergner]

Ah I understand.That would have the unfortunate side effect of a rather long done column for the dev board but good to know that's how it works. Is that my only option at this point?

[Nic Brough -Adaptavist-]

True, but the "done" column is "we don't need to know about this any more", so if the developers are using a Scrum board, it'll only show "done in current sprint", and the column will empty out on sprint closure.  And they won't bother to read it either, it's done as far as their team cares. 

[Phil Bergner]

Then we probably need to adjust how we close out sprints.

Right now we close a sprint on an overview sprint board and roll any non-done stories into the next sprint, this will apply to all the other boards.

For the developers it doesn't matter (right now) since their dev board currently doesn't show any stories that are past the ready for code review stage. However, QA will see all the stories from the current sprint and any previously rolled over stories since they're not yet done QA. Any stories in QA that are not yet passed in a prod. test env. will continue to roll over sprints until they're done.

This is all super-helpful info.