nav[aria-label="Primary Navigation"] { padding: 0; & ul { list-style: none; width: 100%; display: flex; flex-direction: row; justify-content: start; align-items: start; gap: 30px; padding: 0; & li { margin: 0; } & ul li { list-style: none; } } }

Organization help

Morten H

Hi!

We're a small company, 15 employees, 6 of whom are software developers.

We have multiple projects running simultaneously, many of which are technically done but still need maintenance since we offer them as SaaS.

Our dev team has been frustrated because they don't know what they'll be working on or where to find their tasks.
So, after some months, our head developer decided to consolidate all the development issues from our different projects into one project.
Now, each product has its own epic with all the related development issues under it.
This setup is easier for the developers, but the product owners are losing track and can't use features like the timeline within their own projects to stay updated.

Do you have any recommendations on how we can better organize this?

I've been considering the advanced planning feature, and it seems promising.

Also, we don't do sprints, but I'm wondering if adopting them would benefit us.
Would that mean we'd need to reorganize our existing maintenance projects, which are mostly created using the Kanban and business templates?

I'm also curious about how to transition from a Scrum project to "business as usual" when we move into maintenance mode for the app instead of developing new features.

Accepted answers

Lisa Forstberg_o85gu4

Hi @Morten H ,

It seems like your initial setup was one product = one project. This was good for product owners but the developer were frustrated as they had a hard time finding their work.

That setup would be fine if you had built a kanbanboard visualising the work from the different project, ie created a consolidated view for the developers. Having the developers jump from project to project is not a good setup.

With the current design the product owners have less features than before so I understand their frustration.

Also having everything around one product = one Epic is not a sustainable design. An Epic should also have a lifecycle, representing a larger delivery with a start and an end. A product should have more than one Epic.

I would suggest the following options:

Go back to Product = Project and build a cross product kanbanboard for the developers. Simplify this through having shared standard workflows across the projects.
Stay as you are but introduce a custom field for Product to help the product owners filter the scope on their product.
Move to Jira Premium that includes Plans. Here you can add more issuetypes on top of Epic OR group the timeline view on another field - like component or a custom field for "Product".
You can always test product discovery also, but you are a small shop so it should be enough with Jira.

Secondly testing Scrum as a methodology does not require you to do larger changes to your setup. A Scrumboard, like a kanbanboard, is just a way to visualise your tickets. Maybe if you have a status called backlog in your current workflow, you might want to remove that to not cause confusion

Also considering separating development from operations. This can be kanban flow for operations and scrumboard for development. If you want to involve customers in your operations use the Jira Service management project type for offering a portal for your customers to raise incidents or request services from your team.

best of luck

All comments

Lisa Forstberg_o85gu4

Hi @Morten H ,

It seems like your initial setup was one product = one project. This was good for product owners but the developer were frustrated as they had a hard time finding their work.

With the current design the product owners have less features than before so I understand their frustration.

I would suggest the following options:

Go back to Product = Project and build a cross product kanbanboard for the developers. Simplify this through having shared standard workflows across the projects.
Stay as you are but introduce a custom field for Product to help the product owners filter the scope on their product.
Move to Jira Premium that includes Plans. Here you can add more issuetypes on top of Epic OR group the timeline view on another field - like component or a custom field for "Product".
You can always test product discovery also, but you are a small shop so it should be enough with Jira.

best of luck

Morten H

Thank you for your detailed response and good suggestions. I appreciate it!

We already tried creating a consolidated board for the developers, but it wasn't very successful, hence our new method of containing all issues in one project, which seems to be far from optimal too.

We will definitely look into the "Plans" solution, and separating development and operations makes sense.
Would you suggest creating two different projects for this to work effectively?

Thanks again for your insights!

Lisa Forstberg_o85gu4

Hi,

well you need some sort of separation / classification between dev and ops, as they are different kinds of animals. Operations by definition is unplanned work with the focus of upholding a stable and running production environment. Here urgency & criticality of an incident will have an effect on priority. Dev should be plannable and less critical. The priority here is by estimated business value or fit to strategy etc If all resources work on all issues of course the total amount of work needs to be prioritised in ”one list”.

Normally I would recommend using a jira sm project for operations and a jira project for dev, but as you are a small shop it might be enough with having different issuetypes in the same project. It sort of depends on how you wish to work now and in the nearest future both internally and if you will use jira for the intake and dialogue with your customers.

even though issues are stored in the same project you can create different boards for different purposes. An operations board as a kanban vs a scrumboard for dev f ex.

Your one project-setup will be hard to scale when your business is growing but it might be just enough for now.

/Lisa

Welcome!

It looks like you're new here. Sign in or register to get started.

Quick Links

Find more posts tagged with

jira

cloud

jira-service-management-cloud

jira-service-management