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; } } }

What's the best way to use JIRA (and Porfolio) in a single team that does development and DevOps?

jan_scorito

My team and I are using JIRA for over more than 3 years now. Our team consists of 6 developers and we are developing several online games. The current JIRA structure is as follows, we have 2 projects / boards:

Development (SCRUM)
- Which is used for our sprint planning and our normal development cycle.
- All different games have tickets on this board and games are separated by epics.
- This give us the disadvantage that epics cannot be used to separate work in a single game.
- For every sprint we have a fixed number of hours available (depending in holidays etc), which are used to plan the work.
Operations (kanban)
- Which is used to fix (unexpected) bugs directly on our master branch and to investigate user reported errors.
- For every sprint we have a guesstimate of the hours needed for our operational work. This number of hours is substracted of the sprint hours (see above).
The entire team is responsible for both boards

However somewhere over the course of those 3 years everything around us has changed, but we've never changed the way we work in JIRA. And I'm not sure what's the perfect way to implement JIRA (and porfolio for planning) in our situation.

My best bet would be this scenario:

We create projects for every "online game" (and some extra projects for general parts of our platform).
This gives us the opportunity to use epics for what they were designed for (I suppose).
Both board (development and operations) are using all those projects.
Every ticket has a custom field, which can be used to determine if a tickets is "operations" or not. This field can then be used in the boards filters.
We use portfolio for our long term planning.
We use "cross-project releases" to keep the version of all the separate projects in sync.

The above scenario rises some questions:

Would the scenario as described work? And is this best practice?
What's the best way to deal with unexpected work (operations) in a team that does operational and sprint work together? And how should I handle the impact on the current sprint?
As far a I know JIRA Portfolio allows for epics to be given an estimate which can be used in the planning, and the team then can create tickets / stories for this epic with a better estimate, which at some point are going to overrule the estimate of the epic itself?

Thanks in advance for helping us to use JIRA in the best possible way

Comments

Abhishek Aggarwal

True. There are various pre-requisites or assumptions we have to carry before running the portfolio in JIRa. For ex. it expects high level T-shirt sizing or estimates on epics and stories to estimate the sprints and forecast sprint release plans better. Though it gives flexibility to manage shared resources across different scrum teams but it expects all estimates and time(original estimates) is logged for your initial product plan.Portfolio works better when you know things in advance and requirements are frozen!

Francisco Salinas Saez

What we have is:

1) A 'private' sales project (INT) that is used to manage a bunch of the company' sales stuff and connect it to development. We have a CRM for sales specifics but this project will 'connect the dots' for the sales team and offer real-time (through Agile Board) progress on our available time.

2) For every new 'sale' a new Epic is created in the INT project. We create Epics from the internal so that all follow the same workflow, etc.

3) For every new software, a new project is created. All projects share the same configuration.

4) For every new software a new Service desk project is created. All SD share the same configuration.

5) We use porftolio to plan everything.

6) We use Scrum to manage all software development and support. Development Issues come from Portfolio while support tickets come from the Service Desk Portal in which the support rep creates a 'linked issue' as a bug into the respective project. Those tickets show up in portfolio and are treated depending on how critical they are.

7) In Portfolio issues are related to the Epic respectively. Cross-releases are managed w/o problems this way.

8) We dont use estimation by hours but story points instead. With a little bit of statistics you will be able to get a bunch of information out of it. Also portfolio will automatically adjust to what your team can produce. No need to change weekly... just enter holidays and get going.

* We are just 8 employees using Jira, so we manage to keep everything under the 100/month which is our budget for all this. I pretty much use everything: agile, service desk, confluence, portfolio, tempo and more addons.

hope it helps.

Welcome!

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

Quick Links

Find more posts tagged with

jira

advanced-roadmaps