Is there a way to base Sprint Reports off a column that is not the right-most column?

[Jasmin Rizko]

Our team tracks two milestones per ticket: 1) when development is done, and 2) when testing is done. We'd like our Sprint Reports to be based on the second to last column from the right so that we can carry untested tickets over to the next sprint while still tracking completed development work in the Sprint Report. Does anyone know of a way to do this?

[Walter Buggenhout · Accepted solution]

Hi @Jasmin Rizko,

The scrum board (and associated sprint report) are built on the assumption that completed issues in a sprint are the ones in the right-most column of the board, as you rightfully acknowledge. That is the way it is and there is no setting available to change that behaviour.

If you treat development and testing work as different activities, run by different teams (which seems to be the case, from what you describe), you could consider splitting the process across 2 different boards. On the development board, you could make the development done column the rightmost column. On the test board, you could set that same column as the first column of the board and testing done as the rightmost column there.

Underneath that technical part of the setup, do ask yourself the question if it is the right thing to do to consider untested work as "completed". Both development and testers are responsible to deliver working software together, so splitting the process to make e.g. the progress of just the development team look better (as they deliver more story points) may be a pitfall you want to avoid for the entire process. 

[Jasmin Rizko]

Hi @Walter Buggenhout! Thanks for your input. I get what you're saying in the last paragraph - the issue is that developers are responsible for unit testing, while our validation engineer is responsible for, well, validation and integration - that's the testing step I was referring to, and why I'm wanting to set up the board the way I described above.

[Walter Buggenhout]

I totally understand that, @Jasmin Rizko. When you might consider splitting the process across 2 different boards, you may want to think about using a kanban board for the validation engineer rather than a scrum board. The way work reaches him/her will be more on a continuous basis (when development is done) rather than through scheduled iterations.

[Jasmin Rizko]

That's a great point! Thanks :)