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

[gordon.varney]

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

[Walter Buggenhout]

Hi @gordon.varney

This is not such an odd request. It does require you to work with company managed projects, as you can add different boards there and map workflow statuses to board columns as you like.

Suppose you have a workflow that your issues run through that has these statuses:

Backlog > Ready for Development > In Progress > QA > Ready for Deploy > Done

You could then create a 2 boards from your project.

Map all statuses from Backlog to Ready for Deploy to the columns of your dev team's sprint board. Make sure that Ready for Deploy is the rightmost column of that board. That will ensure that issues that end up there by the end of the sprint will be considered complete when you look at your sprint reports.

In your second board, for deployment, map Ready for Deploy to the first column of your board and Done to the last, leaving all other statuses unmapped. That will ensure you only get the deployment work on that board.

Obviously, if your process has more statuses in between, you can of course map these to board columns as well.

Hope this helps!

[gordon.varney]

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. :-)

[YY Brother]

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

[Salih Tuç]

I am not sure there is a direct way to do that but if we see the big picture, it is a basic task.

You are basically want to see some issues in a board.

When we look into detail, we want to see "Done" issues after completion of sprint. So, I am thinking the following approach:

• Create a custom field just for flagging, doesn't matter its type but let's say a Single Text field called "Done in Sprint Flag"
• Create an automation
  • Trigger is "When: Sprint completed"
  • For each issue
    • If the issue is Done
      • Set the "Done in Sprint Flag" as name of the sprint (it may be useful for future)
• Go to your board (or create one) and make sure to add newly added field to your board filter: ".... 'Done in Sprint Flag' is not EMPTY"

After that, when a sprint (that is in the context of automation) is completed, your board will be updated. And when you manually set the "Done in Sprint Flag" field, it will also appear in the board, so it gives you flexibility.

[gordon.varney]

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.