OpenProject Blog

OpenProject 17.3: Evolving agile with backlogs and sprints

2026-04-15T09:02:00+00:00

OpenProject 17.3 has been released and, as announced on our blog, introduces several improvements to agile project management, making it easier to plan and structure work with sprints, backlogs and boards.

In this article, we highlight the most important changes and what they mean for your daily work. And, as always, please see our release notes that contain all changes, features and bug fixes.

A quick article navigation:

Agile evolution with sprints and backlogs

Agile workflows have long been supported in OpenProject, but often required workarounds or manual setup. In our recent article on the future of agile work, we outlined how we want to further evolve these workflows and make them more intuitive and accessible.

With OpenProject 17.3, we are now taking the next step and bringing these improvements directly into the product, supporting both the planning and execution of agile work.

Important
If you are already working with the Backlogs module, you will notice changes to the layout and behavior with OpenProject 17.3. These updates are designed to simplify your workflow, while preserving your existing data and structure.

Dedicated sprint objects

If you have been working with agile methods in OpenProject, you may already be familiar with using versions as a way to structure your sprints. While this approach worked well, it required a certain level of adaptation and was not always intuitive, particularly for teams transitioning from other tools.

With OpenProject 17.3, we are introducing dedicated sprint objects as a natural way to plan and organize your work. Instead of relying on workarounds, sprints are now a core part of the Backlogs module and can be used directly to structure your work packages.

Each sprint comes with key attributes such as name, status, and dates, and work packages can be assigned to sprints in a straightforward way. This creates a clearer and more consistent structure for planning and executing agile work and makes it easier for teams to get started, including those migrating from tools like Jira.

All work packages visible on backlogs

When planning work in backlogs, teams often had to decide in advance which work package types should be included. This could lead to situations where not all relevant work was visible in one place, requiring additional configuration or workarounds.

With OpenProject 17.3, backlogs now display all work package types within a project by default. This means that teams can manage and prioritize all relevant work directly in the backlog and sprint planning view.

This change provides a more consistent and flexible way to organize work, especially for teams that use different work package types across their projects.

Automatic sprint board creation

Setting up a board for a new sprint often required manual configuration, even after the sprint had already been planned. This added extra steps before teams could start working and made it harder to ensure a consistent setup across projects.

With OpenProject 17.3, a dedicated sprint board is now created automatically when starting a sprint. The board is configured based on the project’s workflows and includes all work packages assigned to the sprint.

Teams are taken directly to the board after starting the sprint, allowing them to begin working immediately without additional setup and focus directly on executing their sprint.

Closing a sprint and handling remaining work

Completing a sprint and preparing for the next iteration often required manual adjustments, especially when dealing with unfinished work.

With OpenProject 17.3, active sprints can now be completed directly. When closing a sprint, you are guided to handle remaining work packages in bulk, for example, by moving them back to the backlog or assigning them to another sprint.

This makes it easier to move from one sprint to the next and keeps your workflow consistent without additional manual steps.

Action boards now available in the Community edition

Boards have always been a central part of agile workflows in OpenProject, helping teams to visualize and organize their work. With the mentioned improvements to sprints and backlogs in OpenProject 17.3, their role becomes even more important.

With this release, all Action board types are now available in the Community edition. This extends the existing basic board functionality and allows teams to use a wider range of board configurations, such as Kanban or parent-child boards, without requiring an Enterprise plan.

In the future, we plan to develop and offer additional advanced board features, such as swimlanes and work-in-progress limits, as Enterprise add-ons.

This step reflects our commitment to making powerful agile tools accessible to a broader audience, while continuing to evolve OpenProject based on the needs of our Community.

See our documentation to learn about OpenProject’s Agile boards.

Other great improvements with OpenProject 17.3

OpenProject 17.3 offers more features and updates. To keep this article concise, here is a quick look at some additional improvements worth highlighting:

Edit project attributes directly on the project overview page

Project attributes can now be edited directly in place on the project overview page, without opening a separate dialog. This makes it faster and easier to update project information.

Meeting templates, introduced in OpenProject 17.2, can now be shared across projects. Depending on the configuration, templates can be made available within a project, across subprojects, or throughout the entire instance.

Improved workflow configuration for admins

Workflow configuration has been improved with a new index view by type, a more focused display of relevant statuses, and a more reliable saving experience.

Nested groups for better user and permission management

Groups can now be nested, allowing memberships and permissions to be inherited across the group hierarchy. This also lays the foundation for future improvements in structuring groups in OpenProject.

Improved handling of project identifiers

Project identifiers can now be changed more easily without invalidating existing links. In addition, identifier handling has been improved when creating or copying projects.

Improved work package search across the application

Work package search has been extended to more areas of the application. When selecting work packages, it is now possible to search by attributes such as type and status.

OpenProject 17.3: Migration, installation, updates and support

Follow the upgrade guide for the packaged installation or Docker installation to update your OpenProject installation to OpenProject 17.3. We update your hosted OpenProject environments (Enterprise cloud) today, April 15, 2026.

You will find more information about all new features and changes in our Release notes and in the OpenProject Documentation.

If you need support, you can post your questions in the Community Forum, or if you are eligible for Enterprise support, please contact us and we will be happy to support you personally.

New to OpenProject? To test all features of OpenProject 17.3 right away, create a 14 days free trial instance for our OpenProject Enterprise cloud.
Prefer to run OpenProject 17.3 in your own infrastructure? Here you can find the Installation guidelines for OpenProject.
Want to upgrade from a Community version to try out the Enterprise add-ons? Get a 14 days free trial token to test the Enterprise add-ons (all plans).

Credits

A very special thank you goes to Helmholtz-Zentrum Berlin, City of Cologne, Deutsche Bahn and ZenDiS for sponsoring released or upcoming features. Your support, alongside the efforts of our amazing Community, helps drive these innovations. Also a big thanks to our Community members for reporting bugs and helping us identify and provide fixes. Special thanks for reporting and finding bugs go to Walid Ibrahim, Jörg Mollowitz, Robin Kluth, Natalie Stettner, Gábor Alexovics, Patrick Lenk, and Daniel Elkeles.

Last but not least, we are very grateful for our very engaged translation contributors on Crowdin, who translated quite a few OpenProject strings! This release we would like to particularly thank the following users:

Phi Công Nguyễn Vũ, for an outstanding number of translations into Vietnamese.
Mehmet Coşkun, for a great number of translations into Turkish.
Liangzdz, for a great number of translations into Chinese Simplified.

Would you like to help out with translations yourself? Then take a look at our translation guide and find out exactly how you can contribute. It is very much appreciated!

As always, we welcome any feedback on this release.

How to use status transitions and workflows in OpenProject

2026-04-15T06:09:00+00:00

OpenProject is a powerful tool, but with great power comes the complexity of customization. If you’re new to OpenProject and having trouble setting up statuses for workflows, you’re not alone. Once you understand how status transitions work in OpenProject and how they depend on roles and work package types, you’ll appreciate their full potential.

Read this article to learn…

what statuses, roles and workflows are and how they work together,
why your project management will be much more powerful and efficient with custom workflows,
how to add a new status and set up a workflow for it.

Let’s dive in!

Note
April 2026: This article has been updated to reflect the latest improvements in workflow configuration in OpenProject.

Know your terms: Status, role and workflow

Let’s start with some terminology. You will be much faster to create your very own workflows with OpenProject, if you speak its language. So, what are statuses, roles and workflows? And how do they come together?

What is a status in OpenProject?

The status is a key element in every project management. In OpenProject, the status is also an essential attribute of a work package. Based on the status, everyone knows immediately how far the respective work package has progressed.

By default, statuses such as New, In progress or Closed are activated in OpenProject. However, depending on the type of work package, other statuses may be useful. For example, a work package of the type Feature needs the status In test, a work package of the type Blog post rather needs the status In review.

See our system admin guide to learn more about status management for OpenProject.

What are roles in OpenProject?

Roles in OpenProject are extremely important in order to provide each person with exactly the permissions they need - no more, no less. In addition to default roles, administrators can create their own roles and assign them fine-grained permissions.

In addition to permissions for features or project views, admins can also assign specific permissions for status changes in OpenProject roles. Exactly these settings then define a workflow in OpenProject – which we will take a closer look at in the next section.

What is a workflow in OpenProject?

Let’s get back to our example from above: Firstly, we have the status In test, which should be selectable by default for features. Then we have the In review status, which should not be selectable for features, but for work packages of the blog post type.

Now let’s take it a step further and look at the roles and permissions: Let’s say, Luke is a developer and regularly works on features. However, he is not authorized to test features - there is a separate QA team for this. Now it’s suddenly no longer enough to just assign a set of statuses to the work package type Feature, we also need different permissions to activate a status, depending on the role.

This is where workflows come into play. In OpenProject, a workflow defines which status changes are allowed depending on the role and the work package type. In other words: It is not only important what type of work package you are working on, but also who you are. For example, a developer might be allowed to move a work package from In development to Needs testing, while a QA team member can move it from Needs testing to In testing.

With workflows, administrators can control exactly which role is allowed to set which status for which work package.

Note
Status changes for workflows are configured on a global level via the administration panel: Administration → Work packages → Workflows.

This flexibility is what makes workflows in OpenProject so powerful — but also more complex at first. Instead of having a fixed process, workflows adapt to your roles and work package types, allowing you to model real-life responsibilities in your projects.

The power of customization: Simplify the work for project members

As an administrator, you have the power of defining specific workflows for each role so that project members can perform exactly the status changes they need. The more you customize as an admin at the top, the easier the work becomes for other roles further down in the project.

And remember: You only have to configure these settings once for them to work for years. So grab a coffee and block out a morning to take a closer look at status transitions in OpenProject. Your colleagues and your future work will benefit greatly!

Here’s an example of a typical work setting where status transitions with workflows will be much appreciated:

Let’s take Luke, the developer, from the example above. Now his admin Ivan wants Luke to be able to set work packages of the type Feature from New to In development and then to Needs testing. However, while Luke’s QA colleague Maya should be able to change work package statuses of the type Feature from Needs testing to In testing, this should not be possible for Luke. A role-based permission setting like this allows both the developer Luke and Maya from QA to do their jobs while preventing them from accidentally setting a status for which they have no permission.

This is how the example workflow for the role Developer and the type Feature would look like in OpenProject:

Step-by-step guide: How to add a new status and set up a workflow

Finally, let’s go through the entire process step by step: What settings does admin Ivan need to configure to define the workflows for the work package type Feature – so that each role can perform exactly the status transitions they need to do their job?

Step 1: Create the roles, the status and the work package type you need

If you are specifically looking to create a workflow, you might already have set up the roles, the status and the work package types you need. For our example, admin Ivan would first have to create a work package type called Feature under: Administration → Work packages → Types → New type.

Then he would have to make sure the statuses we described above exist (e.g. Needs testing) – and create new ones, if needed.

He would also have to set up two roles - Developer and QA. This setting can be found under Administration → Users and permissions → Roles and permissions → New role.

Tip
To save some time when creating a new role, we advise you to copy an existing workflow. Please make sure that the new role has the right to change a work package status (or edit work packages, which includes changing the status). You can also copy an existing workflow between roles. For example, you could copy the workflow from the role Developer for the type Feature to the role QA and then adjust only the transitions related to testing.

Step 2: Create and configure the workflow

Now that we have created the roles and the work package type that we want to customize, we can start creating a new workflow under Administration → Work packages → Workflows. For our example, Ivan would have to choose the type Feature.

Next, Ivan needs to select Developer from the dropdown of available roles. He now either sees the statuses that were set for this role in the past. Or, if it’s a completely new role, no status transitons are configured yet, and he can configure them by clicking the + Status button.

Once all required statuses are selected, you’ll see a table with the current status in the rows and the new statuses in the columns.

Please note that all statuses appear twice in the table: the rows show the current status, and the columns show the new status. If the cell at the intersection is checked, the transition is allowed. So, if you want the role to be able to change statuses in both directions, e.g. from New to In progress and also from In progress to New, you have to check the corresponding cells in both directions.

In our example, Ivan wants to make sure that a person with the role Developer cannot set or change a status from or to anything related to testing. If Ivan now unchecks every box that is related to testing, the screen would look like this:

The table shows status transitions enabled or disabled for developers (role) on work packages of the type Feature. As testing features should only be done by QA, these statuses are disabled in the screenshot.

Tip
OpenProject allows admins to define different status transitions depending on whether the user is the author or assignee of the work package. These options can be configured using the tabs at the top of the workflow view and allow you to define more flexible or stricter workflows depending on the situation.

Now, don’t forget to click Save and your workflow is ready!

Tip
You can also use the Summary view to get an overview of all configured status transitions across roles and types.

Wrapping up: More information on how to set up and customize your OpenProject

You have now learned what status, role and workflow mean in OpenProject and how to set up status transitions to support your project and task management. Here’s a quick overview of the tips in this article:

Before creating a workflow, make sure you have the needed role, status and work package type.
When creating a new role, copy an existing workflow to save time.

More information on how to set up your OpenProject instance can be found in the system admin guide – on this page you will find a guide to create custom workflows.

OpenProject is an open source project management tool with a wide range of features and a powerful set of customization options. It offers you the tool to create a custom project management just as you need it. And once it’s set up, working with status transitions and other custom features and actions will be fun because it will work easily and be crowned with success.

Agile updates in OpenProject 17.3

2026-04-13T19:10:00+00:00

With the upcoming release of OpenProject 17.3, we are introducing a major upgrade to the Backlog module – thoughtfully designed to make your agile workflows smoother, more intuitive, and more powerful than ever.

We know that change can sometimes feel overwhelming, so we want to walk you through everything ahead of time, explain the reasoning behind each decision, and make sure you feel fully prepared and confident when 17.3 lands.

Here is what is coming with 17.3:

A fresh new look

The Backlogs module is getting a visual refresh. The new design is cleaner and built to help you focus on what matters most – delivering great work.

A smarter layout for agile teams

We have reorganized the layout so that the Backlog now appears on the left and your Sprints on the right. This mirrors the natural flow of agile practices – from backlog refinement on the left to sprint planning on the right – making the process feel more intuitive for your team.

We understand that this flip in layout might take a moment to get used to, especially if you have been working with the different arrangement for a while. In future releases both sections will become fully resizable, so you can adjust the split to suit your preferences. We are also planning multi-select dropdowns so you can zoom in on a specific sprint at a glance – more flexibility is on the way!

Your backlog, automatically populated

No more manually adding work packages to the backlog one by one. In 17.3, your backlog will automatically be populated based on the work packages in your project. You can easily prioritize by placing the most important items at the top – and with just two clicks via the new context menu, you can move anything straight to the top of the backlog. We are also planning backlog buckets and advanced filters in a future version to give you even more ways to organize and structure your work.

What about your existing backlog and sprint buckets?

Your existing buckets are not going anywhere – we will automatically migrate all of them as part of the 17.3 update, so nothing will be lost. Here is what to expect: in 17.3, both your previous backlog buckets and sprint buckets will be visible together on the right-hand side of the new layout. Please think of it as a transitional step – all your existing structure is preserved and fully accessible. Looking ahead to 17.4, we are planning to introduce dedicated backlog buckets on the left-hand side, giving you the ability to sort and organize your backlog with even greater flexibility.

In the meantime, your buckets will be neatly sorted so they are easy to navigate: buckets with start and end dates are sorted chronologically with the most recent ones appearing at the top, while buckets without dates are sorted alphanumerically.

Automated sprint boards

Starting from 17.3, you will have the possibility to start and complete a sprint. Starting a sprint is now even more powerful. When you kick off a sprint, OpenProject will automatically generate a dedicated sprint board – replacing the previous task board. This board gives you a precise view of your sprint scope and lets you filter by any work package attribute, so your team always has exactly the information they need, right at their fingertips.

There will be many new features coming to the boards soon and in case you are interested in learning more about it, please check out our blog article presenting the future of agile way of working in OpenProject.

A smooth sprint completion flow

Wrapping up a sprint is now just a click away. Hit the “Complete Sprint” button when you are ready, and OpenProject will guide you through moving any remaining work packages - automatically - to the next sprint or back to the backlog. No loose ends, no manual cleanup.

What should you do to prepare?

Nothing special is required from your side before the update. We recommend taking a few minutes to familiarize yourself with the new layout description above – especially the new positioning of the Backlog and Sprint panels – so the first time you open the module after the update, it already feels familiar.

We will also be providing updated documentation as part of the 17.3 release to support you every step of the way.

What is coming in future?

We are genuinely excited about these improvements and believe they will make a real difference for agile teams using OpenProject. This is just the beginning. Further improvements will be released every month. If you would like to understand where we are heading, please take a look at our agile product vision or at our detailed roadmap.

As always, your feedback is important to us. If you have questions or thoughts, do not hesitate to contact us to share your feedback and experience.

Thank you for being part of the OpenProject Community. The best is yet to come!

Your Jira exit solution: The OpenProject Jira Migrator

2026-03-27T07:08:00+00:00

Caution
Atlassian has announced that Jira Data Center will reach end of life on March 28, 2029. After this date, Data Center licenses and apps will expire and become read-only, leaving cloud hosting as the only supported option.

Teams around the world are looking for alternatives to Jira, whether due to changing project requirements, a preference for open source solutions or rising costs. However, switching tools is often easier said than done – especially if a seamless migration solution is not readily available. We at OpenProject are currently developing a Jira migration tool to meet this need. With version 17.2 in February 2026, it has been released under feature flag – meaning it is in its final testing phase and soon to be released to our users.

The challenge: Migrating from Jira to OpenProject

For many teams, Jira has long been the project management tool of choice. In many cases, simply out of habit and a lack of time to start over. Especially since Atlassian continues to raise prices and “lock-in” users into their cloud offering, more and more organizations are rethinking their options and looking for cost-effective open source alternatives that are trustworthy and feature-rich.

However, switching from Jira to OpenProject presents challenges:

Time constraints – teams often don’t have the resources to manually migrate their projects.
Technical complexity – a migration tool must be able to handle issues, work logs and custom fields.
Lack of ready-made solutions – until now, there was no specific importer tool that guides the user through a migration process.

The solution: The Jira Migrator, official migration wizard from OpenProject

In current beta version, the Jira Migrator is able to import the following basic data:

Projects
Issues (name, title, description, attachments)
Users (name, email, project membership)
Statuses
Types

With upcoming releases, we aim to also include importing:

Workflows
Custom fields
Issue relations
Permissions

Currently, we only support Jira Server/Data Center versions 10.x and 11.x. Cloud instances are not supported at this time.

See our documentation to learn how to experiment with the Jira Migrator in beta version. You might also take a look at our best practices for Jira migrations.

Warning
Please be aware that right now (March 2026), this feature is still under active development. We know that many users are eagerly awaiting the release, and we are working hard to provide a high-quality migration tool soon.

Watch this video to learn how the OpenProject Jira Migrator will support teams in their Jira exit:

Your browser does not support the video tag.

We at OpenProject want to help finding migration solutions

At OpenProject, we want to support solutions that make migration easier. Many teams want to make the switch but don’t have the time or technical skills to do so. Which is why, in the past months, the OpenProject core team was quite busy working on a Jira Migrator.

To support the development of the official migration tool, we are collecting anonymized data samples. This data helps test and validate import capabilities across different Jira and Confluence configurations. Please reach out to us if you want to donate your data, we will sign an NDA to ensure confidentiality.

OpenProject Enterprise plans: Community vs Enterprise edition explained

2026-03-26T15:32:00+00:00

OpenProject offers both a powerful Community edition and Enterprise plans tailored to different organizational needs. This often raises the question of which option is the best choice for your team or organization. While the Community edition is fully functional on its own, some teams require professional support, specific Enterprise add-ons, or Cloud hosting.

In this article, you will learn about the differences between Community and Enterprise, and how to easily upgrade or get started with an Enterprise plan.

Quick navigation:

Why does OpenProject offer an Enterprise edition?

Since OpenProject is free (as defined by the Free Software Foundation) and open source software, you can download and run the software on your own infrastructure. It can be used free of charge in the Community edition. This edition is a fully functional project and task management solution and is used by teams and organizations of all sizes.

At the same time, some organizations rely on personal, reliable support when running OpenProject in business-critical or complex environments. Providing this kind of professional support requires dedicated resources and clear responsibilities. The Enterprise edition exists to offer exactly that, while ensuring that OpenProject remains sustainable and fully open source for everyone.

What is the difference between the Community edition and the Enterprise edition?

The OpenProject Community edition is free to use, fully open source, and provides a comprehensive set of project and task management features. It can be used without restrictions on the number of users or projects and is suitable for many teams and organizations as it is.

The Enterprise edition builds on the Community edition. It adds professional support and optional Enterprise add-ons for organizations with higher or more specific requirements, for example when OpenProject is used in business-critical environments or when additional services are needed. The Enterprise edition does not replace the Community edition, but extends it.

In short, the difference is not about access to the software itself. Both editions are fully open source and highly functional. The key difference lies in professional support, Enterprise add-ons, and additional service options.

	Community edition	Enterprise edition
License	Open source	Open source
Costs	Free of charge	Paid plans
Core functionality	Fully available	Fully available
Enterprise add-ons	Not included	Available
Professional support	Community-based	Included
Hosting options	Self-managed	Self-managed or hosted by OpenProject
Typical use cases	Teams with basic project and task management requirements	Organizations that need professional support or have specific requirements

Important
Support is the essence of OpenProject Enterprise: It is important to know that while the OpenProject Community edition is free and fully functional, it does not include personal support. Upgrade to get reliable, high-touch support from OpenProject senior support engineers with expert knowledge about running the software in business-critical environments. We are English, German, and French speaking!

What are Enterprise add-ons?

Enterprise add-ons are optional extensions that build on top of the OpenProject Community edition. They are designed to support more advanced or specific requirements that go beyond basic project and task management needs.

All Enterprise add-ons are developed as open source software. They are not a separate product, but integrate seamlessly into OpenProject and can be enabled as part of an Enterprise plan. Importantly, the Community edition remains fully functional without these add-ons.

Enterprise add-ons are therefore best understood as complementary enhancements. They allow organizations to extend OpenProject where needed, without changing the core principles of openness, transparency, and long-term maintainability. Still, the main benefit of the OpenProject Enterprise edition is the professional support.

Watch this video to learn about our current Enterprise add-ons:

Your browser does not support the video tag.

Community first

OpenProject values a balance between community spirit and financial sustainability, which is a key element in OpenProject’s high user-friendliness and, for example, its comprehensive documentation, available free of charge to all users. One example of OpenProject’s commitment to the Community is that some Enterprise add-ons are released for the community edition over time.

As an example, here’s a list of Enterprise add-ons that have been released to the Community edition in the past:

Why does OpenProject offer different Enterprise plans?

Organizations using OpenProject vary widely in size, structure, and requirements. Some mainly need professional support to operate OpenProject reliably, while others require specific Enterprise add-ons, additional services, or long-term guarantees for complex or regulated environments.

To address these different needs, OpenProject offers multiple Enterprise plans. This makes it possible to keep entry prices low for organizations that primarily need support, while also offering plans tailored to larger organizations with more specific or demanding requirements. The goal is not to bundle everything into a single plan, but to provide appropriate options for different use cases. Enterprise plans therefore reflect a fair and flexible approach: organizations only pay for the level of support and add-ons they actually need.

The introduction of different Enterprise plans is documented in the OpenProject 16.0 release notes.

Important
All OpenProject editions are fully built on GPLv3-licensed free and open source software and OpenProject is not an open core model. Enterprise plans are paid because they include professional support and services, not because the software itself is closed or proprietary.

How can you upgrade from the Community edition to OpenProject Enterprise?

Upgrading from the OpenProject Community edition to an Enterprise plan is straightforward and does not require a migration or a new installation. Your existing data, projects, and configurations remain unchanged.

Enterprise plans can be evaluated via a trial that activates the Enterprise add-ons and professional support for a limited time. If the trial ends without a subscription, the installation automatically returns to the Community edition.

This makes it easy to explore OpenProject Enterprise at your own pace and decide whether professional support or specific Enterprise add-ons are the right fit for your organization. Learn more about upgrading to Enterprise edition.

How can you get started with OpenProject Enterprise?

If you want to explore OpenProject Enterprise in more detail, there are several ways to get started. You can review the available Enterprise plans to understand which options best fit your organization’s needs, including professional support and optional Enterprise add-ons.

If you are already using the Community edition, you can start an Enterprise trial directly from your installation to evaluate the Enterprise add-ons and support in your own environment. Organizations that are new to OpenProject can also choose an Enterprise plan from the start, including hosted options.

If you have questions or specific requirements, the OpenProject team is available to help you find the right setup and plan for your organization.

News from the Product Desk: The future of agile work in OpenProject

2026-03-23T08:42:00+00:00

At OpenProject - the open source project management platform trusted by thousands of teams worldwide - we are making a clear statement: we want to be your sovereign go-to solution for agile teams. We are excited to give you an outlook on what is coming in 2026, in order to further improve agile ways of working within OpenProject.

Co-creation with our Community

We have been exploring, through many interviews with our current and future users - how the backlog refinement and sprint planning experience in OpenProject could evolve to better support agile collaboration. We also analyzed the pain points Jira users experience when working in agile teams. This helped us better understand your needs. We used those insights to provide first prototypes of redesigned backlogs and boards, which were then tested with users. Within an open source project software like OpenProject, you have the possibility to shape the product together with us. This is also why we are releasing our prototypes within this blog post and looking forward to your feedback.

The goal of the new concept is to make backlog refinement, sprint planning and usage of agile boards more intuitive, structured, and scalable for growing teams and enterprises, especially for teams migrating from Jira to OpenProject, who are working with Scrum, Kanban or SAFe. By improving how backlog items are organized and how teams interact with their sprint planning view, we aim to create a smoother and more flexible agile experience in OpenProject. Let’s take a closer look at how these ideas could support teams during agile ceremonies.

Automated backlog

At the beginning of April 2026, we plan to release the first iteration of our redesigned Backlog module. You will then automatically see all work packages from your project within the backlog without the need of adding them manually to the backlog. In case you don’t want certain work package types to be automatically visible in the backlog you will later on get a possibility to exclude them from the automated backlog.

Structuring large backlogs with backlog buckets

Have you ever struggled with structuring a backlog with hundreds of work packages? We have a solution for you! The updated backlog design will introduce clearer ways to organize backlog items using backlog buckets. You can use buckets to sort your work packages in a way which will help you keep an overview over the backlog and your team’s priorities. You just create buckets which are relevant to you and you easily drag & drop the work packages to newly created buckets. With this improvement, you can easily sort e.g. your “Low hanging fruits”, “Priority bugs” or work packages which are “Ready for development”.

Fast lane for moving work packages

We are also planning to implement improved ordering mechanisms for work packages (move up, move to top, move down, move to bottom, or move to sprint). With one click, you will be able to easily move your to-do’s to a relevant bucket or sprint. Less scrolling back and forth. This makes it faster to manage large backlogs and keep priorities where they belong.

Backlog filters and saved views

Of course you will also have a possibility to filter your backlog based on all attributes, incl. custom fields. In case you would like to re-use a certain view in future, you will be able to save it as a public or private view. This will allow you to quickly navigate to the set of work packages that is relevant to you and where you would like to zoom in.

Sprint planning

With the backlog view on the left and sprints on the right, you you can see your sprints and backlogs on one screen without scrolling. This view will boost your productivity during sprint planning. The improved layout makes it easier to see what work is ready to be pulled into the next iteration.

At a glance, key information about each backlog work package is visible:

Name
ID
Type
Status
Assignee
Number of story points
Priority

You will have the possibility to not only define the sprint scope but to also highlight the sprint goal in order to align your team, as well as to set sprint dates.

Active sprints and sprint boards

Once you’ve started your sprint, you will automatically get a sprint board, showing you the planned sprint scope. This is your team’s go-to place during the sprint. With this overview, you will always see who is working on which topic and how the team is making progress.

Multiple active sprints within one project

Do you have various teams working within one project? Do they want to start separate sprints in parallel? No problem! OpenProject will allow admins to define if a project should be a single-sprint or multi-sprint project. This brings more clarity to your teams and their sprints, at the same time allowing them to work within the same backlog.

Board filters and saved views

Once the sprint begins, teams rely on boards to manage their day-to-day work. The new concepts explores how sprint boards could provide a clearer way to track progress. With introduced filters, you will be able to adjust the board view to your needs. You can filter for any kind of attributes, incl. custom fields. In case you would like to re-use some of the filter sets, you can always save the view as a private or public view.

Configurable work package cards

The redesigned board behavior is intended to make daily work management more intuitive. Clearly structured work items and the board layout help teams stay focused on progress and flow while reducing visual clutter. With the configure board view, teams could adjust the card size and choose which information should be displayed on each card. The design illustrates three levels of card configuration: compact, regular, and full; giving users flexibility in how much information is displayed.

Status mapping for complex workflows

The concept will also introduce the ability to map multiple workflow statuses to a single column, giving teams more flexibility in how they visualize their workflow. This will be a booster for teams working with complex workflows.

Work in progress limits

Would you like your team to deliver faster? Focusing on the most important topics and reducing work in progress is an essential productivity booster for agile teams. OpenProject will support you on this path through work-in-progress limits which can be set for each column individually.

Swimlanes

Users will get a possibility to enable swimlanes and configure them based on attributes such as parent work item (e.g. epic), assignee, version, component, priority, or type, allowing teams to organize work in a way that best supports their workflow. Swimlanes will provide your team with a very structured board view.

Agile reports

To support monitoring and improvement, teams can also access reports designed to help track, analyze, and optimize performance during and after a sprint. These will be very helpful during retrospectives. We are planning multiple reports and graphs:

Especially within enterprises, when working based on SAFe principles, most teams should be aligned on sprint start and end dates. Already within our first agile release (currently planned for April 2026), we will allow users to share sprints through the whole instance or within a certain portfolio or program. This means that teams working with shared sprints will share the sprint dates and goal, but still can define their own sprint scope relevant for the team. Under the administration settings, sharing sprints across projects can be enabled or disabled. Projects can also be configured to only receive shared sprints.

Versions and sprints

Soon, you will be able to associate work packages with versions and sprints at the same time. An epic then can be planned for a release using the version field and can be planned for a certain sprint at the same time. In Q2 2026, we are also going to introduce an additional version field, “Observed in versions”, which — in addition to the version that defines the release version — allows you to track the versions in which a bug occurred.

Kanban boards

In case you prefer to work using Kanban methodology, you will of course have a possibility to create Kanban boards, also multi-project Kanban boards, including all the new functionalities described in the article, like swimlanes, work-in-progress limits, filters, saved views. etc.

Global Backlog module for SAFe organizations

The planned global Backlog module will help enterprises to manage big agile portfolios. Especially for SAFe organizations, this might be the go-to place for navigation between sprints and board. Among others, you will also have a possibility to filter for the PI (Product Increment) scope or for all dependencies across the whole portfolio.

And all that is coming to OpenProject in 2026!

These concepts are all part of our ongoing design exploration to improve agile workflows in OpenProject. While not all elements are part of the product yet, they represent the direction we are exploring to better support teams working with Scrum, Kanban or SAFe.

We’re continuing to refine these ideas and look forward to sharing future updates as the designs evolve. In case you would like to provide your feedback on those prototypes, please feel free to comment on the work packages within our roadmap. We would love to hear from you!

Stay tuned for our future agile releases!