How to manage project work from backlog to done in Orbyna

A project request often starts with a short message: update the customer onboarding page, fix a reporting issue, or prepare a campaign for launch. Before anyone can deliver it, the team needs to agree on the scope, assign an owner, find room in the plan, and decide who will review the result.

In Orbyna's Project Management System, that work can move through a backlog, sprint, board, and review workflow while keeping its description, discussions, files, and history on the issue. Each view helps the team make a different decision about the same work.

This guide follows an example request to update a customer onboarding page. The workflow applies equally to a software fix, a design task, or an internal operations project.

Capture the request with enough context

Start in the project's Backlog tab and create an issue. Give it a title that describes the outcome, such as "Update the onboarding page with the new setup steps." Add the request details to the description, choose an issue type and priority, and assign an owner when responsibility is clear.

The description should help someone begin without having to reconstruct the original conversation. For the onboarding example, record:

• which page needs changing and why
• the approved setup steps and supporting files
• what is included, such as copy and screenshots
• what is outside the request, such as redesigning the whole onboarding flow
• what the reviewer should check before the work is complete

Orbyna's issue detail brings together the description, attachments, subtasks, linked issues, comments, and activity history. If the requirements need a longer explanation, create a page in the project Knowledge Base and link it to the issue.

Use linked issues when one piece of work depends on another. If the new screenshots require a product change first, record that relationship with "is blocked by" so the dependency is visible alongside the request.

Turn the backlog into a delivery plan

The backlog holds work that has been captured but has not yet been assigned to a sprint. Order it by priority, then review the highest items for clarity and readiness. An urgent request with missing requirements may need a decision before it needs a delivery date.

For teams working in sprints, create a sprint with a name, goal, and date range. Drag the selected issues from the backlog into the sprint. Orbyna shows story point totals for each sprint section, while the velocity report shows points completed in previous sprints. Use those records to inform how much work the team commits to.

In the onboarding example, the sprint goal might be to make the revised setup process ready for customers. Copy changes, screenshots, and page updates should each have clear ownership. Use subtasks where breaking down the request makes the work easier to assign and follow.

Where timing depends on a sequence of tasks, use the Timeline view to show dates and dependencies. Review the screenshot dependency before committing to the page's completion date. The plan should account for the work that must happen first.

Teams using a continuous Kanban process can manage work through the board without organising every request into a sprint. The same questions still apply: what is ready, who owns it, and how much can the team reasonably take on?

Use the board to manage the next action

Orbyna's board displays issues in columns defined by the project's workflow. The default flow is To Do, In Progress, Review, and Done. Moving a card changes the issue's status, while its details remain available from the board.

For the onboarding request, move the issue to In Progress when work begins. Keep decisions in the issue comments, attach the revised files, and use mentions when someone needs to respond. If the scope changes, update the description so the person reviewing the work sees the current requirement.

During a daily review, use board filters to focus on an assignee, priority, label, type, or sprint. Swimlanes by assignee help the team see how active work is distributed. Work in progress limits show a warning when a column exceeds its configured limit, giving the team a reason to discuss what needs finishing before more work starts.

A short board review should resolve a few practical questions:

• Which issue can move forward today?
• What is waiting for information or another task?
• Who owns the next action?
• Does any change affect the sprint goal or a promised date?

Record the resulting action on the issue. That gives the next person a clear place to continue after the meeting.

Make review part of the workflow

For the onboarding page, finishing the edits is only one step. Someone still needs to check that the instructions match the product, the screenshots are current, and the page is ready for its intended audience.

Define what Review and Done mean for your team. Keep the review criteria in the issue description or a linked requirements page so the reviewer can assess the result against the agreed scope.

Orbyna lets project administrators customise statuses and allowed transitions by project and issue type. Transition conditions can require fields to be filled or restrict who can make a transition. Where review is required, configure the workflow so In Progress leads to Review before Done.

For repeated handoffs, automation rules can respond to status changes with actions such as assigning a user or sending a notification. Configure those rules around the team's actual responsibilities, then use the automation log to check whether they ran successfully.

If review finds a problem, record the feedback on the issue and return it through the configured workflow. Its comments and field history preserve the context for the next pass.

Use completed work to improve the next plan

Once the onboarding update meets the agreed completion criteria, move it to Done. At sprint completion, review completed and incomplete work and decide whether unfinished issues belong in the next sprint or back in the backlog.

Orbyna's reports support several useful follow-up questions. Sprint performance shows committed versus completed work, scope changes, and carry-over. Cumulative flow helps reveal where work accumulates. Cycle time shows how long work takes from In Progress to Done. Time reports let teams compare logged effort with estimates.

Use each report to investigate a specific problem. If work keeps accumulating in Review, check reviewer availability and the clarity of the review criteria. If requests repeatedly carry over, look at dependencies and scope changes before increasing the next sprint's commitment. If actual effort exceeds estimates, use the issue history to understand what changed.

For the onboarding example, the useful lesson may be that screenshots need to be ready before page editing starts. Record that requirement in the next request and link the dependent work during planning.

• Capture the expected outcome, supporting information, and completion criteria on the issue
• Prioritise ready work and plan against the team's delivery history
• Keep ownership, progress, and decisions current as the issue moves across the board
• Define the review step and configure transitions around the team's process
• Use delivery reports to choose a specific improvement for the next cycle

Start with one project and a workflow your team can maintain. As requests move from the backlog to Done, keep the decisions and evidence attached to the work. That gives everyone involved a shared place to understand what is happening and what needs attention.

Explore Orbyna's project management features or book a demo to discuss your team's workflow. For more on planning around linked work, read How to prevent project delays with dependencies, timelines and early warning signals.