Multiple Projects for one Scrum Team

[Richard Pflaum]

Hi,

I am new to Taiga and I'm trying to find the best way to manage multiple projects which are worked on by the same Scrum team.

I am the product owner for the software at a metrology company where one Scrum team is writing the softwares for all our devices. 

I thought it would probably be best to separate the products in different projects.

Unfortunately I now realized that each project has its own Scrum board and I could not find a way to plan tasks from several projects in one board, which is what I would require.

At least this is the way we have been working before - separate backlogs for the products which are prioritized on their own and then merged into one "Main" Backlog which shows the order in which everything will be worked on.

How would you recommend handling this?

Should I use one epic per product, instead of separating the products into projects and then work on a filtered backlog? 

I realize this is an option, but then I feel like the actual "epic" abstraction layer would be missing, which I need for rough prioritization.

This might actually be a Scrum question rather than a Taiga question, but I'm hoping you can help me out or point me in the right direction. Thank you in advance!

Best regards,

Richard

 

[Pablo Ruiz Múzquiz]

Hi Richard,

Indeed, I'd say this is a Scrum/Agile question rather than a Taiga one, but it doesn't harm to try to analyse it through Taiga lenses. Something you haven't mentioned and I think is key here is whether all those products are being developed by a shared team somehow.

Could you share that structure so I can give you my "professional" opinion?

Pablo

--
Please help us keep the Taiga.io Community open and inclusive, follow our Code of Conduct:
https://github.com/taigaio/code-of-conduct/blob/master/CODE_OF_CONDUCT.md
---
You received this message because you are subscribed to the Google Groups "taigaio" group.
To unsubscribe from this group and stop receiving emails from it, send an email to taigaio+u...@googlegroups.com.
To view this discussion on the web, visit https://groups.google.com/d/msgid/taigaio/70c7dd0c-7fc3-4bf8-b46d-796ba6ed7ea5n%40googlegroups.com.

--

	Pablo Ruiz Múzquiz CEO & Co-founder  (+34) 639635072 (+44) 07719222665  kaleidos.net

Este mensaje y sus archivos adjuntos van dirigidos exclusivamente a su destinatario, y pudiendo contener información confidencial sometida a secreto profesional, o cuya divulgación esté legalmente prohibida. Cualquier opinión en él contenida es exclusiva de su autor y no representa necesariamente la opinión de la empresa. Si ha recibido este mensaje por error, le rogamos nos lo comunique de forma inmediata por esta misma vía y proceda a su eliminación, así como a la de cualquier documento adjunto al mismo. El correo electrónico vía Internet no es seguro y no se puede garantizar que no haya errores ya que puede ser interceptado, modificado, perdido o destruido, o contener virus. Cualquier persona que se ponga en contacto con nosotros por correo electrónico se considerará que asume estos riesgos. KALEIDOS OPEN SOURCE se reserva las acciones legales que le correspondan contra todo tercero que acceda de forma ilegítima al contenido de cualquier mensaje externo procedente del mismo. INFORMACIÓN PROTECCIÓN DE DATOS. Responsable: KALEIDOS OPEN SOURCE (B86241973) Le informamos que sus datos identificativos y los contenidos en los correos electrónicos y ficheros adjuntos pueden ser incorporados a nuestras bases de datos con la finalidad de mantener relaciones profesionales y/o comerciales y, que serán conservados mientras se mantenga la relación. Si lo desea, puede ejercer su derecho a acceder, rectificar y suprimir sus datos y demás reconocidos normativamente dirigiéndose al correo emisor o en los datos del responsable. Para información y consultas visite nuestra web  https://kaleidos.net

[Richard Pflaum]

Hi Pablo,

thanks for the quick reply!

The software division of our company is organized as one Scrum team and providing the softwares for each of our devices.

Thus,  the software is not the entire product, but rather a part of other products (we sell sensors).

In that constellation, the software team is "shared" by the different applications and the work time has to be split up between the different products.

It's even more complicated because some functionalities or features developed are catering more than one product, since the specific softwares are built using the same frameworks/libraries.

As the product owner I'm the link between the software scrum team and the stakeholders from our applicative divisions.

Does that answer your question?

Richard

[Pablo Ruiz Múzquiz]

Hi Richard

It certainly does! This scheme of yours is not that uncommon and it poses its own challenges. One team shared across multiple products/projects, each of them enjoying agency and some business goals.

There are two ways I would approach this:

1) One Taiga project using Scrum module and ONE backlog with multiple open sprints, each one per product. You can have a simple syntax for the sprint naming convention and use tags and Epics to filter the backlog. Epics could be the product itself and have all child user stories linked to that Epic. Tags are a more flexible framework. This way you can manage everything on ONE super-project and ONE super-team. You can use Taiga's roles for this and think of naming conventions, too.

2) One Taiga project using KANBAN module and multiple swimlanes, where every swimlane is linked to an active product development. No sprints per se, but you can setup frequent checkpoints anyway. You can filter and collapse swimlanes so you can easily focus but still you can enjoy the different zoom levels and have the "heatmap" view of all different products and see whether there is a potential bottleneck. You could have product backlog as your first KANBAN column o have a generic swimlane where you do the general backlog grooming first and then move cards to the other swimlanes/products. Epics could still be used to track overall product progress.

The other approached involve multiple projects and one project using multiproject support for Epics but I think there's value for the team to be aware of the whole picture. Was I able to express this in a understable fashion?

Pablo

To view this discussion on the web, visit https://groups.google.com/d/msgid/taigaio/2fd03d0b-779c-4f68-9de9-6d7f10660156n%40googlegroups.com.

[Richard Pflaum]

Hi Pablo,

thank you for the advice, I really appreciate it!

I think version 1 is closer to what we are currently doing, I will try this one first.

Now I'm wondering, why isn't it possible to filter by epics in the board view in the scrum module?

Wouldn't this eliminate the need to use separate sprints/boards for the individual products?

The main problem with different projects and separate boards is that the velocity is not transparent and the work done in one sprint (meaning the same time interval) is not visible at one glance

I think using multiple sprints within one Taiga project could cause the same issues. 

To me it seems important to have the big-picture plan of each product separately as some kind of roadmap, which could be epics if every product had its own Taiga project.

The tasks of the next few user stories to be implemented should then be tracked on one shared board linked to the team, not the project.

Not sure if this is just my individual view or if this could benefit other teams too.

It would be really nice to have a Super-board containing all issues in currently active sprints from all projects.

Provided it was possible to filter such a super board sufficiently to gain oversight, this could provide great flexibility using multiple projects.

Is this something I could add as an issue to the open taiga board?

Richard

[Pablo Ruiz Múzquiz]

Hi Richard

Since we're in the middle of defining the next major release, sure! please create an issue here https://tree.taiga.io/project/taiga/issues?order_by=-modified_date or https://github.com/taigaio/taiga-front/ (if github is not down).

By-Epic filter is something really interesting for the backlog and... it's there already. Or are you referring to the sprint taskboard (useful perhaps but I don't see the need to filter out a very limuted number of user stories)?

The multi-project view is something we actually drafted two years ago and found that different teams and organisations needed different top level views. Would you be open to be contacted by the Taiga design team in the future to understand your use case?

Pablo

To view this discussion on the web, visit https://groups.google.com/d/msgid/taigaio/431f297b-0205-4c9e-a0e9-d905e55b3dc4n%40googlegroups.com.

[Richard Pflaum]

Hi Pablo,

yes I'm referring to the sprint taskboard. Provided our different products would be tracked in epics, filtering by epic would be a very quick way to only show the stories interesting to those involved in the product.

This might not be necessary once there is a multi-project view.

Sure, feel free to contact me

Richard

[Pablo Ruiz Múzquiz]

Hi Richard

Thanks for clarifying. I think KANBAN and swimlanes might be worth a try in your case.

One sprint taskboard with multiple products could become a mess, to be honest. Or, to be more specific, it would be challenging for Scrum to cope with such a distortion of a key artefact of the scrum technique, like Sprints are.

I'll add your contact for future conversations around multi-project product design, thanks!

Pablo

To view this discussion on the web, visit https://groups.google.com/d/msgid/taigaio/9a871776-bce7-477a-8dc1-f9f6da26ecddn%40googlegroups.com.