Plan, deliver and review project work¶

Project execution turns a delivery objective into work that people can own, schedule and review. Agile projects use backlog items inside sprints. Plan-driven projects use work packages inside phases. Both approaches share the same underlying work lifecycle and completion requirements.

Availability: These instructions describe the intended journey in the inspected Final Screens. The current project preview uses sample records and action dialogs that do not save your changes. Sample outcomes do not establish that an action was saved. Connected forms, permissions, error recovery and deployment still need verification. Where a screen and the implemented behavior disagree, the limitation below takes precedence over the screen's promise.

Start with project setup and lifecycle if you have not created the project. This guide covers grouping, item details, responsibility, progress, completion requirements and review. Continue with deliverables, milestones and formal reviews for output acceptance, checkpoint criteria and formal approval requests. Repository connection, dependencies, shared delivery and reporting journeys remain under review.

Understand the delivery record¶

For managers and executives, distinguish work in progress, ready for review and completed when assessing delivery. A closed sprint, an elapsed target date, a high percentage or an evidence count is not by itself proof of an accepted business outcome. No guaranteed return, throughput or delivery date follows from those indicators.

Before you begin¶

Confirm the workspace, project and item identity. You need project-viewing permission to inspect execution and project-management permission to make these changes. Being named as an owner, participant or reviewer does not by itself grant that permission. Tenant administrators should verify the person's assigned access rather than relying on their job title.

Use the delivery approach enabled for the project. A backlog item needs a saved sprint; a work package needs a saved phase. The target group must belong to this project. The inspected setup creates an initial group and does not offer a connected way to enable an alternative delivery approach later.

Choose references, titles and dates before creation. Work-item references are required by the service, stored in uppercase, and limited to 64 characters. A reference must be unique within its project and group. The ordinary edit action cannot change it later. Titles are required and limited to 256 characters; stored descriptions allow 4,000 characters. Use concise priority wording. A missing due date means no due date has been recorded, not that the work is on schedule.

Find work in Execution¶

1. Open the project and choose Execution.
2. For agile work, inspect the backlog board or switch to Sprint work to review items within their sprint. For plan-driven work, inspect the phase-based delivery map.
3. Use the intended search and filter controls to narrow the display. Clear them when a known item appears missing. Refresh the workspace before deciding the item has been removed.
4. Check the reference, title, current group, owner, due date and state before opening its action menu or management companion.

Search, filtering and the sprint date-order option still require connected implementation. Do not assume summary counts match a filtered display until that behavior is verified. Missing person details are not proof that ownership was removed. An unavailable or restricted load is also different from an empty group.

Blocked means temporarily unable to proceed. It is not a retirement or deletion state, despite the current board's misleading explanatory copy. Completed work remains visible. Planned dates describe a schedule; they must not be presented as the actual date a sprint closed.

Create and manage a sprint or phase¶

1. Choose Create sprint in the agile workspace or Add phase in the plan-driven workspace.
2. Enter the name and a positive order number. Order numbers must be unique among groups of the same kind in this project.
3. Add a goal or description and planned start/end dates when known. If both dates are set, the end must be on or after the start. Confirm how dates are displayed in your workspace's timezone.
4. Choose Create sprint or Create phase. After a confirmed save, reopen the group and verify its Planned status, order and dates.
5. Use Manage sprint or Manage phase to update those fields or choose Planned, Active or Closed. Choose Save sprint or Save phase, then check the saved result.

Closing a group leaves its items visible. Review and move unfinished work before closing it as a delivery practice: the inspected service does not enforce that practice or automatically finish the items. It also does not enforce a single active sprint or prevent later edits solely because the group is closed. Do not use a closed group or a project hold as a substitute for access controls.

Create an item¶

For agile delivery:

1. Choose Create item on the backlog board.
2. Enter the backlog-item title and delivery notes, select a saved Sprint group, and set priority and due date as appropriate.
3. Review the intended outcome and select Create item only when the connected form can also supply the required reference.
4. Reopen the saved item and verify its reference, group, Planned state and initial 0% progress. Set responsibility and completion requirements through its actions.

Creation gap: The inspected New backlog item design has no reference input and says the reference can be added after creation. The service requires it during creation and does not provide a later reference-edit action. The current form therefore cannot yet be accepted as a complete creation journey. Do not invent a code or assume one will be generated automatically.

For plan-driven delivery:

1. Choose Add work package in the delivery map.
2. Enter the title, description, priority, due date and a saved Phase. Supply a meaningful reference, even though the inspected design calls it optional.
3. Assign an owner when a valid choice is available, or leave ownership unset for later. The phase is still required; its helper text currently confuses phase selection with optional ownership.
4. Choose Add work package, then reopen the record and check its identity, phase and Planned state before continuing.

The current preview controls do not create either kind of item. Follow the intended form and verify the saved result when a connected implementation is available.

Edit details, change responsibility and move work¶

Use Manage details for a backlog item. Update its title, delivery notes, priority, due date and progress, then choose Save details. The reference stays fixed. Setting progress to 100% does not submit a review or complete the item.

Use Change owner, choose the responsible person from the intended project-participant choices, then choose Save owner. Confirm the saved person. The current service checks for a valid identifier but does not itself prove that the selected person is an active, eligible project participant. If the choices are missing or wrong, ask the project administrator to resolve them. No verified unassignment action is established here.

Use Move item, select another saved sprint in this project, then confirm Move item. Work packages can similarly move between saved phases through their management surface. Moving preserves the item's identity and reference; a conflicting reference in the destination can prevent the move. Check both group placement and affected milestone information afterwards. A complete history of prior group assignments is not established by the current read path.

Manage work package combines details, owner, phase and completion requirements on one screen. Those changes are separate service operations. Until the connected implementation demonstrates their save and recovery behavior, do not assume Save changes commits every section together. Reload after uncertainty and confirm each intended change before retrying.

Completed items cannot use these ordinary edits; reopen completed work first when further delivery is needed. A cancelled item is also locked by the inspected item rules, but this intake establishes no cancellation journey for individual work items.

Start work or record a blocker¶

To begin, open Start item, confirm the item, then choose Start item. The saved state becomes In progress and progress is raised to at least 1% when it was zero. The current implementation can also restart other unfinished states; the guide does not treat the design's Planned-only wording as a complete restriction.

When work cannot proceed, open Block item, enter a clear reason and confirm Block item. Use at most 512 characters for the reason, the strictest limit on the inspected request path. Check the Blocked state and visible explanation after saving. Blocking does not delete the work or resolve its dependencies.

Starting again clears the block reason. Starting or blocking an item that was awaiting review does not consistently clear its saved review metadata. Check the current work state alongside the review information, and escalate contradictions rather than interpreting an old review label as a new decision.

Set completion requirements¶

1. Open Update requirements for a backlog item, or the Completion rules section of a work package.
2. Set the number of merged pull requests required, whether a successful build or deployment is required, and which project deliverables must be accepted. A pull request is a proposed code change; use these engineering checks only where they are relevant to the work.
3. Choose the review route: Light review without a workflow step, or Workflow approval with a step required before completion. These are paired choices, not four independent combinations.
4. Choose Save requirements or the work-package save action. Reload and verify the complete set of saved requirements.

Backlog creation normally chooses light review; work-package creation normally chooses workflow approval. Read the saved policy rather than inferring it from the work type. A one-pull-request example in the design is not a universal creation requirement.

Changing requirements while an item is ready for review returns it to In progress and clears the pending review state. The changed policy needs a fresh assessment. Explain that consequence to the reviewer before changing requirements during review.

Check evidence and submit for review¶

Evidence must be linked to this item, and required deliverables must belong to the project and be accepted. Merely connecting a repository or writing a link in a note does not establish that the evidence is attributed correctly.

Use Run evidence check, then Run check again, after relevant proof or requirements change. This reassesses saved evidence; it does not fetch a new repository run. It can move an unfinished item into Ready for review when its requirements pass, even if the item was blocked or had not been started. If prerequisites no longer pass while a review is pending, it can return the item to In progress. Check the resulting state, not just the confirmation message.

To submit deliberately, open Request review and choose Send for review after verifying the prerequisites. If evidence is missing, resolve the stated requirement and check again. If the item is already awaiting review, follow that review rather than submitting again.

“Mark complete” currently submits for review too. Its design and success wording imply immediate closure, but the implemented action uses the same prerequisite check as Request review. Expect Ready for review, not Completed, until the applicable acceptance decision finishes.

The request-review and mark-complete dialogs offer optional notes, but notes entered there are not currently saved. Do not rely on these fields as the record of a handoff, evidence link or decision. Use the actual linked proof and ask support to resolve any missing handoff record. Approval and return-for-changes notes are handled separately below.

Approve or return work¶

For light review, open the review-ready item and inspect the work, linked evidence and required deliverables. Confirm the proof is still current: the light-review approval action does not recheck evidence itself or enforce that the reviewer differs from the assignee.

• To accept it, choose Approve review, optionally enter an approval note, then confirm Approve review. Verify Completed, the completion actor and time, and 100% progress.
• To request correction, choose Return for changes, explain the missing work or proof in the review note, then confirm Return item. Verify In progress and the rejected review record. The delivery owner can correct the work and submit again.

These notes are recorded with the review decision. Keep them specific and free of unnecessary personal or sensitive information. A team requirement for an independent reviewer must be managed explicitly until an enforcing control is verified.

For workflow approval, the light-review buttons cannot substitute for the required workflow. Completion depends on the linked completion-approval workflow outcome and the item's evidence. A workflow rejection returns review-ready work for correction. The governance guide explains workflow initiation, permissions and recovery; do not treat submission alone as proof that a workflow was started or approved.

Reopen completed work¶

Open Reopen item, review the confirmation, then choose Reopen item. This applies to completed work. Verify Reopened, 0% progress and a cleared current completion actor, method, time and ready-for-review time.

The item keeps its assignment, requirements, evidence and recorded review history. Reopening therefore does more than change a label, but does not create a fresh item or erase earlier review records. Reassess which proof is still relevant before starting and submitting the next cycle. The current evidence check does not automatically require new proof merely because the item was reopened.

Recover and obtain help¶

After a timeout or unclear save, reload the same project and item before repeating an action. Verify the saved state, owner, group, progress and requirements that the action should have changed. A success-looking preview, stale tab or old evidence summary is insufficient.

If access is restricted, contact your workspace administrator. For a validation error, correct the stated field; do not create duplicate work to bypass it. For conflicting state or uncertain outcomes, give support the workspace, project reference, item reference, action, time and exact message, using sanitized examples where possible. Never include credentials or private proof in public documentation feedback.

Support and delivery leads should keep item completion, milestone acceptance and overall project closure separate when investigating. The current completion check does not establish that every dependency is resolved, that all evidence refers to the same latest build, or that closing a group locks its children. These limits must be understood before using the workspace as a formal acceptance control.

Read Dependencies and shared delivery for the distinction between a block reason, a linked dependency and a recorded resolution or participant outcome. Use the report guide to interpret delivery counts after work changes. Return to the project overview or project lifecycle guide.