Can I add a second consecutive sprint to a Scrum workflow (Two Backlogs)?

Question

Hi

I'm good with Kanban Projects, but this is my First Scrum Workflow.

By default, the Scrum Backlog commences from the first "To-Do" stage in the workflow. My problem is that I need to have two backlogs/sprints run consecutively. The first will be the development work for the requirements. This will be backlog A - with Sprints.

When 'Ready', it will then sit in Backlog B for vendor development and have its own sprints. Can I do this, or is there a better way to acheive this functionality?

Cheers

Bill Sheboy · Answer

Hi @Scott Windus

I believe this method will prevent the first team from seeing any useful measures in JIRA for their work: velocity, sprint report, etc..  Scrum teams often use such measures as indicators of areas where they could improve.

That is the reason I was suggesting there are two work items, one for each team.  Then the work can flow and complete independently.

Best regards,

Bill

Scott Windus · Answer

Thanks for your thoughts.

The Solution I came up with was to have an almost branching workflow with applied post functions to clear the Sprint, Resolution and Status before going to the second stage/sprint. I have a sprint for the same workflow run through two boards. An issue can still run through a sprint and return to the backlog, if it is not completed. Once I close the sprint, I can then move Stage 1 'done' issue to the next backlog so it can be pulled into a stage 2 sprint/s. It took quite a lot of redesign and testing but it seems to do what I need. Maybe others will find this approach works for them.

Bill Sheboy · Answer

Hi @Scott Windus

You are describing splitting the full workflow into the efforts of two teams: discovery/definition and delivery/release.  As you want to implement these as Scrum teams in JIRA, consider that the work is different for the two teams, and so should be split into different work items.  (This approach is often called "scrummer-fall".)

For example, some feature would be discovered/defined, from start to completion.  Then a new request would be delivered/released, from start to completion.  You could associate these items as children of the same epic, or using links.

Note that approach of splitting the overall flow conceals how long work takes, and if there are any cross-team efforts, such as when delivery is complete but needs input from the people doing discovery/definition.  One way to address that would be to use Kanban rather than scrum, and have two teams working on the same board for the full flow of discovery to release.

Best regards,

Bill