SLAs should be agreed between the operator and the user prior to each commissioning of a service to ensure there are no misunderstandings later one due to completely different expectations.
KPIs are indicators that generally require a closer look when changed. They are only poorly suited 1:1 for measuring quality, usually the difference at a previous point in time is the better approach. They should be re-evaluated and revised regularly.
There are different types of KPIs, depending on the point of view; and each of these points of view has its justification. There is often the danger of getting too involved with the purely technical measured variables. However, experience has shown that it is the application and process KPIs that provide the most insight, even though their determination involves more effort. The technical KPIs, on the other hand, are more of a help when it comes to the diagnosis and removal of weaknesses.
Atlassian Jira probably has the highest market share among the project management tools used by companies and organisations that develop software. However, the use of the tool goes far beyond software development projects, as it is also used to manage projects that have nothing to do with software. The tool often represents the hub of daily work organisation and is therefore enormously important. Lke most project management tools, Atlassian Jira is optimised for individual projects. However, tasks of different teams often depend on one another.
The software organises the management of tasks into so-called projects, no matter whether this relates to real projects or just a summary of the work of a team. Like most project management tools, usage has been optimised for planning and managing individual projects.
In the everyday life of software development, however, projects or teams do not usually work in isolation, and this is something our ASERVO consultants experience time and again when visiting customers. Often, tasks of different teams depend on one another, or they even work together on a common product or result within the scope of a product portfolio. For example, one software component per team could be processed, which is used in a car, along with other software components, and also communicates with them. What’s more, there may be joint release dates that make multi-project or portfolio planning necessary. Also at the level of resource planning, when it comes to the number and competencies of available employees, multi-project planning is absolutely necessary in order to take their total workloads into account within the overall planning.
The information below provides details about the options that Atlassian Jira offers, both as stand-alone options, and with add-ons for multi-project management.
The reconciliation of tasks between projects on an oral basis, e.g. in regular cross-team meetings, is part of the recommended, natural way and procedure for everyday work. This tool also offers some interesting possibilities for the multi-project management of tasks as a stand-alone extension.
Multi-project or portfolio Jira boards
With Scrum boards (see Fig. 1 and Fig. 2) or Kanban boards from Jira Software, you have the possibility to follow and change processing on a graphical level. The number of tasks displayed on this board can be freely defined via a query. These can also relate to several projects, as shown in Fig. 1 or Fig. 2 (projects PJA and PJB). This allows you to easily obtain a multi-project or portfolio perspective of the processing of tasks.
Fig. 1: Multi-project Scrum backlog with cross-team epic „enhanced entertainment“ and stories from different projects (projects PJA and PJB)
Fig. 2: Multi-project Scrum board with stories from different projects (projects PJA and PJB)
It is also possible to define cross-project evaluations – so-called filters – in order to obtain a list of tasks.
Besides the direct use of the list in the tool, as shown in Fig. 3, it can also be exported to a CSV file. Furthermore, the list can be used to define the tasks that are to be used in a report or other graphical evaluation.
Fig. 3: Filter with results list across 3 projects (projects POM, PJA, PJB)
Without additional add-ons, it is already possible to track the status of processing across multiple projects. However, it is practically impossible to plan tasks or resources in advance across projects. There are also some restrictions. This means that cross-project release versions are not possible. This requires additional tools, either outside of Jira or by using add-ons.
Without any direct integration, data exchange with external tools usually takes place via the export and import of CSV files. The desired number of tasks and fields can be defined using filters. But be careful! If you want to perform a re-import in order to update existing tasks, this is only possible via the CSV import function in the Administrator menu. It’s also worthwhile saving the CSV import settings (especially the mapping of the fields) in a file so they can be used again.
The simplest case of using an external tool would be further processing with MS Excel. However, the exchange of data does not take place immediately with every change, but only through an export. This means there is no guarantee that the tasks in the external tool are up-to-date at all times.
In our experience, this procedure is hardly practical, and data exchanges will take place less and less due to the effort involved, which means it will not be up-to-date or reliable. Exceptions here are simple evaluations via an export to MS Excel and then further processing. It should be noted that estimates exported to MS Excel, which Jira displays in days or hours are then shown in seconds.
A Jira add-on called „Portfolio for Jira“ is available for Atlassian for multi-project or portfolio planning and progress tracking. Portfolio for Jira has been especially designed for agile approaches, and the current Jira data is always used automatically. Changes can easily be tried out in Portfolio itself until they are specifically written back in Jira.
The add-on offers its own cross-project and cross-team view, also with graphical representation. This overview can be done on different hierarchical levels as shown in Fig. 4 for stories and in Fig. 5 for epics. The graphical planning includes project releases such as „PJA V1“ and cross-project releases such as „Common Release 1“ (cross-project releases are only possible with Portfolio for Jira!). In the example, all Portfolio for Jira stories were automatically assigned to „Common Release 1“, because the calculation showed that they could all be processed by the fixed release date.
Fig. 4: Portfolio for Jira story plan for three projects (projects POM, PJA, PJB)
POM events are not shown in this story view because POM only has epics. There is however also an individual epic view:
Fig. 5: Portfolio for Jira epic plan for three projects (projects POM, PJA, PJB)
The features of Portfolio for Jira can be used above all on a cross-project level for multi-project or portfolio management, but they also be used by project managers and requirements managers when working on or under projects, as shown below.
Fig. 6: Composition of a team according to skills and capacities
In practice, we see the strengths of the add-on in the extensive expansion of multi-project or portfolio planning (including resource planning) possibilities offered here, and the direct integration and optimal data synchronisation with Jira. From our point of view, the graphical representation of the planning and handling of comprehensive releases also deserves some extra plus points.
On the other hand, we view the insufficiently developed options, adjustments and own design possibilities as a limitation. For example, it is not possible to insert your own calculations, and graphics can only be influenced to a limited extent. Although there is an official API for own extensions, Portfolio for Jira cannot (yet) keep up with the market-leading tools for planning a portfolio.
Adds some additional features to Portfolio for Jira
Manufacturer: ALM Works
Own hierarchical structuring of Jira processes, multi-project view
Gantt chart planning with dependencies and some portfolio functions. Similar to a traditional project management tool, but also takes agile procedures into consideration.
Project portfolio management, resource management, risk management with Gantt charts.
Manufacturer: Agilefant Ltd
Links high level initiatives with Jira epics and tasks. Allows you to plan and track progress from a business perspective.
As an independent version, Atlassian Jira already offers initial possibilities for multi-project or portfolio management, but it is by no means sufficient on its own. The required extensions are provided via add-ons like Portfolio for Jira, in particular, which work optimally with Jira processes, teams and releases. However, in most cases they do not offer the functions provided by independent tools for multi-project or portfolio management. In individual cases, the decisive factor is whether integration or the range of functions is most important.
When it comes to using open source components to manufacture modern software, the bottom line is this – precise intelligence is critical. Tools that lack precision cannot scale to the needs of modern software development. Inaccurate and/or incomplete data will leave organizations to deal with vulnerabilities, licensing, and other quality issues that lead directly to higher costs and reduced innovation.
Learn about Advanced Binary Fingerprinting and why precision matters in data intelligence in Sonatype’s white paper: „Enforce Open Source policies with confidence“.
Find out more about the applications you use. With a free Application Health Check, Sonatype offers the option of having your stock of open source and proprietary components recorded in a parts list. Why don’t you scan one of your applications – the results might surprise you.
6 reasons for the Application Health Check:
ASERVO Software GmbH
81829 München Germany
Tel: +49 89 7167182 – 40
Fax: +49 89 7167182 – 55
Copyright © 2023. ASERVO SOFTWARE GMBH