Seeking Advice: Project/Team/Workflow models

Josh McManus

Hi Atlassian Admin family!

My organization has been using Jira since 2010 and while there has been some general governance in the past, it hasn't been comprehensive or rigidly applied. I convinced my company that putting someone into the "Product Owner" role for our internal tools so that we treat our users like customers and work to ensure our tools are meeting the needs of our teams...and that person is me! Now comes the hard part...moving their cheese.

Projects

Currently there's not great consistency in how my org decides when a new Jira project is needed. Some parts have one project per team irrespective to the product they're supporting, some parts have one project per product that multiple teams work out of, while some parts spin up a new project for every new scope of work they decide to take on. I know that factors which play into this decision should consider permission schemas/access, Release versions (I'd love for this nomenclature to be cleaned up), Components, and screen/field configurations. Based on these factors, it *seems* to me that building the projects around the products they support is the best match...but we are relatively immature in our cloud service products and shared services/components between products seems to mess that model up a bit. What are your experiences with project structure and do you have to fit both desktop applications and cloud service SaaS products in that model? Because I'm working to obtain funding for Salto, a requirement for me is to keep our project count as low as reasonable.

Teams

We used to use Groups to assign work items to teams/boards, however this became burdensome since only Site admins can modify groups and any time there was a restructure and a team needed to be created/removed it forced the Site Admin to engage. To remove this requirement (and to better integrate with Portfolio/Advanced Roadmaps) we decided to move to the new(ish) Team field. While the benefits are definitely valuable in how it ties Teams to home pages and allows teams to manage their own membership, there have been complications as the field still has some support issues. We have worked around some of them (like Two-Dimensional Filter Statistics and Pie Charts not working...we bought the Reports - Charts and Graphs add-on to supplement), however now we have the complication that we are trying to aggregate useful data to this assignment but the fact that *anyone* can create a team makes that data less reliable. What's your experience with building boards that may span projects but centered around some team identifier?

Work Items and Workflows

My organization has purchased licenses to Jellyfish to derive more useful data analytics from our engineering group, and since it uses Jira as a data source for it's metrics it is forcing our hand in aligning the way our engineering group operates. Historically we were primarily a desktop/installed application software company, and that led us to models that were based around builds that generate installation bundles. However as we mature into SaaS products this is forcing us to development patterns that include deploying services to intermediate environments, test environments, and production environments. What does this look like for you in regards to your ticket structure and statuses? Do you leverage subtasks for tracking these deployments or do you have a serial flow of statuses mapped to the activities? Or do you generate Deployment tickets and only track the story or bug fix to the posting of the service to the artifactory? It seems to me that subtasks might be the best fit for tracking these activities since some of them could be operating in parallel (functional testing in a QA environment while load testing is running) and you could block the Deploy to Production subtask with the other activities...however this seems like an administratively heavy load and I can picture teams complaining about the overhead.

Thank you for any advice or feedback you might have!

David Foote_h3fjnl

We also had an environment where we had great inconsistency in the structure of projects, the workflows associated with the projects and the amount of teams working in each project.

With the introduction of a new head of our IT PMO, we finally had the support needed to clean up this side of our house (at least for our IT users; non-IT service teams are a whole other bag!). The PMO's need for clear reporting was a huge deciding factor in getting the organizational will behind standardizing!

This is the approach we took:

Standardized issue types, workflows, and screens across all IT development project

This was crucial in allowing us to provide the metrics the PMO needed along with preserving our sanity as Jira admins; it's no fun rolling out updated field requirements across 20 workflows! We introduced an integrated change process between software and service last year - it literally would not have been possible without this standardization.

We tried as hard as possible to build flexible workflows though; some teams have different QA and UAT requirements for deployment so our flow changes depending on how some fields are set.  If you set 'UAT Required' to 'Yes', you get a set of UAT statuses after development being done for example, where 'No' allows you to go straight to the deployment statuses.

Cons: Our workflow diagram is a huge mess, thanks to the multiple transition paths we need to have available. And standards are really standard - if the PMO says this new date field is needed, everyone will now be filling that out, no one off exceptions to make the Networking team (or whoever) happy.

 

Objective Projects vs Team Projects

Our first approach for project design was to have a generic "Initiatives" project that held parent cards with the children Epics living in separate projects. But after some reporting headaches, the take-two for us on how we define out projects was to split out projects related to big objectives that multiple teams work on and projects that are specific to one team and contain that team's keep-the-lights-on work along with a board that shows cards across all projects for that team. 

Initially, we weren't so strict on the split and we found it very difficult to report on, say, time spent on a particular objective when the child Epics for an objective lived in many different projects. So we created Objective projects that make reporting dead simple; if you want to know what cards were finished in so far this year for an initiative, you just look at project = X and resolution >= startOfYear(). Objective projects also make it easy for a project manager/product owner - they create the cards they need in the project, assign the right team and don't worry about where that team likes to "work".  Boards on Objective projects are also very simple (and close to the Jira default) - just show the cards in this project to get an overview of where everything stands (although we really try to stress that these work best as Kanban; Scrum can muddy the waters a bit).

Team projects are really a combo of two things:

1. A board (Kanban or Scrum) that is built to pull in cards from across the system wherever the team is assigned (we use a field called "Teams" for this)
2. The expectation that only KTLO work is created directly in this project.

The board, in particular, gives a team one location to go to see what work is on their plate; regardless if they are cards coming out of projects, ops-type work they may need to do, or even service tickets that have been escalated to them. Going this route was mostly due to teams being confused that they had work as part of a project but not knowing this because they had never been to that project's board before.

The KTLO expectation fits with our reporting needs - while we need that for estimating workload, it's not something our PMO needs a lot of data on. So having it in the team project gives the Scrum Master a place for it to live (and for their reporting) without muddying objective reporting.

Cons: It can take awhile before people internalize what the two different projects are for; there still needs to be some level of communication when creating cards for teams because new cards that are just dropped on a backlog can be lost; because the queries on the team boards are so broad it pulls in statuses that aren't really relevant - this can cause confusion for scrum masters who are configuring the board's columns. 

Team vs Teams

We were using a field called "Teams" before Atlassian forced introduced the 'Team' field. We explored switching, but the lack of any sort of controls around who can create and update a 'Team' really made it unusable for us. 'Teams' is baked into our required fields for our workflows on both the Software and Service side of Jira for us - but we don't do a lot of actually defining who is a member of which team.

On the service side, we do use special Jira groups that will automatically update the 'Teams' value based on the assignee, but on the software side we don't enforce that the assignee be linked to a team or anything. Weird to be missing that team membership linkage, but it works surprisingly well!

Cons: We will likely switch to 'Team' when it becomes a more mature feature, which will be a lot of work; we sometimes get zombie team values and aren't informed of updates (but generally the PMs/SMs are very aligned and are able to get work to the right teams).


Sorry for the wall of text but hopefully it can provide you with some benefit!