Scrum issue done but not released tracking

JOSE SANTIAGO BONILLA PAZMINO

Hi everyone, 

According to Scrum, the team should deliver done items (issues in Jira) potentially releasable, every sprint.

So, we have a next-gen board similar to this:

To Do - Coding - Functional Testing - Tech Testing - PO check - Done

After that, issues disappear from backlog, but we need to track issues until released to production, after closed (done).

We were thinking about adding more steps in our board like this:

To Do - Coding - Functional Testing - Tech Testing - PO check - Ready to release - Promoted - Done

But we would close no issue every sprint until promoted to production. Also, this is not potentially releasable.

I was thinking about using Releases feature of next-gen, but I am not sure if this is going to solve this problem of tracking unreleased closed issues to production.

Thanks for your guide.

Bill Sheboy

Hi @JOSE SANTIAGO BONILLA PAZMINO 

I wonder if you are mixing issues about the Scrum framework and what the JIRA tool is capable of supporting...

When Scrum notes a potentially shippable product increment, it means a chunk of value that could go to production.  Ideally, that chunk would go to production during the sprint, helping the team learn from feature experiments faster, and so influence future value decisions.

Many teams have the situation you describe, where building and releasing are separate parts of delivery workflow.  In that case, a work item has finished building, is added to the release candidate, and eventually a set of work items is released to production.

For classic JIRA projects, this can be supported by cloning a "built" work item, and then using a separate release management board on the same project.  I believe that is not possible for Next-Gen as you can only have one board per project.

For Next-Gen, your options appear to be:

1. Clone done items from your build project into a separate project for releasing
2. Create a separate release project, summarizing the items rather than cloning them
3. Create smaller work items and release all the way to production during your existing sprint
4. Switch from Scrum to Kanban, and show your full workflow all the way to release on one board
5. Convert from Next-Gen and use a Classic project, with two boards: build and release

 

Best regards,

Bill