Jump to content
View in the app

A better way to browse. Learn more.
JimiWikman.se

A full-screen app on your home screen with push notifications, badges and more.

To install this app on iOS and iPadOS
  1. Tap the Share icon in Safari
  2. Scroll the menu and tap Add to Home Screen.
  3. Tap Add in the top-right corner.
To install this app on Android
  1. Tap the 3-dot menu (⋮) in the top-right corner of the browser.
  2. Tap Add to Home screen or Install app.
  3. Confirm by tapping Install.

My Articles

These are articles written by me, Jimi Wikman. These articles are written on a wide range of topics. The main focus is of course on Atlassian, but as I am also very much interested in other areas that I have worked, or are just interested in you will also find other categories here. Under Ways of Working you will find articles relates to the build process management, design, requirements, development, test, operations and support. Under Interesting I write about security, e-commerce and Invision Community. Under professional, I write about work as a consultant, work related health issues, business related news and other topics related to professional work.

There is a problem with Jira Service Management escalations...

If you have worked in a larger company you probably have noticed that escalation between the different support tiers cause a lot of problems. Perhaps you even notice this in medium or even small companies as well. The reason for this is that Jira Service Management is missing functionality that is needed for escalation to work properly. For a tool that claim to be an ITSM tool, this is quite strange, but well in line with the way Atlassian thinks about their products.
If you are unfamiliar with ITSM and support tiers, then I suggest this nice article as a starting point: https://www.bmc.com/blogs/support-levels-level-1-level-2-level-3/. If you don't want to read all that, then the short summary is that in ITSM support is set in multiple levels of technical expertise.
It starts with a basic support, which is to answer the most obvious questions and to make sure the tickets have enough information. Then the tickets Tier1 can not solve goes to Tier 2 which have more technical knowledge and so on. You can have as many tiers as you want, but most models have 3 or 4 where the last tier is outside help towards vendors for example.
Jira Service Management does not support collaboration
This might be a strong statement, but in this case I feel it is actually true. Maybe we should say handovers, which is what we are actually talking about, but since communication has to remain constant towards the customer I feel that this is still true.
So what am I talking about?
In Jira Service Management today there are hard boundaries around the projects that can not be bridged without harming customer experience. What I mean by that is that in order for me to hand over a ticket to another team I am restricted to 4 options:
Have everyone working in one giant monolith project. Move the ticket to another project. Clone the ticket to another project. Create a linked ticket to another project. Before we dive into what these 4 options mean, let us first define what our customers expect from the interaction with support. From a customer perspective they have a problem, or a request of some sort and they have done their job by submitting a ticket to support. They now expect support to handle their request and solve their problem in that ticket. This is a fair expectation and if we break this expectation they will experience frustration.
1. One Monolith to ruin it for all
This is by far the most common way to work in small companies and it is how Atlassian envision us using Jira Service Management. One box where everyone that needs to be involved have a role. The problem with this setup however becomes very apparent when you start to grow as an organization, or when you start to have multiple products and services with shared resources.
Not only will there be a lot of people in the project, perhaps several hundred people or thousands even if the organization is large, internationally distributed or need to handle multiple companies setup because of company structure or acquisitions. To be able to make sense of a large instance with many teams you need to make a lot of queues and this is where the first problem is with Jira Service Management today: There is no nesting of queues. You have to get an add-on to handle that, which add cost to your already quite expensive platform.
The second problem is that when you mix many teams in one project, you will start to add complexity as the various teams want to customize their experience. You will start to build automations with multiple exceptions, you need to start adding local groups with all the problems that come from that and you will have subsets of screens connected to customized issue types and... well you get the idea. It quickly becomes messy and soon you will have manuals for how to work based on what type of request for which team you are working for to navigate all those custom fields that confuse everyone.
This is a horrible way of working.
If we instead work with Jira Service Management where we have an IT Support desk for first line support (Tier1) and dedicated projects for Tier 2 and Tier 3 teams, then we are in a much better place. But there are still issues...
2. Move ticket to another project
Our first option when not working in a monolith when we want to hand over a ticket to second or third tier teams is to move the ticket to their project. It makes sense technically because the tier 1 team will have no more involvement with this ticket and it should not be handled by another team.
From a customer service perspective it is a terrible option, however. Not only do you break all old communication because by moving you are now changing the URL and the ticket ID. This will make all old communication useless because links will not work and the poor customer no longer can reference the ticked ID as they now have a new one.
Technically you also have permissions to consider and if you do not have the same setup the customer can lose access to their ticket all together. The information in the ticket can also vanish if you do not use Forms and the custom fields are not the same in the projects.
Any SLA you have will also be ruined since each project have their own SLA and when you move a ticket the SLAs will be reset as they are counted again with the new SLA in the project they are being moved to.
In short: Never move support tickets if you can avoid it.
3. Clone the ticket to another project
This is an even worse solution than moving the ticket. Not only do you get all the negatives from moving the ticket, you also duplicate the information. This means that the customer now have two identical requests, but you also have different statuses and different communication. If you for example clone the ticket and then close the initial ticket, the customer will get a notification that their request has been closed, which will confuse the heck out of them when they then get a reply in a ticket that look identical, but with a different ID and different URL.
In short: Never clone a support ticket unless you REALLY want to frustrate your customers.
4. Create a linked ticket to another project
This is very similar to cloning the ticket if you are doing it wrong. That would be that you create a linked ticket and assign it to the customer. Then it would just be a cloned ticket you have linked.
Used correctly however that creates a separate conversation between the two teams. This is how it should be used in Incident Management for example where we need activities to be performed in development or Infra teams for example.
This will not help us in our scenario where we want to make a handover, however as the customer conversation still will be in the original ticket. We could build an automation that sync the conversation between the original ticket and the linked ticket, but since that will be posted as the actor in the automation communication will look very bad on both sides.
We will also still have to keep the original ticket open in the project for the Tier 1 team, even though they no longer have any involvement. The customer experience might be ok, but the setup will clutter up the queues for the Tier 1 team. The Tier 1 team will also be responsible for the SLA, which means that they might unfairly get bad SLA results because of the Tier 2 team activities.
In short:  this is probably the best option, but it is not very good.
 
How do we solve this then?
Without knowing the architecture of Jira Service Management the suggestions here might be more or less difficult to accomplish, but I will make the suggestions based on the customer experience and UX rather than architecture.
1. Change Queues to allow tickets from any project
I can not for the life of me understand the architectural decision to restrict this when boards have had this functionality forever. Just this small change alone will make Queues so much more useful and it will allow teams to work with multiple requests from one area. Queues for Jira Service Management have the right idea, but they focus on local groups, which any sane Jira Administrator avoid like the plague, especially if they already sync users with the AD.
Make Queues like boards so they can be attached to projects or a user. Not only will that allow teams to work cross projects, but it will also open up for different views that can lead to add-ons or native improvements to how support in general can be designed.
2. Add account sync to automation
It would be very nice, not just for thise scenario, to be able to synch comments WITH the account that made the comment rather than using the automation agent as the author. This will allow for a better customer experience and it will make many types of setups feel more seamless than it does today.
3. Build a native handover function
While we can work with custom fields to handover ticket between queues if we get the change to queues to allow data from any project, I would much rather see a native function in Jira Service Management. The reason for that is that it would allow extending that function with more innovation and standard functionality.
The way I envision it a customer agent would just click on a handover link or button and then get a screen like the move screen. There they can select what project they want to hand over to and possibly what team. A comment field can be there by default if they want to add an internal comment as well.
When the support agent submits the ticket is flagged as handover and in their project it will no longer be visible by default in the original project (as it has been handed over). There should be a way to set up a queue to see all handover tickets however if that is wanted. This action will also trigger a new ticket in the project the support agent handed over the ticket to.
What makes this different from just a linked ticket then?
The first change is that the handover ticket work like a cloned ticket with the same information as the original ticket. This means that reporter for example is the customer and not the support agent as when you create a linked ticket.
The second change is that all comments are synced between both ticket with the account information on who made the comment. This way the communication is seamless from the customer perspective and the support agents. It also means that everything is synced toward the original ticket, making that the master regardless if the ticket has been handedover due to escalation.
If the handover ticket is handed over, then the same steps should happen, but the sync should now be done twice, once for each of the tickets in the chain.
What about the workflows?
This is a problem as many teams what to have their own workflows. As we can not, or want to, force people to have the same workflows, we need to figure out what status we will show to the customer. Each ticket will of course show whatever status the team put it in so they can follow their workflow in Jira Service Management, we just need to consider what to show to the customer in the portal.
I can think of several ways to solve this.
The first solution is to just add a label instead of using the workflow. This label can just say Escalated for example and the label stays until the ticket is closed. It is simple, but perhaps not the best from a customer experience perspective since the status actually is communication.
The second solution is to choose either the original ticket workflow or the handover ticket workflow. This can cause some strange scenarios if there are many different statuses between the original ticket and the handover ticket. Having status change from in progress to Open or New for example might be a little weird. While that can be fixed with not changing status from the original ticket to the handover ticket until it has moved at least one transition, it is not fool proof and can be confusing.
The third option is to treat this as some form of integration so we setup a mapping between different projects. This would be a massive thing to build and a pain to manage, but if done well it could probably be used for other things as well. This require you to do a lot of work also every time a new project is added that you might want to handover to.
The fourth option would be to present a choice when you transition a hand over ticket with the combined list of statuses from the original ticket or the handover ticket. It is messy and pretty much the same as #2, but less useful.
There are of course more solution to this, so if you have a good suggestion, please add it in the comments.
Communication must be taken seriously
Regardless how we look at support and what solution we prefer for escalating to other teams, we must remember that communication is key. No matter how good we are at solving problems it means nothing if we agitate the customers by not communicating while we solve their problems.
By breaking communication in any solution we have today, or forcing teams to be suboptimal by working in monolith projects we are limiting the potential of providing exceptional support to our customers.
I think we should take this seriously.
What do you think?
By 💫 Jimi Wikman in Atlassian ·

Related Pages for Confluence - discovering content just got easier

Related information has been used on written content since it's inception, and now Confluence is adding functionality for this as well. It is a feature that not always is welcome, however, but don't worry, you get plenty of control to decide if it should be used or not. Not just per space, but even down to page level.
While we don't have specifics on the algorithms that make this new Related information work, but we can probably assume that labels and keywords in title and headers in the content is used somehow. We do know that the related pages will honor permissions, so you can only see pages you have access to. The official information have this to say:
When this rolls out, it will be turned on by default, which may be a bit annoying. Fortunately, you can turn this off for whole spaces in the Space settings under Space settings > Related pages. You can also turn this on or off on individual pages under More actions (•••), then Advanced details > and either Show related pages or Hide related pages.
In the first iteration of related pages, it will not support Blogs or Jira Service Management customer portals. While this might seem strange as these two areas are where you normally would use this feature, but I think it is a good thing as they can tweak the algorithms a bit before taking that step. This should help make that feature better when it is released. This should help a lot with support if the algorithm is good enough, which I think it will be once they get some data from Confluence usage and tweak a bit first.

 
By 💫 Jimi Wikman in Atlassian ·

Internet Explorer is dead - Internet Explorer is officially retired and out of support

Internet Explorer is DEAD. Finally. After decades of making lives miserably for thousands upon thousands of front end developers across the globe, we can finally celebrate the end of Internet Explorer. For me, this is a great relief and yet another remnant of the Steve Ballmer area that I am happy to see put to rest. Microsoft will not put their efforts into Microsoft Edge, which like most things that has been introduced under Satya Nadella seems to be pretty good.
Microsoft has finally announced the death of Internet Explorer as they officially retire and end support for Internet Explorer 11. It has been a long time coming, and many of us old people have grown up with Internet Explorer. Some of us even remember the battle with Netscape, back in the days before Netscape became Mozilla and then re-invented itself as Firefox. We have seen Internet Explorer almost gain monopoly status, only to slowly die as Firefox and Chrome ate away the market share.
As frontend developers, many have cursed over the course that Microsoft steered Internet Explorer under Steve Ballmer's reign, always insisting on having its own quirks that forced countless hours to "fix". For many years, front end developers had to support the hated Internet Explorer 6 because it had been built in into many company solutions at the time. It was hell. Pure and simple.
Ever since, Internet Explorer has been despised for its reluctance to conform with standards the other browsers agreed upon and for the need to polyfill and CSS hack just to make websites cope with the madness.
I, for one, are glad that Internet Explorer is dead.
Now, rest in peace and long live Edge.
 
By 💫 Jimi Wikman in Interesting ·

Upcoming changes to Epics - finally getting some flexibility for Epics

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:
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.
By 💫 Jimi Wikman in Atlassian ·

Jira harder to control - Jira projects slowly becoming less collaborative.

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:
Roadmap - Featureless Gantt using Epics that only work with data from one project. 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. 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. 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!
By 💫 Jimi Wikman in Atlassian ·

The Problematic Epic - the undefined term that cause confusion

Epic. It sounds so cool and people love to use it. It is that bucket of undefined things that is just...large, that we love to throw things into and proclaim that it is an Epic. But what is an epic? There lies the problem, because the term Epic is defined in many ways in different methodologies and in different levels of the organization. This makes the Epic arbitrary and confusing, because the value of the epic depends on the context, which is rarely known.
Most people are familiar with the Epic through a tool like Jira or ServiceNow. These systems have adapted the Agile, or rather the Scrum, which defines an Epic as "a big chunk of work, which can be divided down to smaller bits". Atlassian, the makers of Jira, takes that a bit further:
So in both examples it is something big that can be broken down. In other words, it is something that has not yet been broken down fully and remain a bit vague because of that. This vague definition of something big, cause all kinds of problems, especially if what the Epics are broken down to are poorly defined.
In Jira for example you have a Story (Not User Story as defined on their website. A User Story is related to Requirements, not tasks), which in the best case will be defined as some form of work that can be done within an iteration (sprint most commonly). This means that you can have pretty much any size of task in a story, and it can be anywhere from full features to a small configuration.
Since much work starts on the business side even in Jira, then it is very common to have the Jira Epic turning into a Portfolio Epic...
 
Portfolio Epics in SAFe.
If we go up a bit within the Agile sphere, then let us see what SAFe says about their epics:
SAFe even have a specific definition to define that an Epic is not a project, which should tell you how vague the Portfolio Epic is in SAFe. It becomes even muddier when Portfolio Epics in SAFe leads to Business Cases with high level estimations, which projects also need. The difference seem to be that the Portfolio Epic is a funding without scope or time frame, which to me is the same as an extra budget for research and development or some form of business operation scenario.

Epics everywhere...
Epics can be found pretty much in all tools you look at, and in companies you will find that the term "Epic" is just as abused as the term "project" or "Initiative" as it is applied to everything. Are you working with strategic themes? I bet you have some strategic Epics as well, right? How about focus areas? Do you have epics there as well, maybe? How about your requirement process, I am sure you have heard your product owner talking about Epics on multiple levels as just things that are undefined in their mind?
Just to make things worse, you even have methodologies named EPIC.
 
Epics in traditional development.
In traditional development, we don't have Epics, but we can translate it based on the definitions used in Agile. I found this definition I thought fit pretty well:
I think Epics are more similar to top-level requirements, but I think the fact that they can also be similar to mission threads illuminate the problem with Epics. As a top level requirement it fit both the team or system based focus as in Agile methodologies like Scrum, but it also fit the SAFe Epic definition, which I think is interesting.
That would suggest that an Epic is defined on the level where it is placed and depending on how you divide between need and requirement the term Epic would be a top-level requirement in both situations, or they would be a top-level need when defined as a SAFe Epic.
 
So how should we think about Epics?
Regardless if you work in an organization that claim to be Agile or not, you will most certainly come across the term Epic. If not in your systems, then people will use the term based on how they have used it in the past. So you need to deal with them and you need to define them in a way that makes sense for every scenario.
My suggestion is that you define the term Epic as a level top-level requirement. This way you know that whatever is in that epic, it is not useful until it has been broken down into smaller pieces. As such, an Epic is a container that is meant to hold actual requirements once defined properly.
If you have Portfolio management, then define a Portfolio Epic as a top-level need. A need is a loose description that will lead to one or more requirements should the need be funded.
If you want an even more clear definition, then you can define the Epic as an operational Epic and a portfolio Epic as a strategic Epic. This should help define the level of the Epics and place them more clearly in the strategic and the operational areas.
 
Do not use Epics as Themes or focus areas.
If you start using Epics, of any level, as a way to categorize things based on strategic themes or focus areas, then you will start muddling the waters and the definition of an Epic as a top-level requirement or top-level need will be pointless.
Themes and focus areas are directional based, while requirements and need are action based. Having them become interchangeable means that you will either only work with directional goals with no actions defined, or you will only have action items and no direction. None of those scenarios are very good or healthy.
An epic should never be a direction or a goal, it should always be a defined activity that lead to a certain goal. So an Epic should always be connected to a theme or focus area, but it should not replace it or live in limbo without the connection.
 
Epic should be defined, or it is nothing.
I have spent more time discussing what an Epic is and is not when working with work processes than any other term. Without a definition, an Epic will cause confusion and frustration as it will become a change shifting monster that represent everything from a strategic theme to project to idea to design task. And beyond. It will be this go-to phrase for anything undefined that we don't want or have the experience to actually name correctly, or work with properly.
It will be everything and also nothing.
 
Epic in Jira could be a feature.
In Jira, I always define operational Epics as Features. It is a top-level requirement of something that once released add value as a separate feature. That means that when released, the Epic will be closed in Jira.
This is because I never have requirements in Jira, as Jira is a temporary work tool that should never, ever hold any documentation. In Jira, you should only have instructions on how to complete the task. That means that Epics in Jira should only be connected to top-level requirements in Confluence, not be the actual top-level requirement.
Unless your company have decided that you do not document requirements, then you don't need to define where to put them and can do whatever your team desire.
 
How do you use Epics?
I have seen many ways to use the Epics and even more ways to describe all kind of things as Epics, but I am always eager to learn more on how others use it.
So how do you use it, and why have you set it up that way?
By 💫 Jimi Wikman in Ways of working ·

Atlassian acquire Percept.ai - strengthening their ITSM products even further

Atlassian announced yesterday that they have acquired the small California based company Percept.ai, a company that focuses on AI technology to automize support flows, in quite impressive ways. This will strengthen the tool set of Jira Service Management with a new automation technology in the form of a no-code virtual agent that I think will add a lot to the Jira Service Management experience.
While Edwin Wong, the Head of Product Management at Atlassian, did not go into any details in the announcement, it is clear that this will be an important part of the future of Jira Service Management. I also think the acquisition of Percept.ai and their virtual agent technology will find its way into other areas of the Atlassian suite, and I would not be surprised to see an AI driven onboarding agent in the future!
I think this is a strong acquisition and an important one for the Jira Service Management product specifically and for Atlassian in general.
 
By 💫 Jimi Wikman in Atlassian ·

Jira Product Discovery - The missing link between business and IT?

Atlassian has just released their new product called Jira Product Discovery in Beta. It is a new project type in Jira Software, just like Jira Work Management, and sadly it is equally a bit lackluster when it comes to functionality. It is however a very nice addition and it has the potential to bridge the gap between business and IT, which is currently being done with creative setups in Jira Software.
So what is Jira Product Discovery?
In short, it is a tool for adding good ideas where you can define value and cost in order to make educated decisions on what to focus on first for your different products. Or just to start new products and value streams. Right out of the box in the Beta, we find many good features such as visual fields for effort and goal impact, the ability to score ideas and the most powerful aspect is the connection to create epics in other Jira projects to truly connect ideation with delivery.
Jira Product Discovery is a very nice new product that can compete with other tools like Aha!, but it is also a typical Atlassian product with limited functionality that may or may not expand down the road. This has been a problem for Atlassian in the last 5 years or so and it can affect the sales of this new product, unless it becomes part of the core like Jira Work Management is now.
 
Functionality looks great!
Even with the risk of having a less advanced feature set than some of the competitors, Jira Product Discovery have a good feature set already.  Things like goals, what can target strategic values, or even smaller product goals is something I work with a lot. Things like effort ranking, key customers and connections to time periods and something they call buckets are all great features.
The ability to add automatic calculation of value is great, but I would like to see the ability to add negative values as well for things like risk and effort. Overall the score system is quite simple and it needs a more granular setup for it to be useful in large scale organizations.
Overall, I think this first iteration of Jira Product Discovery looks impressive and it will most likely fit many companies need as is.
 
It is a Beta
It is easy to point to things that are not awesome right now, but it is important to know that this is a Beta. As such it will be features that are either not yet there, not finished or that will change during the Beta. While I see several things that I think are essential for the future success of Jira Product Discovery as a product, I would not discourage any organization from trying this out even in its Beta format.
That is because this fit a very critical gap in the current product flora for Atlassian and I think this hit the spot pretty close to what a lot of people have been asking for, for a long time.
Don't take my word for it, though, head on over and try it out yourself.
 
Introduction Video
 
By 💫 Jimi Wikman in Atlassian ·

5 new features in Confluence to kick off the new year with

Nothing makes starting a new year as exciting as getting new, fun toys to play around with, and for Confluence we have five of them to talk about today! Not only will you get some nice new ways to present your pages and data withing, but we also get some features that might very well change the way you work. So let us dive in.
#1 Page Status - a game changer?

I don't think I have seen anyone using Confluence without having a status in the page properties to indicate the current status of a document. Now we get a built-in function for this that looks very useful indeed. I can think of a million uses for this, but the question is how this works with things like page properties reports and different listing macros.
 
#2 Presenter Mode

The presenter mode looked a bit weird at first, but it has quite a few use cases where it works very well. One being training or education, and another is to present reports to stakeholders. I think it is a pretty nifty feature to be honest!
 
 
#3 Table visualization

The wet dream of so many managers is to visualize data with graphs. While this may be a very limited experience compared to other tools, it is very much a step in the right direction.
 
#4 Multiple Excerpt Macros

For me who advocate the usage of one source of truth, this is a very good addition. I often use excerpts for design documentation and for non-functional requirements, and I have sometimes wished I could have two or more sections to embed in different ways. With his update, I can now manage these things more freely. I like it. A lot.
 
#5 The new Confluence Home

This change looks really great and I can't wait to see it live. If you want to read more about this change, then check out this article: https://community.atlassian.com/t5/Confluence-Cloud-articles/Say-hello-to-the-new-Confluence-Home/ba-p/1892543
 
These are just a few of the new changes coming to Confluence in 2022 and I will do my best to cover all of them here on the blog and on the YouTube channel.
Which is your favorite of these and why?
By 💫 Jimi Wikman in Atlassian ·

Long Workflows in Jira - Multiple processes in one workflow is problematic

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:
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. 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? 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 ❤️
 
By 💫 Jimi Wikman in Atlassian ·

The Importance of Communication - when TRUST dies horribly and organizations fail

This week alone, I have seen two great companies stumble and suffer serious damage to their brand. Not only did they alienate customers and cause short term financial loss for themselves, they also cause long term damage to their brand and reputation. This is something that could have easily been avoided by simply following standard practices and putting effort into proper communication. In this article, I will give you my point of view of the events and some ideas on how this could have been avoided.
Atlassian - removing features and failing to communicate it
Atlassian have had problems with communications for a while now, and this in itself is a big problem. This week, however, I was preparing for introducing Advanced Roadmaps to a company I work for, and I was very surprised to notice that some features was missing. As it turns out, this was announced back in May on an obscured page in their documentation.
I assume that a notice was sent out around that time, but it seems it did not reach everyone (I never got the mails) and then apparently they did not think any more of this. A minor notice, barely noticeable in the release notes, can be found for the July 26th release. No marking to indicate that this will reduce functionality and rather than explaining what is being removed they refer to "live plans", which almost no one know what that is in reference to.

My question is: what information did new customers that signed up AFTER May 10th get regarding the fact that functionality they were buying would be removed later that year? When I upgraded to Premium, there was no warning and no mention of this, and I have not received a single email regarding this change.
To make matters worse, it seems that not even support knew this was happening so when I submitted a ticket to ask where my features had disappeared to, they referred to the differences between cloud and DataCenter. Obviously, they had no idea this feature was removed or that it had ever been a part of the cloud product.
So, how should this be handled to avoid upset customers that suddenly loose functionality from a premium product they pay a lot of money from? Well, the simple answer is of course to communicate. In this case, you have 2 communication paths to cover: existing customers and new customers.
Existing customers - Direct communication is a must. No one have time to read release notes or blog posts. People have companies to run, and removing functionality from a premium product is almost unheard of without a replacement product or alternative. On May 10th this should be a focused email to all premium customers where the changes in the product would be clearly communicated and detailed.

3 months before the removal, another letter should be sent to remind the customers about this change. Then again every month to ensure no one misses this information. Every release note from May 10th should have a notice at the top reminding of this change as well. This notice should be properly marked in red with a warning sign to illustrate its importance.
  New Clients - Present changes up front. In the upgrade and order form, you should add a notice that the current implementation of Advanced Roadmaps will have changes happening soon that will remove features. You don't want to start a relation with a new customer with the feeling of lying and not being honest. While not a lot of clients was effected by this change, it has significant impact on TRUST. Not only do I not trust that Atlassian will keep me updated on changes to their products, especially when it comes to removing features, I also do not trust that they will be open with me when it comes to financial issues. This is a huge problem and I know that this is not just me feeling this way as I hear many other Atlassian consultants and customers starting to feel the same way.
Atlassian needs to step up their communication as they seem to be stuck in their corporate bubble lately and focusing more on making money than their customers. I think Pete Morris, the roadmaps/Advanced Roadmaps product owner, displayed this well in his response to me.

While Pete is a great guy and his response is kind and professional, it also shows a distinct lack of understanding of how to communicate with customers. In-product notifications are nice, if you assume that people actually read those, or even understand what they mean. Passive communication does not substitute direct communication, and more often than not the people who need the information are not the day-to-day users.  It is the people in charge of tools and work processes and finance that need it, as well as the system administrators.
I will of course reach out to Pete and discuss this with him and others at Atlassian, not to point fingers, but to give my point of view to hopefully prevent similar situations in the future.
 
Invision Power Services - massive surprise price increase and reducing support without notice
IPS, the company behind the software I use here on the site, stepped into a hornets nest this week when they sprung a massive surprise change on their clients. Instead of a simple update to pricing and their support, they now have a PR nightmare on their hands. Their new website refresh that was supposed to be filled with praise over the new design is now a sad tale of angry and disappointed clients. When writing this the thread has 384 replies and it is bad...

So what really happened to warrant such a massive surge of frustration? Well, it was a combination of things, where I think the biggest issue was that people realized big changes to pricing and support by browsing the new website. There had been no information on this change beforehand, and the changes was quite substantial.
Price updates - This was a huge price change where people not only saw their price go up with anything between 30% all the way up to 300%. Most seemed to get a 50-60% increase in price, however, and while that surprise in itself was bad... Billing cycle changes - Payment periods was to pay the license fee every 6 months, but after the update this was changed to 12 months. Not only did people see a 50%-60% increase in license costs, it also doubled in size since it is now a yearly cost. For me, this meant that I went from $105 every 6 months to $310 every 12 months. That is a 50% increase for me. No more support, unless you pay for it - This was a very strange one as IPS now will shift everything towards community support unless you pay a whopping $1250/year. Yes, you read that right... $1250. Unless you pay over 100 dollar a month for ticket support, your support experience will be going through an open support forum. IPS claims that you can ask for private support or use the contact form if you do not want to post sensitive information in public, which seems very odd to me. For me, that just add a step for IPS support, the way I see it? It could have been different...
This could easily have been avoided, and it could even have been a positive spin on things if handled correctly. No one really mind the price change because we all knew that it had to come sooner or later. The change should have been done gradually, however, with the proper communication.
First announce the change 3 months in advance. IPS need to increase prices to up the development and support efforts. Everyone wants to see more features and bugs fixed faster. Everyone wants support to be better. Not a hard selling point to make. Offer anyone that want to commit to IPS to pay for a longer period of time now before the price change. - Show that you care about the current customers and also get a big chunk of short term cash to invest. Next renewal price remains the same for all existing customers - Again show that you care and appreciate the current customers by extending the existing price 6-9 months depending on when their next billing is due. #2 above should cover any current cashflow need, and you get a ton of goodwill. New customers pay the new price, of course. Offer multiple billing cycles. - Matt tried to motivate having just yearly billing with that customers can get confused or happen to pick the wrong cycle. I don't buy that as it is a UX issue and they own the product in charge of billing. I had a web hosting service for 15 years with multiple billing tiers and no one ever got confused by that. Having multiple options would help a lot for many that have problems funding $300 one time fee, but find it easier to fund maybe $30 monthly. Yes, you can do that anyway if you like with the ability to deposit money, but it is not something that people are used to. Define your support properly and offer ticket support. - While I get the idea to move questions to an open area to reduce the number of same questions being asked over and over, that is not the answer to the problem. I am all for the community driven help with IPS staff doing the heavy lifting, but you need to have an option for ticket support as well. I think it would have helped to put classification on the support tiers to make it easier to understand:
  Tier 1 support - Paid Premium support with response time within 1 hour and a resolution time within 48 hours. You can even offer per ticket support where a customer can pay a sum for priority support either per incident or for say a month for example during a migration or critical sales period. Tier 2 Support - Ticket support in a private forum with only own tickets settings. This is used only for technical support issues, meaning that something is not working with your software. Tier 3 Support - Community driven support where you can ask any question and get help from the community as well as IPS staff. The key point here is to communicate, in advance, present the negative changes with a positive that motivates the negative. A price change should lead to improvements for the users, like better support and faster feature cycles or investments. This way you motivate the change and you give time to absorb it. This is important because the human mind is very sensitive to change and rapid change has a tendency to cause frustration or even anger.
IPS did the complete opposite by letting their customers discover the changes on their own and then selling the change with no upside for the customers at all. Instead the customers now pay more for less as prices went up and support was removed. That is a double negative, which is extremely hard to sell to your customers.
This was a part of the email that was sent out hours after the release of the new website and the new price model.

The wording and the way this is presented is directed inwards. It tries to motivate price changes with an historical reluctance to increase prices, which is pretty much what every landlord in the world do when they want to make more money and care nothing about their tenants. It has never been received well and it was not in this case either.
Claiming that the services and products hold great value is a moot point to make towards their customers. We know this, that is why we pay in the first place. What we want to know is why should I pay 50%-60% more tomorrow compared to today? What has changed and how do I get better value for paying more? Making claims that major features have been adding and referencing gamification (which is not a complete system btw), anonymous posting and Zapier integration does not really motivate why you want me to pay you more. I already have those features!
Switching to annual renewal billing because it is a simpler way and in line with industry standard show a distinct lack of connection with the customers and it is again directed inwards. It is not easier and more wanted for the customers, but many would have loved to have that as an option. I am of course talking about companies, but they are not the only customers IPS have.
The fact that this came out hours after the release of new prices and changes to support models enforces the feeling that this was an afterthought and that IPS care so little for their customers that they only informed them after they started screaming. I know that is not how IPS see their clients, but the perception is still there due to this mistake.
IPS failed in communication and people are leaving
Due to this very simple mistake to not communicate and not making sure the customers understand the reason behind the price change this has now caused many customers to cancel their subscriptions. This will have a ripple effect on the mod creators either leaving or increasing their prices substantially. Less mods means less customers and less customers means less community support, which leads to a feeling of abandonment and ultimately a reduction in sales.
Worse though is that IPS loose their customers TRUST. Again.
IPS is on a very dangerous path, and has been for a while, due to the fact that they seem to lack a communications officer that have experience with communication strategy and financial strategy. While Jordan is doing an amazing job trying to communicate with the customers on the forum and social media that is not enough to save them from blunders like these. Not even Matt trying to do damage control will do anything in this situation.
The damage is done.
The ony question is how will IPS handle this now that they have screwed up. They can either continue to ignore the vocal customers that do not approve of these changes, or they can roll back and make a new plan to roll out later this year.
If they ignore the customers I think they are going to have a really bad 2022, especially as people get back to life again and spend less time online again. Many struggle with finance now and it is not hard to motivate a move to less capable competitor with such a huge increase in pricing. Customers will drop like flies, not just because of the changes to price and support, but because they no longer trust IPS as a company.
If they roll back and make a proper plan in communication with their customers, then they have a chance to salvage some customers at least. Many will still leave due to the lack of TRUST, but the chance for redemption could salvage that to some degree. With the proper communication they can even turn this into a win, but that would require a communication plan that is very different than what we have seen so far from IPS.
 
Communication is not a nice-to-have!
If you run a company then you sould know that communication is not nice-to-have. It is an essential part of your business and if you fail in communication you not only can, but you will, damage your brand and business.
Anytime you deal with change for your customers, make sure your communication is aimed towards them. Make sure you present the benefit for them, not for you. Change is never accepted up front, so you must always sell it to prevent backlash. It is very difficult to fully recover from a communication mistake, but you can mitigate and in some cases even improve your relation with your customers.
So don't ignore the importance of good communication and if you are not a communications expert yourself, hire one. It will save you a ton of money from stupid mistakes like Atlassian and IPS have stepped into and it can increase your revenue a lot.
Good luck!
 
By 💫 Jimi Wikman in Ways of working ·

Price increase - but why the obfuscation Atlassian?

Atlassian are raising the prices for their cloud services on October 12th, which is perfectly ok. What is a bit strange though is that they for some reason seem to purposely try to hide just how much they are raising the prices. It does not say in the email, and the link takes you to the FAQ rather than the price list. A price list that only have the new prices and not the old for comparison. It is a bit odd.
This seems to become a norm for Atlassian lately, to hide information and prevent comparison. I don't like it and I don't like the direction Atlassian is taking in terms of communication and information in the last few years. Atlassian used to be good and open about their prices, but lately it feels that they are doing everything they can to obfuscate and hide information purposely.
I am not sure if that is because they have a strategy to adopt dark patterns in their UX to prevent a clear view into the actual costs (like airlines do), or if it is just some bad practice on their part implemented by someone who don't understand the customers.
For example, why not include the new pricing in the email you send out to the customers? You know what products the customer own as it is part of your database, so it is not rocket science to add customized templates based on product ownership. If people could do that 15 years ago when sending out printed catalogs that had your car and your color on the front page, then I am sure that Atlassian can set up a simple database that can send targeted content to product segments.
Even if you can't because you have not done the work, or your master data is crap, you can still send the entire pricing table, or at least link to it!  Instead, you send out a letter that say nothing with a link to a page that does not have the pricing information I am looking for.
 
Not even the FAQ landing page that Atlassian link to have a link in the text or any form of directional que to the single most important question clients will have when landing here: What are the new prices. Sure, there is a link component to the left, but nothing that indicate that these are related to the new pricing structure. It's just sloppy and poor UX in my opinion.

Once you click in to see the pricing tables, you would expect to see the new prices and the old one for comparison, right? Nope. Atlassian shows only the new prices. If you are anything like me, then you never really pay attention to the actual price per tier, you know your monthly cost, right? So it would be nice with a place to see your new cost based on the new prices... but nope. You just have to wait for the next bill to see what the new price might be.

As you can see, the start plans are going to be shafted once more. So if you have one, hold on to it because it looks like they will increase the price on that tier with 750%.
 
Now, it is not very difficult to present the information on the increase in a more useful way. Just add the information on both the old and new price, along with the changes in both value and percentage. This is what Jira Cloud Standard looks like, for example, if you spend 2 minutes on it:

 
I think this could be a problem because the person in charge of the INFORMATION is a designer used to work with PRESENTATION. Having tables that look good is one thing, answering the questions of the people looking for answers is another. If you present new prices that will affect people's decision to remain a client or not, then you better do better than this Atlassian.
This was not good, so step it up.
Ok?
By 💫 Jimi Wikman in Atlassian ·

Configure browser push notifications
Chrome (Android)
  1. Tap the lock icon next to the address bar.
  2. Tap Permissions → Notifications.
  3. Adjust your preference.
Chrome (Desktop)
  1. Click the padlock icon in the address bar.
  2. Select Site settings.
  3. Find Notifications and adjust your preference.