Best Practice - Two Sprints one project

[Jeffrey Cardona]

We currently have a project that has two boards

• Discovery Board for product ( Containing Epics & Discovery Stories )
• Engineering Board ( Containing Epics, Story, Bugs, Tasks )

We want to run Discover Sprint and Engineering sprint together.

Our Epics will consist of both Stories & Discovery.

Would it be best to run "parallel sprints" feature or would it be best to separate these boards into separate projects.

[Bill Sheboy]

Hi @Jeffrey Cardona 

There may not be a "best" practice for this use case; how your teams work may help you decide what approach to try.  Perhaps consider and discuss these ideas with the teams to help pick an approach, experiment, and inspect/adapt to improve.

• Do people work on both teams, discovery and delivery (engineering)?  If so, do people end up blocking one team or another due to capacity?
• Do the sprints for the teams typically overlap in time for specific epics (like in Marty Cagan's models) or is work discovered, built, released, and assessed for customer value returns within one sprint of time?
• Do people on either team get "distracted" or "highly interested" in the progress of the other team's work?
• How often do you develop discovery ideas and abandon them?
• What do you know about the lead time (concept to cash) for your idea delivery of the value stream?  Would you find it valuable to know that time?

Kind regards,
Bill

[Jeffrey Cardona]

Thank you Bill on your feedback, I appreciate you taking your time out in responding to my question.

[KAGITHALA BABU ANVESH]

Hello @Jeffrey Cardona ,

Great Question.

we have same kind as below.

in my project, there are different modules. For every module we have a separate team.

we created component for each Module/Team.

created multiple scrum boards by writing jQL for each and each and every component.

We use a common board (Main Board) to create Sprints, sprint backlog, starting and closing of sprints done here. This board contains all the issues from all the components. we grab items to sprint from each module, and teams-will work on them.

In the main Board, we get to know Sprint related information, Burn down  and etc.

from each individual other component boards, we are able to track component wise burn down, velocity and etc.

I felt a bit difficulties, with parallel sprints in project based on modules/components. Sometimes user stories misplaced in sprints. If we closing a sprint with unfinished stories with pending sub tasks, we have to move them to backlog or next sprints, during this also we felt this a bit clumsy.

my choice is, if you have dedicated bandwidth please follow the same as our case.  If not go for the 2 different projects. 

thanks.

[Jeffrey Cardona]

Thank you Kagithala on your feedback, I appreciate you taking your time out in responding to my question.