Board course 06 — Completing work, handling change and closing the project

Completion is a business decision recorded in the right place. This chapter brings the welcome-note example through review, correction, delivery and project closeout while keeping task, sprint and project states distinct.

In this chapter

• Review the actual output
• Use status and effort honestly
• Handle scope changes before changing shared records
• Establish the receiving result
• Close each record for its own reason
• Complete a short independent check

Review the actual output

Begin with the task's agreed brief and the exact version being reviewed. For the welcome note, the checks are purpose, specific materials and a clear first action. Read all three sentences. If the materials sentence says “Bring the usual things,” that criterion fails because a newcomer cannot identify the materials.

Record a precise finding: “Version 1 does not name the materials. Replace ‘the usual things’ with the agreed paper and pen, then recheck the complete note.” Do not write a fictional positive review merely to advance the workflow.

The review task can finish when it produces the complete required review, even if its conclusion is changes needed. Correction and delivery remain separate. Keep the original criteria when correcting the draft; do not quietly remove a failed condition. Identify the revised version and explain which finding was addressed.

For the supplied three-sentence draft in chapter 1, all three text checks pass. That is a bounded content review. It does not establish that a particular reader opened a stored file or that an independent person performed the exercise described by the note.

Use status and effort honestly

Task controls include Backlog, In Progress, Review, Done and Update Task. Use a state that describes actual work under the agreed process. Do not cycle through every state to imitate a theoretical workflow or assume the application enforces your acceptance criteria.

Before Done, compare the task's output against its own completion condition. A draft task needs the draft; a receiving task needs the receiving result. After a permitted state change, save once and reopen the exact task independently. Compare the relevant list too, allowing it to settle. A stale list is a reason to retrieve, not immediately save again.

Keep actual effort separate. If drafting took 25 minutes against a 30-minute estimate, record actual effort only through the supported field and unit. Do not copy the estimate to Logged Hours. Blank logged time means not recorded, not necessarily zero work. Allowance for correction is not actual labor unless correction occurred.

Handle scope changes before changing shared records

Suppose someone asks for a fourth sentence naming a help contact. That changes the original three-sentence output. Decide who can approve the change, what acceptance condition changes, whether the intended contact is appropriate to name, and what additional drafting/review time is needed. Preserve the original scope until the decision is authorized.

Once approved, update the relevant brief and version deliberately, then recheck the affected output and relationships. Do not treat a chat suggestion as authority to change someone else's task, audience or deadline. A new label or renamed status does not itself approve scope.

Config > Statuses and Stages & Rules affect workflow definitions. The transition form exposes From status, To status, Enabled, Assignee only, role choices and Priority/Label conditions. These controls do not prove content-based acceptance enforcement or safe migration of existing records. Enabling the feature is itself a configuration change; ordinary project closure does not require it.

Config > Resolutions > New Resolution has Resolution Name and optional Description. A resolution such as Fixed classifies a disposition. It is not a substitute for the actual correction or the recipient's decision. Avoid modifying shared configuration merely to make this practice easier.

Establish the receiving result

Deliver only the approved final version through the permitted route. The receiving test should answer: Can the intended receiver read the complete note? Is it the agreed version? Do all three content checks pass? What decision did the receiver make?

A file link, sent message, attachment name or your own successful preview does not establish another person's access. In a one-account practice, label the receiving check as simulation. If the required body is denied or the receiver has not checked it, keep delivery open and state the missing condition.

A complete receiving record for an authorized simulation could say: “Same-account practice: read the complete version 1 note. Purpose is stated in sentence 1, paper and pen in sentence 2, and the three labelled boxes in sentence 3. These checks pass. This is not independent acceptance by another person.” Use that wording only after actually performing the stated check.

Close each record for its own reason

When delivery's condition is satisfied, update that task through its supported control and verify the retained result. Then open the project. Project states are Planned, Ongoing and Completed, with Update Project. Completed is a separate decision based on the project's full outcome, not a guaranteed automatic rollup of Done tasks.

A sprint's Closed state ends a timebox. It neither completes the project nor settles its outstanding tasks. Likewise, project completion does not demonstrate a goal metric changed. Inspect each record independently and preserve any remaining obligations.

A useful closeout names the agreed scope, final version, review result, receiving result and remaining limitations. Keep supporting history rather than deleting it because the project is complete. If delivery remains blocked, a truthful closeout may instead report completed production and review with receiving still pending.

Complete a short independent check

Use a different fictional note: “We will practise identifying a next action. Bring a notebook. Start by writing one action you can finish today.” Create no records unless your practice authorizes them.

Prepare a three-task plan, a complete draft brief, a review against purpose/materials/first action, and a receiving condition. Explain which Board screens and fields would store the project, task membership, responsibility, due date and evidence. Then answer this exception: the review passes, but the receiver cannot open the stored copy. The correct response preserves the passed text review and leaves receiving acceptance open; neither Done on the review task nor Completed on a project can repair the access gap.

You have completed the course when you can navigate the records, explain field choices, verify retained relationships and states, and distinguish completed production from accepted delivery. Any unavailable native practice remains a specific practical gap, not a reason to invent a successful result.