Skip to main content

Different projects one sprint

Last post 02:56 pm July 20, 2023 by Christophe Meyer
7 replies
02:22 am July 3, 2023

We have several products we are developing and trying to push to market, have do i structure my sprint board on jira

should i have one board per sprint which includes all tasks from all projects or different boards per project for one sprint

If not what is the best way to do this

08:45 pm July 3, 2023

A board should give the Developers transparency over their progress to achieving a Done Increment. That's the commitment they're making. Let them experiment and figure out how to best structure their workflow, define its policies, and to understand their commitment point.

Whatever they choose, they'll run into problems if they're trying to push work through. Scrum, in common with any lean or agile way-of-working, is based on pull.

12:15 pm July 4, 2023

It is a good idea to have one Jira board for each product since you should have one backlog for each PRODUCT.

In Scrum, "project" is not precisely defined. Although they may be considered separate projects, multiple teams working on the same product should share the same backlog.

Then, you should figure out a means to divide or share the same backlog list of "issues" (as Jira refers to them) graphically. You can do this by making it accessible to several teams or by somehow dividing different teams using a at one template

07:44 am July 7, 2023

Always a Jira project for a scrum product.

and one board per product

and one sprint per product.

and one pb per product

If for some obscure reason you need a board for several projects/products you can do this. (technically speaking)

03:28 am July 12, 2023

As @Ian said a Scrum is a pull system. The team needs to be able to pull from a prioritised backlog. The team can then decide how best to display the sprint items. 

Starting with the backlog, I have somewhat of a different view. Scrum works on a prioritised backlog, and if there are multiple backlogs, then I think the priority will be muddled. 

The Scrum Guide talks about a product per backlog, but we are trying to make things work in a multi product environment. I lean towards defining a product/portfolio consisting of multiple "sub-products", then group all items on one backlog. From a backlog perspective a backlog item is just an item. The important thing is to have a single prioritised backlog to pull from. Use a label or something on Jira to differentiate between products. 



01:59 pm July 13, 2023

You can't change the definition of product that easily.

with 1 product you have One backlog product and all events for this product and one stakeholder for this product. You have 1 sprint backlog per team.

Your sub-product is like a product ? what is the differerence ? is it just because they look alike?

Similar doesn't mean the same.

if you need to use a label to separate your tickets in sub-product, you're cheating because you're dealing with several products.

In short, by thinking you're simplifying by distorting the definition of a product, you're adding complexity to your management...are you going to do sprint reviews for each sub-product? if not, what are you going to lose, what do you really think you're going to gain? are you going to do retrospective for each sub-product? if not, do you think it's useless? do you really think that each "product" renamed into sub-products will all have the same problems? isn't that a little too optimistic? Are you looking for automation in an exaggerated way, forgetting the relationship with the customer/team? How big will your backlog if you mix several products, even if they're called sub-products, in the same backlog? 



05:05 pm July 14, 2023

Is it that it is the same pool of developers who are responsible for multiple products?

02:56 pm July 20, 2023

I'm sorry, but I'm confirming my opinion and my experience. Even if it's the same group of devs, it's a fake good idea. putting everything in the same project means trying to reduce the number of events, thinking that it will increase productivity, but it will compromise quality and increase delays. Jira isn't designed for multi-product Scrum in a single project, unless there are major complications. In theory, you can always do everything...

Otherwise, you can use empiricism to test things out for yourself... experience will help you understand...

By posting on our forums you are agreeing to our Terms of Use.

Please note that the first and last name from your member profile will be displayed next to any topic or comment you post on the forums. For privacy concerns, we cannot allow you to post email addresses. All user-submitted content on our Forums may be subject to deletion if it is found to be in violation of our Terms of Use. does not endorse user-submitted content or the content of links to any third-party websites.

Terms of Use may, at its discretion, remove any post that it deems unsuitable for these forums. Unsuitable post content includes, but is not limited to, Professional-level assessment questions and answers, profanity, insults, racism or sexually explicit content. Using our forum as a platform for the marketing and solicitation of products or services is also prohibited. Forum members who post content deemed unsuitable by may have their access revoked at any time, without warning. may, but is not obliged to, monitor submissions.