Multi-Product Project ?

Can you provide a bit more detail about the intention and desired outcome?

From what you say, it sounds as though you're trying to organize others, and to do so in terms of the capabilities presented by a particular tool.

If you're wondering how to structure Jira for a multi-product project, there are, in my opinion, a number of options.

For each product, I would build a separate Jira Scrum template on the same account so that you can flip between them and have access to all of your products and metrics in one location.

By the way Jira fits into good Scrum in the same way that McDonald's fits into the concept of a good meal.

Hello,

@nicolas

you say :

"For each product, I would build a separate Jira Scrum template on the same account so that you can flip between them and have access to all of your products and metrics in one location."

I think that's right, for me the idea is to have one project per product (and not to bring all the products together in a single Jira project). So it would be several products, but managed by one team. Sometimes 1 person can be dedicated to a single product (depending on the sprint). That said, I still don't quite see how team members would be allocated to each product. You'd have to do a sort of multi-product sprint planning with the team, then switch from one product to another in Jira... not to mention that it's going to be pretty difficult to allocate the time each person has set aside for each product, while taking story points into account...

To answer @Ian, basically, given the inertia of projects and the resources available, you can't make products sequentially, and it's rare for a sales person to refuse a project. So, for example, we make 5 products, but in 5 times as much time...

Hello, thank you for your reply.

@Nicolas, you said :

For each product, I would build a separate Jira Scrum template on the same account so that you can flip between them and have access to all of your products and metrics in one location.

I think that's right, for me the idea is to have one project per product (and not to bring all the products together in a single Jira project, what they did without asking). So it would be several products, but managed by one team. Sometimes 1 person can be dedicated to a single product (depending on the sprint). That said, I still don't quite see how team members would be allocated to each product. You'd have to do some sort of multi-product sprint planning with the team, then switch from one product to another in Jira... not to mention that it's going to be pretty hard to allocate everyone's time to each product while taking story points into account...

To answer @Ian's question, basically, given the inertia of projects and the resources available, we can't produce products sequentially, and it's rare for a salesperson to refuse a project. So, for example, we make 5 products, but in 5 times as much time...

I don't think Jira is your problem. To me, the problem is that a single team will be working on multiple products at the same time.  That is not something that is described in the Scrum framework.  And Jira is also not described in the Scrum framework.  You have not implemented Scrum properly so you should be able to find many ways to use Jira to fit your real situation.  If I were in your place, I'd just create a big project and put all the tickets into it. You can use labels or tags to differentiate the products.  But this would no different than a customer support team using Jira to manage their support tickets. (Which by the way is what Jira was originally created to do)

But you may want to follow the Scrum framework you have bigger problems than Jira.

it's rare for a salesperson to refuse a project

Why? Are the Developers claiming to have the capacity, and the ability to make the associated Scrum commitments? If not, that's the problem to be solved. Remember that any lean or agile way of working is based on pull rather than push.

I somehow to disagree with a notion that one Scrum team cant work on a multiple products.

I find it hard to concur with the idea that one Scrum team can't work on several products at once.

I could be mistaken, but I can't locate any mention in the Scrum Guide that a team can't work on multiple product backlogs at once. I acknowledge that this method of working is challenging and would demand extra work, but there is no rule forcing a Scrum team to maintain a single product backlog.

 

Additionally, it is a common practice in many organizations for one product owner to manage many product backlogs.

Having stated that, it is appropriate to point out that Having said that, it is right to mention that Scrum is not a technique to use Jira. On the contrary Jira is a tool to help Scrum, and as any tool it is replaceable..

Therefore, rather than focusing on how to use Jira in that situation, the main question is whether team developers are capable of doing Scrum under the circumstance: i.e. working on multiple Products at once, which would require working part-time for each separate Sprint, separate Sprint planning, Daily scrums, Sprint review, and retro for each separate product backlog...

If they can work on many product backlogs at once and produce valuable  increments for each of multiple Sprint Backlogs they are working for, then using Jira is juts a technicality and can be done as I have described.

If they exhaust themselves and cant work that way, then problem is in what they are required to do, not the Jira.

The questions I would ask are around Focus and changing that focus how it impacts ability to deliver value when you are constantly context switching and meet a Sprint Goal if the same people are pulled in many directions with different goals.  

I was going to say the same as @Daniel. 

... create a big project and put all the tickets into it. You can use labels or tags to differentiate the products.

As said the Scum Guide pairs one Scrum team per Product. However in my opinion the thing is to have one sprint backlog per team, which the team creates by pulling from one central backlog, call it a central "Portfolio" backlog for a lack if a better word. The PO or multiple PO's will have to manage the priority on this central backlog. The thinking is the same as with Support items. Once an issue or feature is in the backlog, they are just all items, and the team(s) pull the items into the sprint from the backlog. Then the assumption is your team(s) are cross functional, else that is going to be a bigger problem for team work. 

The team organisation you mentioned, might have better fit or advice from scaled agile or other hybrid models. I will recommend investigating those also. 

Ok, so in theory there is no objection for a Scrum team to work on multiple products (i.e multiple Sprint projects) at the same time. But constant shift in different directions is exhausting and would likely badly damage the Focus.

May be easiest solution would be to talk to PO and ask WHY cant this products be merged in one product backlog as a part of single product vision?

Are the products competing with one another?

Is the organisation pushing a deadline demanding release of all products within short period of time?

Any other reason?

I worked at a company that was failing.  The staff was leaving as fast as they could get a job or as they were included in a layoff.  My situation resulted in me being around for a lot of that chaos. However, I learned some good things from it because that is what empiricism is all about. 

I had 2 teams I worked with as an Engineering Manager by title but was I was the one responsible for the Scrum Master responsibilities as well as other business stuff. We used Jira. Each of the teams worked on a different product in the beginning.  As the organization changed, those two teams dwindled to just a few people.  We ended up with 1 Product Manager, 5 Developers and myself that needed to cover the work for both products.  So we decided to merge the two products into a single one.  The product definition and scope was redefined by the Product Manager. We pulled all of the items from the two product backlogs that were still applicable into a single product backlog and continued to build that one up based upon new discoveries.  However, externally and within other departments in the organization, there continued to be 2 products. So, we would label each Product Backlog Item to determine which external product would be impacted by the changes.  We ordered the backlog with no regard to those labels and crafted Sprint Goals that would allow items to be pulled into a Sprint regardless of the product that was the subject of the value that they were delivering.  This meant that sometimes we would release value to both of the external products and other times to only one.  But to us, we were only working on a single product. 

The lesson I learned from this is that a "product" does not have to be identified by the users or even the profit that is derived from it.  A "product" can be anything that a group of people can understand, visualize, organize themselves around, and provides value to one or more stakeholders.  I also learned that the products defined today are subject to empirical discovery and can adapt over time. 

Hello

Thank you all for your answers which helped me in my reflexion.

To recap:

- We have X products that may look the same but each has its own particularities. The objectives of the product are quite similar but often there are technical or even architectural variants.

- Each product is intended for a different customer or stackholder..

- the projects don't necessarily start at the same time, depending on the customer's signature.

- team members are not working full-time on a product for various reasons.

Scrum authorizes or provides for :

1 PO can work on several products

1 SM can work on several products

Several teams can work on one product (same product backlog, several sprint backlogs): defined in Scrum at scale)

but this is new :

I need :

1 team to work on several products (so po, sm and dev)

Scrum doesn't say anything about this, but it doesn't forbid it, as mentioned above.

note: We may be able to add this case in the scrum guide with copyright of forum participants ;)

Solution 1:

Same product backlog for all products in Jira :

This was done without my agreement, it's a disaster because :

1. Jira is not designed for multi-products.

2. For example, you could use the "component" field to indicate the products, then filter by product to display the boards, separated by swimlane.

3. but the SM has to calculate everything by hand, as we'll only have automatic velocity for all products....

4. Sprints must be synchronized.

5. How will sprint reviews be carried out when we only have a single product backlog? extractions will quickly become laborious for each customer.

I'll skip the fact that they wanted to do without SM....the products are hardly moving forward at all...

Solution 2 that I recommend :



Work in mono-product mode.

1 backlog per product

1 sprint per product

and all the events for each product... in short, classic.

the only thing that changes and becomes more complicated is the way in which the team will divide its work between the different products, necessarily on a part-time basis.

We're obliged to take velocity into account by :

Velocity for one product or all products combined?

competence: not all members have the same skills

and which US product to make....

The risk is that, depending on product priorities, we'll get to the 2nd product out of 5, for example, and capacity will already have been reached. 

arbitration will therefore have to be based on sprint objectives and product priorities. 

It's not easy, and it's not very light for agile but I don't see any other solution.

We're obliged to take velocity into account by :

This is a root of 90% of problems Scrum teams are facing across the world.

This and Jira... 

The silver lining may start to emerge from the clouds once you abandon the notion of evaluating team success, product value, and overall performance results by velocity.

Thank you for your answers. I think the debate can be closed.

In the end, I don't think management's desire to create multi-product teams is a good solution.

You lose focus, but above all it's stressful going from one product to another.

Team members would do better to be more versatile instead of being specialised and focused only on one technique. But will the developers want to make this effort?

note : I'm not sure that versatile is the right word. I mean multi-functional without having to be a specialist in everything.

Create separate projects for each product: In Jira, set up individual projects for each product your team will be working on. This allows you to maintain separate boards, backlogs, and configurations for each product.

Hello Milse,

Yes, you're absolutely right. The solution of putting everything in Jira is no good at all.

Clearly define your project requirements, including the scope, technology stack, timeline, and budget. Understand the skill sets and expertise needed for your specific project.