Post processing of a Done issue at the end of a Sprint?

Question

There is some interest in visualizing and handling Done issues, when a Sprint ends, in what I'll call a post-sprint/pre-deploy board. So, issue is completed and "Done" in a Sprint and we want to have it appear on a different board - a board where we manage issues destined for a deploy (that may need some additional housekeeping work).

Yes, may sound odd. Has anyone done this with success?

Maybe phrased a different way, how can I manage Sprint-done issues on a board specifically made to hold issues destined for next release - and may or may not have post-sprint but pre-deploy subtasks.

Many thanks.

JGV

gordon.varney · Answer

So, with this solution, "Done" means end of Sprint Done, which is fine. Using the extra field (flag) I can have that "Done" item show up on my Deploy board automatically, triggered on End of Sprint.

To test, rather than create a field (or repurpose an unused field), we could add an Add_to_Deploy label and look for that.

Hmmmm

This is the workflow I'm playing with.

* Draft through Sizing are used on the Product Owner's Kanban board and work well.

* Backlog to Done are used on the Team Scrum board and work well.

* Ready for Deployment through Product Done would be "post-Done" work on the Deploy Kanban board.

gordon.varney · Answer

Would though, going to Ready for Deploy, trigger all the normal when Done things - reporting and such? I want/need to keep all the built-in things that happen when something reaches Done. We're one of several teams with plenty of automated reporting - me suddenly using a diff def'n of Done would be very short lived. :-)

Yong Yang · Answer

Hi @gordon.varney

I  agree with @Walter Buggenhout solution.

As supplementary, according to my previous experiences, this question is related to both sprint management and release management.

1.Sprint Management

Both Ready for Deploy and Done statuses can be in the last columns in the Active sprint board because there may be some issues that don't need to be deployed and done directly.

2.Release Management

I suggest you use the Release feature directly, where you will see which issues are to be deployed accroding to their statuses. It meas maybe we don't need any board created.

Hope it helps,

Thanks,

YY Bro