Back in December 2021 Atlassian announced that there would be some changes coming to Epics and in April we learned that Epics would see an update to how Jira manage Epic Name and Epic Summary. What does all this mean, and when can you expect to see the changes in your Jira instance? Let us dive into the information we have and see if we can answer those questions.

Why is Epic changing?

Having the ability to change, or rename rather, Epics have been requested for well over a decade and up until recently it has been ignored. It was only when SAFe started to become popular that Atlassian started to consider this, however:

Quote

We know many teams using Safe Agile Framework (SAFe) struggle because they’re unable to reflect their issue hierarchy in Jira Software Cloud, namely Features as the parent of stories, rather than epics. Non-software teams can also benefit from terminology that better reflects their work, e.g. campaign, candidate, etc.

This is not the only change that SAFe have initiated and for everyone working in an enterprise company where small agile teams may not be the norm, this is a positive thing. I will talk more abut that in the future.

So what is happening to Epics?

The changes are pretty big from a technical point of view, but even from a consumer perspective, there are pretty big changes as well. The reason for this big change is that Atlassian is merging features from Advanced Roadmaps into the core Jira experience. In doing so, they change the old architecture quite a bit and things will certainly move round a bit as a result.

Here is what will change:

• Move issue hierarchy in Advanced Roadmaps to your admin setting
• Rename Epics will reflect everywhere (no more language hacks)
• Change what Epic fields are shown in different areas
• New colors based on team based projects
• Epic link will become Add Parent and move to breadcrumbs

Move issue hierarchy in Advanced Roadmaps to your admin setting

The issue hierarchy that currently reside inside the settings for Advanced Roadmaps will move to the global Jira admin settings. You will find them under Issues by heading to: ⚙️ Settings > Issues > Issue hierarchy. This means that even if you do not have a Premium license, you will still be able to see these settings and when the Epic changes roll out you can edit the name of Epic from this area.

Rename Epics will reflect everywhere (no more language hacks)

This is a big one and the one that has been causing frustrations for many, many years. Once you rename the Epic in the Issue hierarchy, you need to rename the Epic issue type as well, and then all areas where Epic is referenced you will see the new name instead. So if you rename Epic to Feature, you will see Feature everywhere you see Epic today, including the Epic side panel in your backlog!

Change what Epic fields are shown in different areas

This is more of a technical change, but what it means is that what currently is shown in the backlog will see some changes. This could cause some issues that you might need to adjust when the change happen in your Jira instance.

Epic name → Issue summary

Currently, the board and your backlog show Epic Name and after the update it will instead show the Issue Summary. This make more sense, and I suspect that we will see the Epic Name removed in the future as Atlassian adjust Epics to be presented the same way as other issue types. If you have been putting different information in these two fields, then you need to update them to be the same before the changes happen. There are several solutions for this, but I think the solution Bogdan Gorka suggested in the Atlassian community using automation seems like a good way to do it.

Epic status → Issue Status Category

In the current solution you have Epic status, which is only available in the Epic panel, that define what Epics should be shown in the Epic Panel. In the new solution, the Epic panel will instead look at the Issue Status for each Epic to determine if it should be shown or not. If the Epic issue is in a green status (done), then it will not be shown, unless there are still open issues inside the Epic.

Again, this makes sense as it shift Epics to behave the same way as other issue types, which align behavior in Jira.

New colors based on team based projects

This is something that comes from team managed boards, and I am guessing this is an architectural decision to have a uniform design that can be expanded later using the Parent Link feature from Advanced Roadmaps. In Theory, it would allow you to treat any parent link the same way, and you could set any story color to the issue. To make that useful, there would need to be a change to the Epic panel to show the levels above epic as well somehow.

For now however this will just be a slight color shift when the upgrade comes as the upgrade will match the nearest color.

Epic link will become Add Parent and move to breadcrumbs

Perhaps the change that will confuse users the most is that the Epic link will become Add Parent and that this functionality will move from the standard locations to the breadcrumbs. This makes sense from several perspectives, but it will have a learning curve for many users. Changing the Epic Link to the Parent link from Advanced Roadmaps will once again align Epics with other issue types and allow for a uniform handling of the issues hierarchy.

My Opinion

This is a great change, not just because it will allow us to change Epics to Features (or whatever we want), but also from a technical perspective. It breaks down Epics unique behavior and replaces it with something that can scale, which is exactly what I have wanted for more than a decade.

In the screenshot over the new issue view you also see that there is a pretty significant change to naming for subtasks as well where we now instead see "Child Issues". This is again a way to make way for a more flexible structure that is uniform regardless of level.

This is absolutely a great step in the right direction from Atlassian and it makes me very happy to see.

In the last few years, Jira have moved more and more towards JIRA project isolation. This is causing problems for companies that are working collaborative across multiple JIRA projects, and it is becoming increasingly difficult to use because of that. In a short period of time boards have become almost unusable where cross-linking projects cause things like roadmaps and scrum boards to stop working. This is a mindset issue, as well as an architectural one.

It is clear that Atlassian's tools are focusing on an Agile mindset, focusing on Scrum and Kanban. This has always been the case, but it has never really prevented anyone for using their tools in a more traditional way as well. In recent years however this has changed and with the introduction of team managed projects this has taking a turn for the worse.

With the introduction of team managed products, we have seen product development becomes increasingly fragmented and teams within Atlassian seem more and more isolated. This is typical for organizations working with Agile teams, and we also see this in the new products that are more MVPs than full-fledged applications. This fragmented way of working seem to cause not just alignment issues between the different Atlassian products, but it also seems to affect the architecture as well.

The architecture is all over the place...

If we look at the very basic architecture, we have "projects", which is the highest level of grouping data. This is what we have configuration for, like what issue types, workflows and custom fields we have for that set of data. Projects are divided between Team Managed and Company Managed types, where team managed are unique and isolated projects where anything goes and company managed are controlled and globally defined projects.

On top of this, we add a board, which is a visual representation of a filter in either a Kanban or Scrum view. This is not something that I would consider "optional" because a project without a board is pretty useless. The boards are divided into four areas:

1. Roadmap - Featureless Gantt using Epics that only work with data from one project.
2. Backlog - Basic list with priority and iterations/status for selecting items to work on. Scrum features stop working if you add generic fields to bring in with a specific project attached to it. There is a hard limit of 5000 issues that will actually shut the backlog down if you hit it.
3. Active sprints - Basic column based structure that you map statuses in the workflow to. Hard limit of 500 subtasks that will shut down this feature if you hit it.
4. Reports - Basic reports for different purposes.

As boards are defined based on a filter and filters can include any data from any project and since it is placed on top of a project you would assume that the data would be presented within the configuration of the project. Strangely, it does not because boards actually override project configurations and allow for customizations, even on Company Managed projects.

This makes little sense, since the purpose of having a company managed setup in the first place is to ensure that the setups are the same. If each project can define their own views and configuration of estimates, for example, then what exactly is company managed?

Things like that data from multiple projects can cause problems, like the roadmap being able to change from multiple projects is easily managed by adding permissions for who can and can not change things. A simple check to determine origin project and then who have permissions to make different changes in that project already exist, but it is not used in the roadmap.

Disabling whole boards because of generic queries like "Related System[Dropdown]" = Jira" for the simple reason that it is not specific in terms of what project the issue belong to is a decision I do not understand. Sure, it can add overhead to the query if there are a lot of issues and a ton of customization, but that is solved by having a cache for every board that you check delta for on load instead of dynamically load all items. You also only load data for the listing and then fetch additional data on request.

The limit of 5000 issues in a backlog is not just stupid, it is borderline illegal as it is an unknown limitation that cause denial of service. What makes this worse is that this limit does not just count the issues, but subtasks as well. This makes no sense in a Scrum board where subtasks never show up, and for a Kanban you should be able to turn this off in the settings.

The Atlassian Agile Attitude

This attitude towards technical architecture is not really surprising considering Atlassian is very open about their culture and how they approach things. Atlassian is very dedicated to Agile and especially Scrum, and that bleeds into everything they do. When asked about these problems, the response has been that Agile teams don't need to collaborate as they are empowered and self-organizing. Having a 5000 issues cap is not a problem for Atlassian because an Agile team never have that many issues, so if you do then you are not Agile.

Don't get me wrong, these are all valid responses, IF everyone that used Jira was doing Scrum the way Atlassian defines it. They are not. The vast majority of companies, especially the larger companies, are NOT doing scrum. Or any other Agile ritual for that matter. There are product discovery teams for sure, but in general companies do product delivery, not product discovery. Just check to see how many UX or CRO experiments are currently running in any given company, and you probably will find there are few, if any.

This mentality is also what is consistently blocking requests that go outside the Scrum sphere, like having estimates on subtasks show up on the story in an aggregated form or any form of resource and finance management in any of their products.

It will only get worse

I hate to say this as I like the products, but I have a feeling that this is only going to get worse, at least for another 5 years or so when we will either see Atlassian change directions or another product has emerged that better fit the way companies work. Atlassian is doubling down on the Agile mindset and you can see it in the products where they regularly remove functions and new products seem to be half done with little to no connectivity to other products. This would be ok if the new products would see rapid development once released, but that is not the case.

So I am afraid that if you are looking for a tool to manage projects and tasks where you can set a standard for your company to follow, then Jira may not be the tool you are looking for. Not because it is very bad today, but because it continues to degrade as a uniform tool.

If you on the other hand are looking for a flexible tool that your teams can adjust as they see fit in a snow globe type of setup that is great for design and explorative situations, then you are probably better off with Trello or Asana to be honest.

If you are in need of a predictive tool for financial planning, then none of the Atlassian tools are what you are looking for. Atlassian doesn't support traditional financial structures, as Agile is an exploratory ritual. This could change however as Atlassian is focusing a lot on SAFe it seems and as you probably figured out by now SAFe is a traditional steering renamed and repackaged. So we could see more support for predictive planning tools because of this.

Is there no hope?

Of course, there is hope. Atlassian just must start to focus more on what companies actually need and less what they think they need. To do that, they have to look at the bigger picture and they have to focus on what matters most to all companies: finance. While they have a tool that is supposedly targeting this area it is way too expensive and since you can not test it, it still remains a tool you have to buy on faith alone.

The first thing should be to implement proper team's setup with resource management. Make teams assignable and take a look at BigPicture that have most of what you need: workload plans, holiday plans, absence management, skills, roles and of course time allocation. Connect other applications like Confluence to allow for team spaces only visible in the teams section as well as basic information like contact information, team lead and connected systems from Insight.

The second thing is to stop the Premium nonsense and just have one product. Locking key products like Advanced Roadmaps and the old Insight asset management in a price tier is plain stupid. Not only will you prevent your own products adaptation, you also annoy the customers that are forced to pay for things they don't want. At twice the regular cost, no less.

The third things that should happen is to add seamless integration of the products. If you have ever seen a user trying out OpsGenie from Jira Service Management, then you know what I mean. New products like Atlas should be clearly be marketed as separate products, just like Trello, if they do not connect to the basic Atlassian ecosystem.

Make issue hierarchy open to everyone to define. Have predefined sets for Agile or SAFe setups, but make it open for everyone to define their setup instead of locking down every user in a structure Atlassian want. We are already getting new features for the Epic, which is a great addition, now take it to the next step.

Finally, make boards useful again and remove the caps and the breaking of features if you cross Jira Project boundaries. Add the color background feature from Business projects and allow for any colors instead of a defined set.

My Opinion

In my opinion, Atlassian is moving in the wrong direction in some cases. In other cases, they are doing great things. If you are working in an organization with a project based financial structure that is based around a set of portfolios and budgets, then you are probably hurting right now using Atlassian products, with add-ons.

I also feel that Cloud is way too much of a playground right now, with little to no way to mitigate negative changes when Atlassian destructively removes features from their products. If you are on DC and are considering a move to Cloud I would strongly suggest you reconsider that unless you really know what the result will be and how your workforce will be affected with the limitations and constant updates that you can not control.'

If you are already on Cloud, then keep careful watch on what is going on as information on changes that destructively remove features is rarely very well announced and you have to follow the community forums like a hawk to spot them. Also make sure you frequently check the well hidden suggestion and bug section of Atlassian and submit requests and bugs when things dont work or when you have features removed from the systems.

Working with Atlassian's systems is a bit bumpy at the moment, but it is never boring!

Jira is a great tool, but it is often abused by trying to make it do more than it does. One such abuse I see a lot is excessively long workflows, which is usually introduced by management. This is problematic because the longer the workflow, the more you will need to go up in scope for each issue. This is because there is no 1-1 relation between the different areas. This is the most common cause for having huge stories with tons of subtasks.

Before we go any further, let us first define what Jira is not.

• Jira is not a project management tool, but it can be extended using Advanced Roadmaps to provide some support for this.
• Jira is not a resource management tool, but it can be extended using Advanced Roadmaps to provide some support for this.
• Jira is not a deployment tool, but it can have features that can provide information about deploys.
• Jira is not a code repository tool, but it has features that can provide information about code.

Now, let us take a look at a common process flow for a company.

Based on this we can see that we can build something that support the Ideation where we make designs and prototypes. It would probably make more sense to just have a project with some tasks and then use Confluence, as much of what comes through ideation are never going to be realized. Definition is when we document more about the things that comes from ideation, and we would do that in Confluence most likely. Finance has nothing to do with Jira as we don't have connections to budgets, resources and so on. This is where Jira Align would be best suited.

Specification is the requirement process and that happen in Confluence and then we create stories in Jira for things to prioritize based on cost vs value creation before we hand them off to Realization. Verification is usually a part of the realization flow, but more often than not you would use an add-on for it. Acceptance is either a separate activity that also use the same verification add-on as test, or it is just informally part of the workflow.

Presentation is done completely separate and since we release groups of stories it rarely makes any sense to even have this in a workflow. This is what Releases/Versions are for in Jira. The whole maintenance bit where we deal with Incidents and problems is not connected to the realization flow, but it ties into the Specification. This, since the requirement, define what is an incident and what is not.

So based on this, we see that there is a clear distinction for where Jira is designed to work, and that is between realization and acceptance. This is the optimal fit and then you can extend this using Advanced Roadmaps so you can connect Realization to Finance to get that full span all the way up to strategic level.

What if I want to have a longer workflow?

Nothings says you can't have more. Jira is very flexible and you can do pretty much whatever you want. Before you do, however, make sure you understand who you extend the workflow for and what it means.

Extend with Deploy

This is probably the most common extension as a lot of people are used to having deploy, or rather release, as a part of their physical boards. Adding this to the workflow will add a blanket step. By this I meant that this step has no real purpose other than to inform people outside the deployment process where particular code has been placed. Using the version field will actually give this information in a much more organized way. You can also connect your CI/CD tool to automatically connect release information to your stories, which is probably the best solution if you work with continuous deploys.

If you add this in the workflow instead, then someone in the team will have to manually go over what stories are part of a package and then transition them one by one to next status at the time of the release. Considering that this step often happen well after the development, test and acceptance has been closed, it often happens that this is missed, leaving stories open long after they have been completed. Even if you remember it, you will still have multiple stories open in your boards, which will be a problem if you for example release infrequent or need to delay a release. If release is not done by the team, you will also have actions from another team in your board, which is a bit weird.

If you must have a way to visualize where different code is, then you should always use version. This will clearly show what code package a story belong to and you can filter it and also have a dedicated section for managing versions that you should tie to release notes and so on.  If you absolutely can not communicate where a story has been released without having an issue on your board for it, then I suggest you connect all the issues to a release ticket. That way, you can manage the release just like any other task.

Adding this to your workflow means that you skip the version feature completely and since it is a blanket step it is prone to mistakes and lingering stories that very likely will mess up your statistics. If you have problem communicating releases to management and stakeholders, then I think you have bigger issues than your workflow...

Extend with requirements

Another common way to go is to use Jira as a requirement tool and by doing that extend the workflow to add more steps before realization. There are three major drawbacks to this, however: you need to have more fields added, requirements are not 1-1 with development, and Jira does not have version control or documentation capabilities.

As the requirement process have a different ritual and workflow than development, we need to add more fields. While this is usually not a big issue, it will clutter the backlog, as well as the content of each story. Each Jira project would need multiple boards to handle the two processes so it does not add confusion for the people working in each of the two processes. Overall, it will add more clutter and add complexity to the work in Jira.

In order to fix the second problem with requirements not being 1-1 with development, you would need to lift the abstraction level of the requirements. If you don't then you would make the user story 1-1 with development and that would mean that each development would have to be a subtask instead of a story. That makes it impossible for the developers to break out their own work further. This, however, often make each story an epic, which then means you no longer have any way to group several stories into a feature. Each story will also have quite a few development tasks compared to having multiple stories created for each user story.

The first two issues you can probably deal with, but the fact that Jira does not have documentation capabilities or version control should be a dealbreaker for any real requirement analyst. Not having a way to structure your requirements so you can find them and maintain them is a big issue, and it is why most people choose Confluence or an add-on to manage requirements. Not having documentation capabilities is also a big issue since you will be limited in what information you can add to your story, and you will most likely feel that this is claustrophobic and difficult to get a good overview of since there are so many other things displayed in the story.

Version control is a must for any requirement tool. This is for two reasons: you need to know what was agreed upon, and you must have a way to continue working. With version control, you can set points in time that you can restore to if needed. If you have worked with IT development for a while, then you probably have had a situation, or two, where unlocked requirements caused a lot of problems. This is especially true for design documents that are supporting requirements.

While it is certainly not impossible to add the requirements part to your workflow, you are again adding steps from a completely different process that have little to no relation to development stories in many cases. This is because requirements can, and will, become obsolete or too costly to be picked up for development during the requirement process. Just like with deploy, you will add complexity to the workflow and the boards, and the team will have information in the stories that are irrelevant for their area of responsibility.

The most common effect of adding requirement steps to a workflow is that there will be (at least) two boards. One for working with requirements and one for development. It is also very common that the stories will be larger to the point where work will mostly be done through sub-tasks to compensate for the lack of 1-1 relation.

Extend with business processes

This is not as common, but I see it from time to time. This is not a very good thing because the abstraction level goes way up and even the subtasks will be very large as the workflow starts on a project, or even program level. Even at the smallest amount of statuses for each step you will have a minimum of 14 statuses and I have seen workflows with up to 27 statuses. I do not think I need to tell you how painfull that was for everyone involved...

The problem with having business workflows included in the build workflows is that the business workflow and the build workflow are completely different. The business workflow is all about financing value creation and the build workflow is about realizing the need that has been approved in the business workflow. This means that there are three hard decision points that can stop the progress of the issues:

1. Ideation - Do we think the theory of value creation is motivated by the value the idea creates? This happens before we even consider looking into the issue further.
2. Financing - What budget will the feature fit into? If it exist, do we want to prioritize it over other features and if it does not, how do we fund it?
3. Specification - When we have broken down the feature so we know better how to realize it, is it still worth doing and if so should we prioritize it?

While you certainly can extend the workflow and make a behemoth that will plague everyone in all aspects of your organization, you should consider the next aspects of mega workflows: Complexity and bloating. In order to support multiple processes in one workflow you need to extend the information in Jira as it is built for the built process. That means that you will need to add a lot of additional custom fields. This is bad because not only will it be much harder to work with a bloated issue where the majority of information will not be related to th work you do, it will also slow down the project a lot.

This problem will be even worse when you consider the amount of people that will need to have access to the project. Since you involve everyone up to a strategic level it means that everyone from business level down to realization will need to be included and working in the same projekt. I have seen Jira projects where thousands of people have worked in multiple teams, all with cusomizations to the workflow and content leading to hundreds of custom fields. Loading times could be as high as 3-4 seconds in a DC setup with load balancing and anytime you tried to look at the workflow the browser would crash.

Having the business processes in Jira is not a bad thing, but you should divide between business and build processes, preferably with Confluence as the middle layer to document requirements and tecnical solutions. Tools like Advanced Roadmaps or BigPicture can help extend the capabilities towards the business side as well.

Will it stand on its own?

One thing I always ask is if you can take the extended parts of your workflow and let it stand on its own, or is it actually a part of a singular process? I do this to see where people are in their mind so I understand how they think about the work. On one hand, I do understand the need to have an overview of the work from strategic level down to the smallest task in the operative level. I just don't think that Jira is the tool for that, because it is a task management system, not a program, or even project management tool. This is where Advanced Roadmaps and Jira Align comes in. These are the tools that should give you the overview (Advanced Roadmaps on Operations level and Jira Align on Strategic level).

When the users understand that having multiple steps in a process, where the outcome is not 1-1 with the next step, might not be the best solution, then you can show them what a board will look like with all those steps. The number of columns alone should be enough to see that a long workflow like that is not very useful. I have seen a workflow that required 27 columns, which of course is not something you can actually work with.

Use the correct tool instead

The solution in most cases is to not add more steps to a single workflow, but to extend the hierarchy and use something like Advanced Roadmaps, or split the work into two, or more workflows that can exist independently in different Jira Project.

In the series Setup Jira and Confluence - Introduction to setting up Jira & Confluence for success, that I will rewrite and make videos of in 2022, I will go over the tools and the setup in more detail.

I hope you found this usesful, and as always if you have any questions feel free to ask. No questions are stupid and if there is one lingering in your head, you can be sure others have the same questios, so you would make them, and me, a favor by asking it ❤️

Atlassian recently announced a reboot of their Jira Core, which was practically unused by everyone due to its lack of unique features. The reboot comes with a new name, Jira Work Management, and a new setup focused on business teams. This is a great change and it will make Jira a bit more interesting for business teams in the future.

Quote

This is the first Jira built for business teams, by business teams. We crafted this new Jira experience directly with customer design partners of all sizes and industries, as well as internal Atlassian teams of every type — including our own Jira Work Management teams.

Four views to rule them all

Jira Work Management focuses around three main views: Board, List View, Timeline and Calendar. There are of course other features as well, such as a form builder experience as in Jira Service Management and the ability to pick a background color. The focus is on these four views however and they will determine how the business teams will react to this reboot.

The List View

The list view will appeal to anyone who spend a lot of time in Excel, or if you use something like Asana or Tasks in Teams. Inline editing and individual settings for the visual changes are big selling points, even if I foresee a bit of confusion when the views differ from user to user.

Quote

In-line editing is the new standard. Our list view makes updating and adding new tasks fast. Teams can show or hide columns, drag-and-drop tasks, and sort or filter their work. Visual changes to the list view, such as sorting, filtering, and altering columns, happen locally for each user. Our users were tired of messed up filters in spreadsheets and so were we!

Timeline View

The timeline view is pretty much a slightly watered down version of the Roadmaps feature in Jira Software. It will work well for team level, just like Roadmaps in Jira Software, but not much more.

Quote

We’ve redesigned some Jira features for business teams, which means this ain’t just your simple roadmap. Tasks and Subtasks are now visible on the timeline view as bars, and issue data is displayed on the bars themselves to keep staying in context easy. Plus, dependency management and clear issue hierarchies are staying to make sure this view stays full-powered.

Calendar view

The Calendar view is nice, even though I am not so sure how useful it actually is. if we could tie it to our tasks in Outlook, then maybe the calendar would be more useful, but for now I think it will be more of a glance tool, just like the list and timeline views. I could be wrong though and I would need to try it out to test it out for real.

Quote

For a long time, we’ve hidden calendars in Confluence or dashboards. Now, they’ve made the prime-time. Create new tasks from empty spaces, see the current status of work at a glance with color-based (and icon-based) bars, or quickly switch to “Today” from any date.

Board View

The board view is the only view that existed in Jira Core as well and it looks pretty much the same. This is very similar to Trello and it will be a nice alternative to Teams that are used quite a lot for this kind of view for many business projects.

Quote

Fewer updates here, but we've added lozenges to the column names so it's easier than ever to see what's a To-do, In progress, or Done status category. We also added support for seeing how many subtasks relate to a card on the board. Expect big changes to the board later this year!

Conclusion

The four views will pretty much satisfy most need from a business team, but my question is how these boards will tie in with the steering products Advanced Roadmaps and Align? I see this as a common theme with Atlassian lately with the same concern for Next-Gen projects and so on. It's something I will bring up in another article though.

Introducing Forms

It is interesting to see that forms are moving out from Jira Service Management as a way to create input and display forms. I think this will probably show up in Next-gen projects down the road as well. It is a good change and I think it makes perfect sense to make input and output presentation in this way.

Quote

Simple requests need a simple solution — our new project forms have you covered. Project admins can make a new form for each project in seconds by dragging over relevant project fields. You can change how field names appear on the form, spend time making your description perfect with a full-fledged editor, and rearrange fields instantly — all with autosave to back you up.

Background color

Adding a background color to your project will not make or break the customers' appreciation of it, but it is a nice icing on the cake. I don't see what the point is to restrict to standard colors when you could just add a color option to the surrounding text as well and let users add whatever color they want. I foresee images coming soon as well, just as for Trello.

Quote

Last but not least, project background colors are finally here! Project admins can choose from 14 colorful themes with the click of a mouse.

So why do you want this?

Adding business teams into Jira are a good thing. Earlier it has been a bit difficult to convince them to join, but I think that the List View will be a big selling point to be honest. Maybe even the Calendar, even if I am not seeing it at the moment.

Having the business teams in Jira means that you can bring in a lot of processes that currently live outside of Jira. This will allow easy management of early project/program planning, procurement processes, staffing, legal and security management and not to mention brick and mortar projects such as store building.

This is of course the first release of Jira Work Management and it will very likely evolve quite a bit in the coming year or so. For now, it is also free for all Jira owners, so once you get access to it, I suggest you take some time to check it out and see what it can do for you and your organization.

You can sign up on the waiting list here:
https://www.atlassian.com/software/jira/work-management

Regardless if you work in a continuous delivery flow like Kanban, a sequential delivery flow like waterfall or an iterative delivery flow like Scrum, you will benefit greatly from having portfolio management. Having a dedicated funnel ensures that you get a proper overlook of your incoming request. In this article we will discuss how that can be done by creating a process for it in Jira Software.

Advanced Roadmaps is a very useful tool because it allows us to get the big picture. It also allows us to scale the hierarchies in Jira for issue types. This is important because the standard hierarchies are designed for teams, so they do not scale well. While you can work around this using the sideways approach where you have the higher hierarchies in a separate project and link between them, that is not really a hierarchy. This also works poorly when you wish to display things in Advanced Roadmap.

The first thing we need to do for a proper hierarchy view in Advanced Roadmaps is to define the portfolio levels. We need to accommodate for multiple scenarios as requests, or demands, often come in different forms. The most common types are projects or even programs, or new features. We also want to make sure we can work with the different frameworks out there, so we add a collaboration level as well as defined in SAFe.

To avoid a lot of confusion between different frameworks and other tools, we rename the Epic issue type in Jira Software to Feature. It will not be perfect, but it will have to do until we get the ability to rename it properly when Atlassian makes that change in the future.  We do this by going to Issues -> Issue Types and edit the Epic issue type. We also add two new issue types for Initiative and Capability.

Next we go to Plans -> Settings -> Advanced Roadmaps hierarchy configuration. There we add two new levels called Initiative and Capability and map them with our newly created issue types with the same names. Finally, we rename the Epic to Feature, and we should have our first hierarchy defined. We can go back and adjust this later if we want. The setup should now look like this:

We can now add this to our projects by adding the issue types to our Issue Type Schemas. Depending on your setup you may want the new issue types for Initiative and Capability to exist in a separate Issue Type Schema, or you will add them to the standard schema. Either way we still need to give the new issue type a workflow that match their purpose. So we head over to Issues -> Workflows and create a new workflow.

Again we want to consider what the purpose of these issue types is and who will actually work with them. Initiative, Capability and Feature are all used by management and requirement analysts to provide information on how to realize demands. That means that we do not have the same transfer of responsibility as for User Stories. Instead, we need to consider what we actually do in the portfolio and what we need to track in terms of activities.

SAFe have a pretty good example of this for their Portfolio Kanban. Their first step is Funnel and for us that is pretty much everything that comes into our workflow, and we define this as new. Anything that comes in to the portfolio needs to be reviewed to see what we should focus on next. Since we will not review everything we add two steps for the review process: Ready for Review and In Review. This allows us to only pick things that we want to review by moving them from new to Ready for Review, and then we have an active status to indicate that we are working on this.

We do the same for Analysis, which is the step where we involve Business Analysts and Requirement Analysts to define the need in more detail. For this we add Ready for Analysis for when the Review process lead to us spending time to break down the need in a requirement process. We also add the In Analysis to indicate that it has entered the Requirement process.

Before we close this workflow we add the Implementation process as well. Ready for Implementation indicate that the requirement process has led to a decision to implement and In Implementation indicate that the need is being fulfilled. We do not fracture this further as we can easily drill down to individual tasks in Advanced Roadmaps, and it is not really useful to have for example test and release part of this workflow. That is because each issue type will have many issue types below it, and you can only transition on the last sub-task, making it misleading and feeling stagnant.

Finally, we add a status for Blocked/Pending to allow us to track when things are preventing this activity from being fulfilled. This can be external or internal dependencies or financial reasons for example.

As always we go for an open workflow to allow for free transitions. We add a close screen to the Close status to set a resolution and then add a post function to remove resolution on all other statuses. This workflow should now look like this:

The final step is now to go to our workflow scheme and add this new workflow. We do this by going to Issues -> Workflow Schemes and click edit on the workflows scheme we have Initiative, Capability and Feature added to. We click add Workflow and add the new workflow we just created. Then we select that this workflow will be applied to Initiative, Capability and Feature before hitting save.

This should now allow you to work inside Advanced Roadmaps using Initiatives, Capabilities and Features in a proper portfolio management process that allow for larger projects and programs as well as manage smaller feature or even user stories.

I hope you found this useful and as always, if you have any questions just write a comment and I will do my best to help you.