Turn an outcome into an initiative

Describe the result before the steps

The fictional equipment service needs employee self-service. A useful request states the outcome: “An authenticated employee can create a request and see only their own requests.”

Explain why it matters: managers currently enter requests for employees. Define scope: request creation, status display, access checks, and evidence for those behaviors. Exclude automatic purchasing and changes to the manager approval rule.

Do not prescribe file edits before the repository has been inspected. The initiative captures intent; detailed planning turns that intent into implementation steps.

Review what the request produced

Taiga uses the request and product context to create an initiative or an ordered set of initiatives. New work arrives in Backlog. A larger request may need several independently reviewable changes.

Read the generated end state, Why, and Scope. Check that required behavior was retained and exclusions were respected. If an existing initiative already covers the request, Taiga can name it instead of creating a duplicate.

A request blocked by a published policy needs the decision route that policy defines. Read the explanation and resolve the conflict through that route. Do not rewrite the request merely to hide the prohibited action.

Treat the board as an execution sequence

Taiga works one initiative at a time per product, including planning. It starts the next queued initiative after the current pull request merges. It does not automatically move items from Backlog or Todo into Queue.

Queue placement matters. It overrides waiting for unfinished dependencies. Before queuing employee self-service, confirm that the identity foundation exists or that the selected scope establishes it correctly.

Inspect the detailed plan

The planner reads the repository, product documents, policies, instructions, and deployment context. Check the plan against the actual user outcome and environment.

For the equipment service, verify three access cases. An employee sees their request. Another employee cannot see it. A manager retains the intended review access. Include data migration and operational effects if the implementation changes them.

If Build on its own by default is off, the finished plan waits for your decision. Approve starts the build as the approving person, subject to their permissions. Reject uses your feedback to plan again. An initiative can have its own setting.

Use the right record for the next decision

Plans are versioned. A run records which plan it executed. If the intended approach changes, review the initiative and the appropriate replanning action. Use the run to inspect the previous attempt.

A build, a merged pull request, and a production release are different states. Keep the acceptance evidence and deployment responsibility visible as work advances. Continue with autonomy settings.