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

[Scott Windus]

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

[Scott Windus]

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]

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

[Bill Sheboy]

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

[Brad Quirk - Quirk Consulting]

Hi Scott,

Is the intention that these tickets will 'flow' from one sprint (e.g. the requirements) to the second sprint (development)? In other words, are you also trying to connect two Jira workflows together? This may prove impossible.

However, if your intention is simply to visualise two sprints running concurrently at the same time you can build a separate Jira Board that is driven by a JQL query like 'project IN (ABC,DEF) and sprint in openSprints()'. With some minor config you could have two horizontal swimlanes setup that shows the progress of tickets for both sprints, but they wouldn't necessarily 'talk' to each other, if that makes sense.

Hope that helps!

Brad 

[Scott Windus]

Hi Brad

Yes, pretty much that.

I had tried what you recommended however splitting the workflow across two boards, doesn't allow adding the issue into a new sprint after it has completed the work required in the first sprint. The same project sprint just gets shared across both boards, including the designated time.

It's quite frustrating because we want to run through the internal requirement elicitation and sign off in sprints, but once we have finished, we want to hand it over to a vendor for them to complete their work, in a new sprints. This can not happen all in a two week block.