Knowledge, skills, innovation - your guide through the complex world of software development.

Why automated tests are the The future belongs to

8 tips for implementing Continuous Testing

  • Decide from service to service which tests make sense and are sufficient for them to be integrated in the deployment process.
  • Carry out automatic tests after each possible step (in each deployment stage).
  • Do not carry out all existing tests in each deployment process of each service.
  • Try to reduce end-to-end testing or exclude it from ancillary processes.
  • Motivate and teach others to develop and integrate automated tests to distribute the understanding and knowledge (think like a¬†DevOps).
  • Only expand your end-to-end testing where necessary and maintain these tests with the objective that they are stable, reliable and robust.
  • Concentrate on the essential:
    • The supreme objective is the clean deployment of the services.
    • Integrated tests should provide support here, but not be the focus.
  • Share and discuss your experiences, problems and solutions on continuous testing with others.

Finding and defining good metrics in the DevOps environment


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, Portfolio for Jira AddOns

Atlassian Jira, Portfolio for Jira, AddOns

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.


Multi-project management with Atlassian Jira without further add-ons

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.

Documentation on agile Jira boards

Jira - Multi-project Scrum backlog © 2018 Atlassian

Fig. 1: Multi-project Scrum backlog with cross-team epic „enhanced entertainment“ and stories from different projects (projects PJA and PJB)


Jira - Multi-project Scrum board © 2018 Atlassian

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.


Jira - Filter with results list © 2018 Atlassian

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.


Exchange with tools outside of Jira

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.


Portfolio for Jira, Logo © 2018 Atlassian


Portfolio for Jira description

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.


Portfolio for Jira story plan © 2018 Atlassian

 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:


Portfolio for Jira epic plan © 2018 Atlassian

 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.

Cross-project features

  • Up-to-date overview of several teams and projects
    • Always automatically up-to-date with Jira data
    • Multi-project planning of releases
      • For agile and traditional approaches
      • Simple, multi-project or portfolio prioritisation
      • Planning can be specified for Jira teams (but does not have to be)
    • Forecasts regarding whether or when a release date will be met
    • Tracking of progress, also for joint release dates

  • Multi-project resource planning
    • Allocation of resources according to knowledge and workload of employees
    • Scenarios allow „if, then…“ alternatives


Portfolio for Jira - Composition of a team © 2018 Atlassian

Fig. 6: Composition of a team according to skills and capacities   


Project-specific features

  • Improved coordination with other teams
    • Joint planning of releases is possible
    • Multi-project dependencies can be automatically taken into account during planning
  • Multiple Scrum teams can be planned and coordinated better
    • Easier distribution of stories to the teams
      • Based on team capacities
      • Cased on team specialisations
    • Cross-team tracking of progress
  • Forecasts regarding whether and when a release date will be met
  • Scenarios allow „if, then…“ alternatives


Our practical evaluation of Portfolio for Jira

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.


Further Jira add-ons 

Portfolio Toolkit

Manufacturer: Teamlead
Adds some additional features to Portfolio for Jira


Structure for Jira

Manufacturer: ALM Works
Own hierarchical structuring of Jira processes, multi-project view



Manufacturer: SoftwarePlant
Gantt chart planning with dependencies and some portfolio functions. Similar to a traditional project management tool, but also takes agile procedures into consideration.



Manufacturer: SoftwarePlant
Project portfolio management, resource management, risk management with Gantt charts.

Agilefant Business Execution for Jira

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.

Enforce with confidence

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“.

Free application Health Check

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:

  1. Software Bill of Materials
  2. Review your OSS policy
  3. Restriction of technical / security debt
  4. Search for recently published security vulnerabilities
  5. Compliance with regulatory or industry guidelines
  6. Quality checks of outsourced developments

Reach us

ASERVO Software GmbH 

Konrad-Zuse-Platz 8

81829 M√ľnchen Germany

Tel: +49 89 7167182 – 40

Fax: +49 89 7167182 – 55


Social Media

Copyright © 2023. ASERVO SOFTWARE GMBH

Cookie Consent mit Real Cookie Banner Skip to content