Setting up Projects - Teams vs. Products

[Jamie Stanczyk]

Good morning!

I wanted to get feedback on setting up projects within Jira. Currently, our Jira instance is setup to where each product within our company has its own project. This is helpful for us as we have multiple teams that work on one product, so we are staying product management focused. 

And this is where the discussion and advice is needed. We also have teams that work on multiple products, so tracking individual team velocity, burndowns can be difficult. Along with having products as projects, I also have project for each team, with a cross-project filter that shows all of the work that they are doing for their given sprint. However, viewing the project burndowns are difficult as those reports are based on sprints, not on teams. I have found multiple other posts with this dilemma, and it seems like an additional plug-in app maybe necessary.

These reports are needed as we have some teams that work on multiple products, and still need to see what the sprint burndown and velocity look like overall.

So this question, is two-fold:

• Is it best to keep our setup of product for each project, with our unique structure?
• How is best to get team velocity/burndowns with this product management focus Jira setup?

[Holly Scott]

We were set up like you, then suddenly changed to projects being by teams only. We're trying to justify switching back and I'd love to see the responses you get here.

[Jamie Stanczyk]

Would you be able to explain to why you switch from products to teams and what issues if any that you have been running into? For example, how difficult is to track product roadmaps now?

[Holly Scott]

I think the change is detrimental. The cross-functional discussions now have to be extra meetings, you only see, for example, software's work across all projects when software often depends on system's completion of work items. Even our actual scrum teams have been restructured to this. Our Daily Scrum is now a bunch of software people discussing work that affects no one else on the team. It's actually somewhat upsetting.

[Walter Buggenhout]

Thanks for sharing this topic over here, @Jamie Stanczyk! It is one I know many organisations struggle with - Jira being a swiss army knife, deciding how to structure your projects is one of the hardest and most impactful things to do to support your organisation in the best possible way.

I am all with you on the idea of setting up projects for your different products. That makes it clear what work is all about. You can use versions/releases (which are project specific in Jira) to track your product releases. And you have a single source of truth for your product history (spanning multiple versions, ...).

To bring work to the executing teams, use a team board and filters to pull the work from the different (product) projects together for each team. You can use various mechanisms to assign work to teams, that you can leverage into your board filter. It is the board that hosts the sprint or kanban features that help teams plan and track their work. Velocity and sprint burndown are reports that help track, inform and improve the teams - in the end the people that are doing the work. So knowing e.g. the velocity (scrum) or the lead/cycle times (kanban) of each team can help you project how long it will take each team to deliver value.

Out of the box - in the premium plan - advanced roadmaps plans can help you consolidate the schedule across multiple teams.

But of course, there are plenty of organisational and other challenges to overcome. Curious to hear how other agilists manage this in their environment! 

[Holly Scott]

This is what I've been saying! Thank goodness I see someone else saying it!

[Tarang]

I think the word "project" is overused and it doesn't help that Jira has Project when really it would have been better called Workspace. So within a workspace one can have multiple products, if one wants, and most likely that they are related possibly as the same group of teams are to work on them.

This said, I am with you in having each unrelated product having its own workspace. Of course there will likely be teams, often infrastructure or services team, having to address multiple products and their workspace will be a mix of demands.

In terms of viewing progress using burndown or burn up charts, so if you have scrum teams or teams taking an iterative approach then the Sprint burndown will let teams view their progress for the sprint using the burn down chart. If any team wants to view progress for a larger body of work tied to a release then they are better off using Version field to assign their product or team backlog to a defined version. This will enable one to see progress for the version using version burnup gadget.

As far as Team velocity goes, this is misunderstood and miscommunicated when really its a measure for the team for its true capacity to fulfill what they commit to in a sprint. Its a KPI for the team and should be used wisely by the team and not be viewed as "team performance" as this will lead to gaming the system - aka Goodhart's law!

[Walter Buggenhout]

It is, @Tarang > I try to look at it as a measure for building trust and predictability, rather than a performance metric.

[Walter Buggenhout]

And although it will bring about some significant change (once more) for long lasting users of Jira - the terminology is going to change later this year, when projects will be renamed to spaces.

[Tarang]

Yes, alas its how others outside the team, often people in the hierarchy of management, and less well informed of Agile practices who often unknowingly abuse this measure and start corrupting its value to the team. which leads to it becoming a vanity metric.

[Walter Buggenhout]

Can you make sense of the comments here @Jamie Stanczyk? Are they providing clarity about your further direction?