Release management and done-done

[Dave Cobb]

Our company is in the process of introducing JIRA, so part of our current process is to track all tasks to 'done' with releasing to live and post-live testing being classed as 'complete' or 'done-done'. Note: we release mid sprint for those items ready - not at the always at the end of sprint.

How does everyone handle release & post-live tasks within JIRA, are they separate user stories or part of the same story?

I'd like to use the release management capability within JIRA for 'done' tasks, but need to understand how this fits with post-live testing and marking a story as complete and therefore affecting sprint velocity/burndown.

[Aron Gombas _Midori_]

Dave, in Jira each status falls in a status category like "To do", "In progress", etc.

I think it is the category decides in a given status is interpreted as "completed" in the Burn Down Chart.

This means that you can e.g. mark your "done-done" as "Completed", but all the prior statuses as "In progress".

[Dave Cobb]

Thanks, Aron.

So would it be best to group user stories against an Epic, and have a separate task/story for post live checks? That way user stories can be tracked to done and put into a release, and the epic marked as 'complete' once the post live checks are done?

[James Chan]

Hi @Aron Gombas _Midori_ , by mapping the "done-done" as "completed" , when the team has multiple items that there developed/tested however cannot be released. This implies those items would not considered as "burned" and they will all stayed in up in the air in the Burn Down chart, hence impacting the velocity prediction ?

Can you shed lights on how you would handle this situation where let's say all items in the current sprint are developed/tested but they need to stay in the pre-production environment until a few sprints later to be released all in one go. In this scenario, the burn-down chart will show nothing is burned....

Cheers
James