How to setup Sprints to allow the BA team to be one sprint ahead?

[Vinay Barigidad]

In our dev setup, we would like to have BA team be ready with the requirements before the sprint starts. To achieve this, the thought process is to have them be ahead of Dev sprint by at least 1 sprint. 

How do I setup the sprints to achieve this ? 

• Do I have a separate project for BA team and have them run their sprint separately and include only those BAs to be part of the Dev sprints for issue resolution ?
• Do I have only one project for the whole of the delivery, but run two separate sprints, under the delivery (Ex: Sprint1 for Dev and Sprint2 for BA, which will consists of those BAs who need to have the requirements ready for Dev's Sprint2)?

Suggestions would be greatly appreciated

[Rebekka Heilmann _viadee_]

Hi @Vinay Barigidad 

it all depends on how your team is organised. I wouldn't recommend running two Sprints in one project.

I like your first idea. Depending on your workflow, you could have a seperate State "refined", that is the BA's Done and the Ready for Development for Dev. Or even have more States if easier. You can then include only Ready for Dev Issues in the Dev Board and vice versa in the BA.

So if you have seperate Workflow steps for each role in the actual work, I would recreate that with the Jira workflow to an extent anyway.

You could also have Requirement - Issue Types for the BAs and create Dev Task Issue Types from them with a Link.

[Vinay Barigidad]

Thanks Rebekka.

I am planning to run a pilot with an approach. I will probably have two separate projects. One for BA. One for Dev. I will link BA user stories with the Dev User Stories to build the dependencies. I will probably have to do some automation to indicate that the BA user stories are done and the Dev user stories can be taken up for the sprint. 

Will see how this experiment goes.

[Bill Sheboy]

Hi @Vinay Barigidad -- Welcome to the Atlassian Community!

Although there are ways to manage staggered iterations like this (e.g., state management, extended workflow across multiple boards, etc.), I advise first discussing with the team why this approach is needed (i.e., what problem is it trying to solve).

This way of working could lead to a deadlock / capacity / delay situation.  For example:

• people perform analysis on stories A, B, C prior to the iteration start
• the iteration starts, with other people selecting A, B, C stories for delivery
• original group of people start on analysis for stories D, E, F...
• a blocking problem with the analysis occurs with stories B and C, pulling in the people performing analysis, and so they stop work on D, E, and F
• blocking problems are resolved, but now there is insufficient time to "ready" work prior to the start of the next iteration
• worse still, the delays introduced by the re-work cause some stories not to finish in the sprint, and so they carry over to a future iteration
• in the meantime, story D is descoped after analysis completed, and so the analysis is wasted, and a new story must be rushed through analysis to meet the capacity of the team for the next iteration
• and so on...

Some of these impacts are why Scrum teams collaborate together to refine the backlog and deliver together, eliminating delays of people's capacity being unfocused on the current sprint's goal and work.  An alternative might be to use one of the Kanban methods, focusing on value delivery flow and managed practices for work intake and status "exit policies".

A discussion with the team may help to decide what to try for improvements.

Kind regards,
Bill

[Vinay Barigidad]

Thanks Bill. This is helpful. You also have highlighted a potential problem with the staggered iteration, which I did not think of. 

I will review this with the team and see what we need to be doing as a group.