OpenProject agile boards and Scrum backlogs

Scrum sprints, Kanban boards and the Gantt chart in OpenProject do not keep separate copies of a task. They read from the same work packages, so a start date, due date, assignee or status set in one view appears in the others. That shared model is the main reason to run sprint delivery and dependency-based scheduling in one project, and it is also the main source of friction. Before a team rolls the setup out, it needs to agree which fields are authoritative and who is allowed to change them.

The trade-off comes from asking one project to serve two planning rhythms. A Scrum team plans in sprints and re-plans every iteration, so it changes assignees, versions and statuses often and cares little about exact dates beyond the sprint window. A Gantt view depends on dates and relations between work packages, so a small date change on an upstream task can move a chain of dependent tasks. When a sprint planner drags a card into the next sprint, the schedule view may shift as well. Teams should decide whether sprint assignment or the schedule owns the date fields, and document the rule where the team will see it.

A practical agreement covers three questions. First, which fields the product owner or scrum master may change during a sprint, and which only the project manager may change, such as finish dates on milestones or relations that cross phases. Second, whether story points or estimates drive the plan, or whether the Gantt dates are the commitment and points are only for velocity. Third, how the team handles work that leaves a sprint unfinished, since its dates in the Gantt view may still reflect the original plan. Confirm how the relevant OpenProject version handles these fields and relations in your environment before you write the rule down, because behavior around sprint assignment and scheduling should be tested rather than assumed.

Illustrative example (hypothetical): a team of eight runs two-week sprints for a billing feature and needs a Gantt view for a go-live date that depends on a third-party certificate. The product owner moves a story to the next sprint, and the dependent test task shifts past the go-live milestone. The team agrees that only the project manager edits dates on the milestone and its predecessor chain, while the scrum master controls sprint membership and status. The shift is then visible in the Gantt view at the planning meeting instead of surfacing on release day.

Before rollout, run a pilot in a separate project with one real backlog, a short set of dependent work packages and one planning cycle. Check that a sprint change, a date change and a status change each appear correctly in the board, backlog and Gantt views, and that people can see who changed what in the activity log. Ask the team to report where they expected a field to behave differently. Use the pilot results to finalize the field ownership rules, then decide whether the same project structure suits every team or only some of them.

Start by confirming that your source system is supported before you plan anything else. The OpenProject Jira Migrator imports from Jira Data Center 10.x and 11.x, not from Jira Cloud. If your team runs Jira Cloud, the migrator does not apply, and you will need a different route for moving projects, issues and history. The migrator is also in beta, and the OpenProject documentation advises using it only in test setups. Treat the first run as a rehearsal on a non-production instance, and plan the cutover as a separate, later event.

The migrator currently imports projects, issues, versions, custom fields, users, groups, statuses and types. Those cover the core of a backlog: work items, their status and type, the release versions they belong to, and the custom fields your team relies on for estimates or classification. Users and groups come across so that assignments and ownership can be checked after import. Confirm the exact field mapping for your custom fields in a test run, because a custom field type that does not map cleanly will need a decision about whether to recreate it in OpenProject or leave it in the archive.

Issue relations and sprint assignments are listed as coming soon, and workflows and permissions are planned for later. This matters most for Scrum teams. Dependencies between stories and the sprint each story was committed to will not arrive with the migrator today, so you should not expect OpenProject to reproduce the Jira sprint history automatically. Decide early whether sprint history must be preserved as a record. If it must, plan a manual or scripted approach, such as exporting sprint membership from Jira and recording it as a version, a saved query or a documented archive that people can search. Ask the OpenProject team and check the current migration documentation for the status of relations and sprints before you commit to a design.

Because workflows and permissions are not migrated, you will also rebuild the board and role setup in OpenProject. Define the statuses and types that your Scrum or Kanban board columns will use, assign project roles deliberately rather than copying Jira groups, and verify that the backlog and sprint views show the work your team expects. Ask a sample of users to check their assigned items, and record any gaps as acceptable, scripted, or blocking. This list becomes the input to your cutover decision.

Your side of an agile boards and Scrum backlog setup starts with decisions that only your organization can make. Name one product owner or delivery lead who can approve the status and type model, decide how sprints and backlogs are ordered, and sign off on the board configuration before it reaches your users. Without that person, configuration questions stall, and the team ends up choosing defaults that nobody has agreed to keep. The named owner should also be the contact for the written scope, so changes after work begins go through one approval path.

Next, provide your current workflow in writing. Describe how work moves from idea to done today, which states your teams use, which issue types they rely on (stories, bugs, tasks, epics), who transitions tickets, and where the process breaks down. A simple document or a whiteboard photo with notes is enough. Add sample backlog data, ideally an export or a representative set of items from your existing tool, including sprint or cycle assignments, estimates, custom fields and links between items. This data shows how the status and type model will be mapped and where the migration record needs exceptions. If you plan to use the Jira Migrator, confirm first whether your source is Jira Data Center, since the tool does not import from Jira Cloud and sprint assignments are not yet supported.

Identity and access inputs come next. Provide the details of your identity provider, including the protocol you use (SAML, OpenID Connect or LDAP), the group structure that should map to project roles, and who administers it. Single sign-on and LDAP group synchronization are Enterprise features in OpenProject, so confirm your plan before you commit to that design. You will also need access to a staging instance that matches the production setup closely enough to test board settings, permissions and sign-in. Agree in advance who can grant test accounts, and who will review results on that instance before anything is copied to production.

At handover, you should receive a configured OpenProject instance with the board and backlog settings applied to the projects in scope. You also receive documentation of those settings, covering board definitions, backlog configuration, the status and type model with its transitions, and the rules behind them. A migration record should list what was imported, what was mapped to a different status or type, what was excluded, and what remains for manual follow-up. Finally, an operations runbook describes routine administration tasks, how to add a new team or project to the Scrum or Kanban pattern, and who to contact when something fails.

Confirm every deliverable against the written scope before work starts, because the scope defines what counts as complete. Ask for each item to be listed by name, with acceptance criteria, the environment it is delivered to, and the person who signs it off. Ask the partner which items depend on your inputs and what happens if an input arrives late. Items that are not in the agreed scope, such as Gantt integration decisions, portfolio views or time tracking, should be recorded as separate work rather than absorbed silently into the handover.