Projects, boards and products
A project defines issue keys, fields, types, workflows and permissions. A board displays selected issues in columns and helps order the work. A product connects projects through a shared backlog, Product Goal and Definition of Done. Adding a project to a product does not move its issues or change their keys.
A project can belong to several products. A Scrum board connects to one product, and a product can have several team boards. Each team plans sprints on its own board. Kanban boards work without sprints and do not use this product connection.
Create and configure a board
Open "Boards and products" and choose to create a board. Choose Kanban or Scrum, enter a name, then define which issues the board includes. You can define scope using projects or a query. QQL board selection is limited to 500 issues; narrow the query for larger sets.
A board is managed by its creator, a Company administrator or someone with board-management permission in every project in its scope. Creating or editing a board requires an assigned seat. Readers see only accessible issues; a board does not grant additional project or issue permissions.
Set up columns and their assigned statuses in board settings. A column may contain several statuses. Moving a card through a workflow transition requires transition permission; changing a field requires edit permission; changing order requires ranking permission. Dragging a card cannot bypass a missing workflow transition.
Add quick filters for frequent selections, such as assignee or priority. A quick filter hides cards that do not match; it does not delete issues. See QQL for query syntax and Workflows for transitions.
Working on a Kanban board
Open the board, select a filter and move a card to the next column. Choose a transition if Quevell offers several. Status and field changes appear in the issue and its history. To reorder issues, drag a card to a different position in the list.
If an action is unavailable, check permissions, board scope, column settings and the issue's workflow. A column move does not always change status: columns without assigned statuses can organize the board independently.
A shared product backlog
A Company administrator creates a product under "Boards and products", names it and selects active projects. To change the scope, preview the proposed changes before saving. The shared backlog contains accessible issues from those projects. Project permissions and issue security remain in force.
Connected boards use the product's shared issue order. Teams can filter their work through board settings and plan it in their own sprints. An issue can belong to only one open sprint within a product. Planning in another overlapping product does not share this restriction. For a standalone board, the same restriction applies within that board.
For example, a product connects application and service projects. Both teams use the same backlog order while choosing work for their own sprints. Planning the same issue into a second open sprint of that product is rejected. Return it from its earlier sprint first if the teams agree to hand the work over.
Goal and Definition of Done
The administrator maintains a shared Product Goal and Definition of Done. A goal can be completed or cancelled; you must complete or cancel the active goal before starting another. Product revisions record these changes.
The Product Goal describes the shared outcome. A Sprint Goal belongs to one team's sprint. The Definition of Done records a common agreement; its text does not automatically transition issues or verify the work.
Starting a sprint captures the product commitment revision. Later edits to the goal or Definition of Done do not rewrite that sprint's commitments. Read them when reviewing its history and results.
Board connections and archiving
The administrator selects a product in Scrum board settings, previews the connection and confirms it. Every explicitly selected board project must belong to the product. A query-based board is additionally restricted to the product's projects.
Choose the connection before planning sprints: changing or removing it is not permitted while the board has active or planned sprints. Its earlier standalone ordering is retained and becomes active again after disconnection. Product scope changes can also be rejected when they would conflict with connected boards or open sprints.
Products are archived without permanent deletion. Both active and planned sprints on connected boards block product archiving, even when empty. An active sprint can be completed normally. There is currently no separate action to cancel or delete a planned sprint. Without running that sprint, you cannot remove this block while preserving the board and its history. Returning every issue to the backlog or archiving the board does not remove the block. You must restore an archived product before editing it or planning new work. History and earlier results remain available. Continue with sprint planning.