Single or multiple sprints

[david_smiles]

We have a single product with a large product backlog.  We release new features roughly every month.  Our sprints are two-weeks long, so a release could be comprised of two sprints (or more if a big release).

We are currently working on a new release, currently sized as 1 sprint.  However, in the background two engineers are working on a side project, on a set of new features. These features will be eventually merged into the main product sometime in the next month or two.

How should this be managed?  In the same sprint as the main development project, or as separate parallel sprint for the same project?

My preference is to keep the work separate, as the main development sprint is business critical, whereas the side project is not and I don't want it to derail the main project (merge conflicts, bugs, etc).

Does anyone have any recommendations?

Kind regards,

David

[Deleted user]

Hi @Dav,

You mention that the two engineers are working on a side project. If this is the case I would suggest creating another Jira Project to completely separate the work, the issues can be linked to integration Stories within the main product's Jira Project for reference. Once the side project is complete, the project can be archived after the integration back into the main product is complete.

I would try to avoid parallel sprints if at all possible, however you know the product, team and project so you will know the best course of action. 

Hope this helps

[Kelly Albrecht _Western Massachusetts_]

I’d consider adding a component to the project that represents their effort and then tag their issues with that. Then add a Kanban board to the project that filters to issues with their component. They can use that board to see their issues through while the main team sprints with the Scrum board. 

[Troy Spetz]

We use JIRA 7.10 server version.

From what you have said, I would use separate sprints which run in parallel.

The reason is that sprints are time-boxed events. Their purpose is to minimise development risk by restricting the amount of time developers work on a feature (i.e. before the next sprint demo/retro/planning session is held).

So, if two different teams are working on two different features at the same time (and you don't want both features in the same sprint), then using two different sprints should work.