I am rebuilding this site (click to read more)
Jump to content

Articles

wdfw w ff wdf sfsfd sfdwdfsdfwerw r werw erwe rwe rwer werwer werw erwer we r we rwerewrwe rwe rwer wer werwer werwe

My Articles
Community Articles
Guest Blogging Information

My Articles

Show all categories

Atlassian Cloud changes Dec 30 to Jan 6, 2020

This is a repost from Atlassian's blog where the latest updates to the Atlassian cloud platform is posted. It is reposted here since the Atlassian blog does not have an RSS feed and so we can discuss the changes to the Atlassian Cloud architecture. You can follow these posts withe the tag "atlassian cloud changes".
Atlassian Cloud
Your cloud-hosted products are supported by the Atlassian Cloud platform. This section usually includes changes related to multiple Atlassian Cloud products, site administration, and user management.
Email users with suggested account changes Rolling Out 
From the Change details button, you can suggest that a user changes their account details to make their profile more consistent and easier to identify. Read more about administering Atlassian accounts.
Give your users a Trusted permission 
From a user's Permission options, select Trusted to give certain users more responsibility. These users will be able to install and configure new products on your site and invite new users themselves.
Claim accounts after verifying a domain 
To start managing accounts on your domain, we’ve included an additional step that requires you to claim accounts after verifying that you own the domain. From the table on the Domains page, click Claim accounts next to the verified domain. Read more about verifying a domain.
Set your language and time zone for Jira and Confluence in your Atlassian account profile
Rather than individually setting your language and time zone in Jira and Confluence, these preferences will soon come from your Atlassian account profile. Visit your account preferences to update these settings. It may take up to 10 mins before your updated preferences are reflected in Jira and Confluence.
 
Jira platform
Changes in this section usually apply to all Jira products. We'll tell you in the change description if something is only for a specific Jira product.
New user profile cards
When you hover over someone’s name in directories, on dashboards, and in user picker fields, you’ll now start to see rich profile cards with more information and a link to the user’s profile (if you have permission to see it).
Next-gen: Epic panel in backlog 
You can now manage epics on the backlog of your next-gen project via the Epics panel, similar to how epic management works in classic Jira Software projects. Changes you make in the panel on the backlog will reflect on the Roadmap, and vice-versa.
Advanced search (JQL): Search for content updated by a specific user
Use the updatedBy() function to search for issues that were updated by a specific user, optionally within the specified time range. For example, if you want to find issues updated by John Smith between June and September 2018, enter issuekey IN updatedBy(jsmith, "2018/06/01", "2018/08/31"). Read more about the updatedBy() function.
Search for and filter projects by their type with the "projectType" JQL field
We added a new JQL field to search for and filter projects by their type. Type projectType to filter “software” (Jira Software) projects, “service_desk” (Jira Service Desk) projects, “business” (Jira Core) projects, or “ops” (Jira Ops) projects.
 
Jira Software
We're rolling out a new type of project known as next-gen. By default, any Jira Software licensed user can create their own next-gen project. These projects don't affect existing Jira projects, shared configurations, or your schemes. You can manage who's allowed to create next-gen projects with the new Create independent projects global permission. Read more about next-gen projects.
GitHub app on the Atlassian Marketplace 
We've partnered with GitHub to build a new and improved integration, which you can install at the Atlassian Marketplace. This replaces the DVCS connector in Jira's system settings. Current GitHub integrations set up under the old method will continue to work, but new integrations must be set up using the app on the Atlassian Marketplace. We're rolling out this update gradually, so it may not be on your Jira Cloud site yet.
This won't affect GitHub Enterprise integrations, which must still be set up via the DVCS connector.
Next-gen: Roadmap issue hierarchy
You can now expand an epic on your roadmap to see its child issues and their statuses. Learn more about managing epics on the roadmap.
Next-gen: Create child issues on your roadmap 
You can now add child issues directly on your roadmap. Just hover over an epic, click the + icon, and give your issue a name. Learn more about managing epics on the roadmap.
Next-gen: Add the Environment field to issues
Add Jira’s built-in Environment field to your issue types in next-gen projects. In your project, go to Project settings > Issue types and drag the Environment field into the Description section of the issue layout.
Large backlogs load faster 
Big backlogs can take time to load, and teams usually work with a small chunk of the issues at a time. Knowing this and striving to make backlogs render faster, we've changed the default to display only 100 issues (90 from the top and 10 from the bottom) from your backlog. The remaining issues will be displayed if you click Show all issues.

We've also introduced a number of backend changes that resulted in faster initial loading.
 
Jira Service Desk
Issues with the customer organizations field now use the organization name instead of ID when exporting to CSV 
When exporting Jira issues to CSV from the Jira Issue Navigator, the Custom field (Organizations) now contains the name of the organizations linked to the issue. The field previously contained the organization ID, which was not valuable for exports used for reporting.
As part of this change, a CSV import can now match organizations by both their ID and their name. No changes are needed if you use CSV export files for import.
New issue view for Jira Service Desk 
The new issue view groups key actions and information in a logical way, making it easier for you to scan and update requests. Learn more about the new issue view.
Use keyboard shortcuts in your queues 
Use keyboard shortcuts to navigate around your queues and get your work done faster. You can now move through issues, select their fields, and go to the issue view from your queues just by using your keyboard!
Customer portal request details page redesign 
We have redesigned the customer portal request details page to make it easier to use. You’ll notice we have added a rich text editor, sorted the activity stream from old to new, and have moved the location of the request fields, share button, approval and comment boxes.
Maintenance complete on the customer portal user profile page 
We have just completed some maintenance on the customer portal user profile page.
We also introduced a new layout that is easier to use on mobile devices. Go team!
Easier configuration for the new issue view 
If you have the new issue view, you can now easily configure how your issue view looks for each request type.
From your service desk project, go to Project settings > Request types and you'll find the new layout for making changes.
Global create can select request type and raise on behalf of 
You can now create a request on behalf of your customers and set them as the reporter. Use the global create button ( + ), then select Raise this request on behalf of and add in your customer's email.
 
Confluence
Your editing experience just got an upgrade 
The new Confluence editor allows anyone to create beautiful, powerful pages effortlessly. Check out the editor roadmap to learn more.
We're extending editing improvements to all pages on Android 
The editing improvements we made to blogs a few months ago are coming to the rest of your Android mobile pages, too. In addition to being faster and more reliable, your new pages are also responsive, optimized for readability, and have advanced tables. Some macros are still missing as we rebuild them, but you can check the list of changes and track updates to macros on our docs site.
Annotate images in the new editor 
Annotate images by adding text, inserting shapes and lines, using brushes, or adding a blur to a certain area.
Confluence Cloud recent pages drawer 
We’ve made it easier to get to the pages you visited or worked with most recently. A new action has been added to the global sidebar that presents you with a list of your recent pages; interaction-specific tabs help you narrow the list based on your actions, like visited, edited, or saved as draft.
Share pages directly with your team 
It’s now easier to share pages with everyone on your team, all in one go. When you click Share on any page or blog post, Confluence now lets you add a team – no need to enter each person individually. Learn more
Jira issue URLs are converted to smart links 
When you paste a Jira issue link into a Confluence page, the URL is converted to a smart link that displays the page icon and the page title. This works if the Jira and Confluence sites are linked or if they are both cloud versions.
Convert pages to use the new editor 
You can now convert your existing pages that were created using the legacy editor to use the new editing experience! Learn more
Confluence navigation just got better 
Get to information faster with improved navigation – making what you need visible from anywhere in Confluence. Learn more
Align and resize images in tables in the new editor 
When images are inserted in table cells, you now have the ability to align and resize them.
Portfolio for Jira plan macro 
The Portfolio for Jira plan Confluence macro lets you embed a Portfolio for Jira Server and Data Center plan in a Confluence page. Join key stakeholders in the spaces where business goals are built and tracked, and share how work is progressing across multiple projects and teams.
Improved expand element replaces the macro 
Content creators just got a better way to control the way information is presented. The existing expand macro has been replaced with a quicker, easier way to include the expand functionality. Insert the improved expand element using /expand or by inserting the element from the editor's Insert toolbar.
Jimi Wikman
💫 Jimi Wikman

Atlassian introduces their new cloud development platform Forge

Earlier in 2019 Atlassian presented their new cloud development platform FORGE at the Atlassian Summit. The idea is to have a tool that makes it easier and faster to develop apps for the Atlassian cloud suite using a serverless FaaS hosting platform, powered by AWS Lambda.
This new cloud development platform will probably be a welcome tool for new app developers and if received well it will push development for cloud to the front lines. All in accordance with the business strategies Atlassian seem to push towards cloud in general.
According to the article by Atlassian, Forge comes with three core components:
A serverless Functions-as-a-Service (FaaS) hosted platform with Atlassian-operated compute and storage for app developers A flexible declarative UI language (Forge UI) that enables developers to build interactive user experiences across web and devices with just a few lines of code A state-of-the-art DevOps toolchain, powered by the intuitive Forge Command Line Interface (CLI).  
A serverless Functions-as-a-Service
The first component with the FaaS I think sounds excellent as one of the big hurdles with app development for Atlassian (and other systems) is hosting and develop the app as a separate web service. Having FORGE do the heavy lifting should make that threshold a bit lower (depending on the cost of course).
 
Atlassian list 3 specific areas that they hope that FORGE will help with:
Trust: As personal information goes digital, privacy, transparency, and security are more important than ever before. With Forge UI, developers and app consumers benefit from built-in, best-in-class security for apps, by default. Plus, thanks to Atlaskit, when Atlassian makes an update, your apps won’t break. Running anywhere: Atlassian customers want experiences that are consistent across their products and apps, and across their devices and web. Forge’s UI enables users to build once for both web and mobile. Moving up the stack: In general, developers aren’t concerned with where their code is running – they simply want to spend less time on implementation details of the code, and more time on providing customer value. Forge’s serverless FaaS model enables developers to write single functions rather than building entire web applications.  
There are also other areas where FORGE can help reduce pain points and increase security.
 
A flexible declarative UI language
The second part I am not sure if it's a good thing or not. For anyone developing only towards cloud based Atlassian systems it is of course awesome as it makes things easier and we get a more unified design across apps as well as systems. It is when dealing with multiple ecosystems such as Server or Data Center this can become a bit complicated.
On one hand it forces even server based apps to follow the design specifications of Forge UI, but on the other hand it can limit the app developers. Overall it should still be a good thing and as it is based on Atlaskit it should be pretty well aligned with the overall UI design for cloud.
 
A state-of-the-art DevOps toolchain
For the DevOps toolchain I would like to know more before making any assumptions as it seem to be based on Bitbucket pipelines that are still quite new.  I like Bitbucket Pipelines, but I would like to see if this is just a built in version of it into FORGE or if it has some changes.
Things like defining environments within AWS Lambda and what the UI for this will look like. Is it "just" a CLI and if so, what capabilities can I expect within the CLI itself. Will this be connected to Bamboo for the build or can I choose other build tools such as TeamCity for example?
The fact that this part is barely mentioned in the article of the presentation is a bit of warning flag for me. If it is state-of-the-art, then please show me the tool chain and give me an example of a simple code update from development to production. Still, this is just me being a bit nit-picky as I am sure there are already videos out there for this or they will come soon enough.
Overall I think this will be a bit of change for many app developers today, but a good change.
 
Welcome to the Forge - Presentation at Atlassian Summit 2019
 
Personally I think this is a great thing that will help app developers a lot. Old app developers might need a while to adjust, but in the long run I think it is a good thing. Adding this service not only ensure that things get more uniform in terms of design and coding, but it also will provide great insight into how a controlled DevOps toolchain is perceived outside of their own company.
I look forward to learn more about Atlassian Forge that is currently in Closed Beta that you can sign up for here.
 
What do you think of Atlassian Forge so far?
 
 
Jimi Wikman
💫 Jimi Wikman

Setup Jira & Confluence for success - Part 4: Defining Jira Screens & Custom fields

In the last article we talked about defining workflows, so now it's time to talk about defining custom fields and screens. The custom fields is where most companies make many mistakes by trying to build new ways for Jira to work and screens almost no one seem to use. Let us change that, but first let us go over what these things are. We start with custom fields.
Custom fields explained
Custom fields are extensions of the data built in to Jira by default. This allow you to make adjustments to your Jira instance in the event that you need it. Custom fields comes in many pre-defined formats such as date fields, droplists, labels and even cascading select lists. In short you can model the data you work with pretty much any way you want. That is usually also the big problem with custom fields...
Custom fields are defined just like most things in Jira using attaching the custom fields to a scheme. For custom fields this is called Field Configuration Schemes. These schemes connect a custom field configuration with the custom fields. This field configuration is what defines how each custom field should be used in a specific context. This allow you to have different behavior and configuration for the same fields.
Custom fields - new data objects that extend the database model. Field configuration - Definition of configuration and behavior for custom fields. Field configuration schemes - map fields with field configurations. This is attached to a project to define that projects field configuration.  
Impact on performance
Custom fields have an impact on performance. Period. Anyone who think otherwise do not understand how custom fields work or what impact they have on the system.  Jira uses an indexing system that cache data in order to quickly find the relevant data you search for. For this Jira uses Apache Lucene, an open source high-performance, full-featured text search engine library written entirely in Java.
Whenever you use a board, filter, dashboard or search in Jira you will use Lucene. Every custom field you add will grow the data exponentially in the index as it will be added to every single issue in Jira, even if that issue does not have any data in the field.  Just by adding custom fields you will see an impact on performance and if you are careless about the size of your projects or do not manage your releases properly, then you can render the Jira instance almost unusable dye to loading time.
Use custom fields with care!
 
Mandatory fields impact
Mandatory fields can be set in the field configuration. This will make a certain field mandatory that you have to fill in. This may sound like a great way to force the users to fill in the data you want them to, but in reality it is causing serious issues, especially when working with any form of integration.
When you have integrations that send data to Jira, then do not use mandatory fields, or make sure that it is mandatory for all projects. Having multiple versions of what data is mandatory is a sure way to make integrations fail. This is because we set up a condition that say that unless this data is part of the data you want to submit, it will fail.
The most common reason for using mandatory fields is because the teams do not understand why they should fill in the data. This is because of poor education on how the workflow should be done or because the way it is designed makes no sense to the people actually doing the work. This should be solved on a method and process level and not in the tool.
 
Building new systems in Jira with Custom fields
The biggest failure I see in Jira is when custom fields are used to extend the capability of Jira to something it is not built for. The most common thing I see is that a story is used as a business need and then kept all the way though deployment. I understand the thought behind it, but the execution will require dozens if not hundreds of new fields and it will just become a mass of data that is almost impossible to work with.
Jira is first and foremost a development tool. It starts with a need that has been transformed into a work order for the development team. In many cases you also have test included in Jira. Often as a plugin or just in the workflow itself. That is all Jira should do as there are other tools that should handle business need, requirements as well as build and deployment.
In large organizations this behavior is very dangerous. I often see people getting burned out or just give up an aspiration of coherent and logical way of working as the systems evolve to grotesque monsters no one really understand or want.
Do not build new ways of working, stick to the standards that exists and you will be much happier. If you are going to extend the capabilities of Jira, then always use a Jira designer that can design the system globally for all users. NEVER allow teams and groups within the organization to design on their own, unless they are an isolated group that never need to work with outer teams or systems. That lead to a fragmented way of working that will cost millions to repair in the future.
 
One field to "always" use
Despite all the issues that comes with custom fields there is one field I always think makes sense. There are others of course because in all organizations there are a few fields that makes perfect sense and that really improve the way of working. One such field is "Team", but only if you are not using a plugin like Portfolio for Jira as that already have teams built in.
The reason why team is useful in almost any scenario is because it allow you to work across Jira Projects in a standardized setup. This way we can avoid Jira projects with hundreds of people and instead work with boards. Using this field you can assign issues to teams rather than people allow for cross project assignments. We will discuss this more in future articles.
 
 
Screens and why they matter
Where custom fields are abused to the point of absurdity in many organizations, screens are barely used at all in my experience. This is strange as screens are very useful for making sure you are working with the right data at the right time. This will make things much easier when creating new issues or allow you to have certain data filled in during transitions in the workflow.
Screens are divided into 3 views:
View screen - The view used when you look at an issue i Jira. Edit view - The view showed when you edit the issue. Create View - the view when you create an issue. This allow us to focus the information in creation view for example to make sure that we only see the fields that we actually need, and then have all information in view and edit.
When defining screens we have three parts to do so:
Screens - Where we define what data should be available in the screen. Screen Schemes - Where we define what screens should be used for the View/Edit/Create views Issue Type Screen Schemes - Where we define what screen schemes should be used for the different issue types. One common use of defining screens is to define the create view for defects. This allow for a more focused defect report process where only the fields we really need is shown when creating the defect. Once created it will allow for all the same fields as a story since it is actually a story that describes a need that has yet to be addressed.
 
Defining fields in a screen
So, first we start by defining the screens.  First we want to create a new screen for defects so we can define the fields we want when creating new defects. We go to Jira Settings ->Issues -> Screens where we find all our current screens. Then on the top right we can click the button to create a new screen. Add a name and a description and then click add.

 
This will take us to the screen configuration page where we can define the data we want. Since this is a defect we want to capture the problem, where the problem occurred and also who should get the defect to look at. We define the fields like this:
Issue Type* - Needed to we can set this as a defect. Reporter* - So we know who reported the defect for follow up. Summary* - The headline that summarize what the problem is. Environment* - Where was the defect found (test, pre-prod, dev and so on). This is needed for defects, but if this had been for production incidents we would not need this field as it is always in production. Affects version* - what code base or release is this related to so we know in what code we should look for it. Description* - This is where the defect is described. It should be steps to reproduce and expected results. Attachments - Pictures or videos that help describe the defect. NEVER upload office files here as you need to download them, which is a horrible way to work. Assignee - Sometimes used to assign a defect to a QA lead for example or a Project manager for attention. Responsible team - When the responsible team in known it can be added to the defect as well. Priority / Severity - How bad the defect is and not how soon it should be fixed. Components - what area of the system the defect affects. Labels - for labeling. Linked issues - If there are other issues that are relevant to the defect. Epic Link - If you use epics to group things. * These fields are mandatory. The rest can vary depending on your work process.
It is important that these fields are also available in the default screen. If they are not present there they will not show as we do not have custom screens for the view or edit screens in this example. If you forget to add them, then do not worry. The data will still be there, but it will not show until you have added the fields to the screen.
 
Defining views for Defects
With this done our next step is to define the three views for defects so we later can attach it to the right issue type. We do this by going to Jira Settings ->Issues -> Screen Schemes and click on the button saying Add Screen Scheme. Add a name and a description, then set the default screen. This should not be the new screen we created as that one will only be used for the create action. You can change this later if you want.

 
With that in place we come to the configuration page where we assign screens to the three actions we have (Create, View, Edit).  By default you have one screen defined for all actions here, which is the one selected when creating the screen scheme. Now we will add our new screen to the create action and we do that by clicking the top right button that says "Associate an issue operation with a screen".  Now you can select one of the three actions and a screen. We select the create action and connect that to our new defect screen and click add.

 
Defining screen schemes to defects
Now that we have the screen configured we need to add it to the correct issue and to do that we first need to create a issue Type Screen Scheme. We do this by going to Jira Settings ->Issues -> Issue Type Screen Schemes. Again we click the add button in the top right and add a name and description. This time we also can select a default screen scheme so we add the default screen sheme that will be used for all actions rather than the custom field we created for creating new defects. This can be changed later if you want.
Once we have this created we get into the configuration screen. Here we will have a default screen scheme set for all issue types. Now we will need to add the new screen scheme we created for defects here. We do that by clicking the button in the top right that says "Associate an issue type with a screen scheme".  Select the issue type Defect and then the screen scheme we created earlier and click add.

...and we are done.
From now on we will always see the fields we have defined in the Defect screen when we create new defects. We can edit the fields as we see fit and it will not affect any other screens. Since we did not create custom screens for edit or view it means that we will see the same fields as for all other issues once the defect has been created.
 
Focus information when needed
As you can see it is not very complicated to add new screens, but they can add quite a bit of focus to your workflow. For this example we created a focused screen for reporting defects, but you will most likely want additional screens. One such screen that I almost always add is the Resolve screen that shows up when you resolve an issue. This is done by adding a trigger in the workflow that add a screen on an action as a popup.
We will cover that setup in another post.
I hope this was useful for you and in our next article we will discuss Jira security & access. In case you have missed any of the previous articles you can find them all here.
 
Jimi Wikman
💫 Jimi Wikman

Secure your passwords - top 5 password managers in 2020

A new year, and a new decade, is here and with that you probably have the urge to make new beginnings and start fresh with exciting projects. One suggestion is to take a look at securing yourself online by adding a password manager to avoid getting your accounts stolen as well as reduce the frustration of remembering all passwords. Here are my top suggestion for password managers in 2020.
Security online is a difficult thing and with limited resources and competence in law enforcement for online crime, you would do well to take some additional steps to protect yourself. One such step is to manage your passwords online. Most people have dozens, if not hundreds, of accounts registered online. Most use the same login and password for all sites, or perhaps they have 3-5 variations that they mix with.
This of course means that if one site is hacked and your passwords stolen, then all your accounts will be in jeopardy. Having unique passwords for each site is of course much, much more secure and if you have long passwords it's even better. The problem is remembering hundreds of long and complicated passwords, which is pretty much impossible. This is where password managers come in handy.
Password managers act as a secure vault where you have one master password to rule them all. You get help setting good passwords that are randomly generated and not reused in multiple sites. This vault can then be accessed from any device so you can login with just one master password while still ensuring that all your logins use unique passwords that can not be used on other sites. Protecting your accounts online can be simplified using a password manager and these are my recommendation for 2020.
 
LastPass

Offers free version Price: Free for limited, $36 per year for premium account, 48$ per year for family account. Works with: Windows, MacOS, Linux, Android, iPhone and iPad. Browser extensions for Chrome, Firefox, Safari, Internet Explorer, Edge and Opera.  
 
1Password

 
Offers trial version Price: $35.88 per year Works with: Windows, MacOS, Linux, Chrome OS, Android, iPhone and iPad. Browser extensions for Chrome, Firefox, Safari, Edge and Opera.   
Dashlane

 
Offers limited free version (50 passwords on one device) Price:  Free for limited version, $59.88 per year Works with: Windows, MacOS, Android, iPhone and iPad. Browser extensions for Chrome, Firefox, Safari, Internet Explorer, Edge and Opera.   
Bitwarden

 
Offers free version Base price beyond free: $12 per year  Works with: Windows, MacOS, Linux, Android, iPhone and iPad. Browser extensions for Chrome, Firefox, Safari, Edge, Opera, Vivaldi, Brave and Tor Browser.   
 
KeePassXC

 
It's free Donations accepted Works with: Windows, MacOS, Linux, Chrome OS, Android, iPhone and iPad, BlackBerry, Windows Phone and Palm OS.
Jimi Wikman
💫 Jimi Wikman

3 new features for Jira Software Cloud's roadmap

The Roadmap feature in Jira Cloud's NextGen projects is getting three new features. While all good additions, the question still remain who these new features are for and to what extent these new features will make people move over to NextGen projects.
NextGen for Jira Cloud is in a strange place as it is not really defined what is can and should be used for. The Roadmap feature is in a similar place as it fall somewhere between Portfolio for Jira and the Roadmap planner macro in Confluence. These 3 new features are an improvement and a good indication on where Atlassian are going. The question is just how fast these new features are coming out and if it appeal to the target audience.
Drill down into the details

The first feature is the ability to open up the Epic and see the underlying tasks. This is a much needed feature that was heavily requested and also one I spoke with Atlassian about earlier this fall. This is a good feature and a good step to improve the roadmap, but is still in need of further refinement.
We still only have Epics as the starting point, which will limit the use of Roadmaps. Opening up the subtasks will only show their status at the moment, which is useful, but not what many want. Many still want a Gant view where the sum of the subtasks should make up the time in the Epic. This is not possible at the moment and I find it interesting that Atlassian has chosen to follow an Agile first approach to the Roadmaps, which means it will not be very useful for the majority of the companies using Atlassian's products today.
 
Add new tasks directly in the Roadmap

Another great feature that was much requested is the ability to create new sub tasks directly in the Roadmap.  This way we can build up a full stack of tasks for a project in one view, which is excellent for portfolio and project planning purposes. The fact that we do not get full Gantt view for the sub tasks makes this a little less useful for time and resource planning however.
 
Filter your Epics and Tasks

The ability to use different filters is a must for any Portfolio, but even roadmaps benefit from filtering options. In this release we get the filters for issue status and assignee, which is a good start. I would like to see some more filters like dependencies and of course issues that are behind the time schedule. The question is just who this Roadmap feature is for though as then we are moving more into project management and Portfolio management and Atlassian has previously stated that the Roadmap is for teams.
 
It's a good start, but...
I am still not sure where NextGen projects are heading, which means it's hard to say if the features are great or poor. We know that Roadmaps will be ported over to the Classic project types as well, but that will make things even more confusing. This is unfortunately a common issue with Atlassian as they are getting more and more fractured with no clear indication on structure or strategy.
Roadmaps for me is something that should stay as a team tool for small teams to give an overview of the current work. To cater to that need Roadmaps could benefit from a few changes.
The first would be to change the basic structure and allow the view to be in any level. That means that I should be able to use Stories rather than Epics as Epics are just containers and not work tasks. The majority of issues are not connected to Epics in most teams, especially if you work in a Kanban setting for continuous improvements for example.
The second would be to go full gantt, or rather to give the option to go full gantt. Not every team need or will use estimation in issues, but most do. Without a full gantt the view of issues will not be as useful as a progress overview tool. It's like saying that I have a container of a certain size and in that container I have put five items. On the question if the items will fit my only answerr will be "I don't know", which is in many organizations not an acceptable answer.
The third would be to add dependencies on issues and not just on Epics and extend the data to also show data from other projects. In most organizations dependencies are not within the team itself, but to surrounding teams. Even if the view is for the team it makes sense that I should be able to see what other teams could be affected.
The fourth would be to ensure that Roadmaps becomes a granular part of a larger view. Right now it is an isolated feature, which means that we will have different data for different levels of the organization. This will lead to miscommunication within the organization as teams will say Epics, which will mean something very different to Program managers and Portfolio managers and so on. As more and more organization add SAFe to their processes it is important that the team view is part of the greater whole.
I am sure we will so many great additions to Roadmaps in 2020 and hopefully many of the questions we have regarding Roadmaps and NextGen projects will get answers then. Until then these three new features are welcome additions that I am sure will help many teams improve their work processes.
Jimi Wikman
💫 Jimi Wikman