Requirements and plans

Plan first: what Yavaren reads before it starts

Before a story is implemented, Yavaren reads everything it links to, relates it to the story and lays out a plan. Criteria found in linked material are part of the delivery unless you choose to review or ignore them. You can ask to approve each plan first.

A story often says only half of what is wanted: the rest is in an attached mock-up, a linked specification, the parent epic, a related item or a pull request. Before Tulaian implements a story, it reads all of that, relates it to the story, and lays out a plan. Only then does it write the change.

What it reads

• The story itself, its acceptance criteria and its comments.
• Attachments and images on the item (Tulaian looks at mock-ups and screenshots when its agent can read images).
• The parent item (an epic or a feature) and linked items (related, duplicates, blocking).
• Links in the text: to another item of your tracker, to a file, commit or pull request in the project's repository, and to web pages.
• Links in every other text field of the item too: build notes, technical notes, the definition of done, repro steps, test notes and custom rich-text fields. The list says which field each link was found in, and the text of those fields is read as well.

Web pages are read only at public https addresses, never with any of your credentials, and never from an air-gapped installation. Anything that could not be read is listed with the reason.

Where you see it

Open a job under Recent work › Details. What Yavaren read lists every source and whether it was read; Plan shows what each source adds, where it conflicts with the story, the approach, the files to change, each acceptance criterion with the change and the test that proves it, and the risks. The draft pull request has a short version of the same.

If a source contained text that tries to give instructions to an AI, Tulaian treats it as content and tells you.

Approving the plan first

Under Admin › Plan first an admin can switch on Approve the plan before implementation (off by default). A project can choose differently under Projects › Delivery preferences. When it is on, each story stops at its plan and says The plan is waiting for your approval. Open the job's details and either Approve the plan (Tulaian implements exactly that plan) or say what should change and Ask for changes (Tulaian plans again and waits for you again).

When the plan has a question Tulaian cannot do without, the job stops the same way with the question, why it matters and the assumption it would otherwise make. Answer it, or choose Proceed with Tulaian's assumptions.

You can also have each plan posted on the tracker item.

Criteria found in linked material

Linked pages, items and attachments often hold acceptance criteria or business requirements. By default Tulaian includes them in the delivery: they are checked like the story's own criteria, tests are written for them, the reviewers check them, and the pull request lists each one as met, not met or not verified, with where it came from. When one conflicts with the story's own text, the story wins and the other is listed as not adopted.

Under Admin › Plan first › Criteria found in linked material an admin chooses:

• Include them in the delivery (the default).
• Let us review them first: before implementing, Tulaian shares its understanding of the item, its goal, the criteria (the item's own and those found in linked material, each with where it was found and a quote) and its plan, and waits. You are asked under Waiting for you. Open the job's details, choose Include or Exclude for each criterion from linked material (add a note if you like), then approve. Tulaian implements exactly what you approved; an excluded criterion is never part of the work.
• Read them for context only: linked material is still read, but nothing found there is added to the delivery.

A project can choose differently under Projects › Delivery preferences. There you can also name extra fields to read, or fields never to read.

For a requirement, its features and stories, the same criteria appear on the brief and the stories screens, marked with where they came from. When you review them first, you include or exclude each one in the same approval of the brief or the stories.

Letting Yavaren staff review on your behalf

If plans wait too long for someone in your organisation, an admin can switch on Admin › Yavaren staff review — "Allow Yavaren staff to review plans and linked criteria on our behalf". It is off until you switch it on, and switching it on asks you to confirm.

• Choose what staff may review: story plans (approve a plan, ask for changes, include or exclude criteria from linked material) and/or requirements (decide the criteria from linked material in the brief, features and stories approvals). You can also say for how many days.
• Staff decide through the same steps your people use, with the same checks. Each decision is shown on the job as made by Yavaren staff on your behalf, is in your activity log, and the person who asked for the work and the approvers are told.
• Staff never approve a deployment, merge a pull request, accept an offer or decide anything else.
• Stop now switches it off at once: from that moment staff cannot decide anything for you. Every decision staff took is listed on the same panel.

If your organisation accepted the Managed plan review package (Settings › Packages), Yavaren staff review your plans and requirements while the package is active.