Your first project

This walks one project from nothing to a set of initiatives ready to build. It assumes the organization is already set up, because the policies created there are what your specification is written against.

Taiga shows your progress through the first three steps as Describe, Shape and Plan. Those are the same three used below.

Describe

A project starts one of two ways. Either it is empty and you describe what you want to build, which is the path this page follows, or you point Taiga at an existing repository and it drafts the project’s documents from the code for you to review. Everything from Shape onward is the same either way.

Create an empty project, then open Discovery.

Discovery is where a project gets defined. It starts as a conversation: you describe what you want to build, and Taiga builds a structured specification from what you say, covering vision, users, capabilities and technical requirements. You do not need to prepare anything or know the vocabulary. Answer in your own words, and say when something is undecided.

Your progress is saved as a draft, so you can leave and come back. Work through the sections until the specification is complete, then publish it. Specifications are versioned, so publishing is not a final commitment: you can create a new version later, either starting fresh or copying from the current one.

You are done with this step when a specification is published.

Shape

Discovery is not only the conversation. With a specification published, it is also where the rest of the document set is generated from it, one document at a time.

The project home always shows the single next thing to do, and each one takes you back into Discovery to produce that document:

1. User flows, which define how people interact with the system.
2. Architecture, the technical structure, designed from those flows.
3. Data flow, documenting how data moves through the system. This one comes before the security work, because the security assessment reads it.
4. The security set: a DPIA, a threat model and a risk register. These are three separate documents, generated individually like the others.

Review each document as it appears rather than at the end. They feed each other, so a wrong assumption in the architecture is cheaper to fix before the threat model is written from it.

This is the step that used to take weeks or even months. Producing a specification, user flows, an architecture, a data-flow model and a full security and privacy assessment is normally a project of its own, spread across several people. Here it is hours, which changes what is worth reviewing carefully: the bottleneck moves from producing the documents to agreeing with them.

You are done with this step when the document set is complete.

Plan

When the documents are complete, choose Generate Initiatives.

An initiative is a slice of work that agents can plan and build. This is where the specification stops being a description and becomes a set of things to do.

What you get is a sequenced backlog, not a feature list

Taiga reads the whole document set, not just the specification, and produces a backlog in the order it can actually be built.

It starts with foundations. The first initiative has no dependencies and covers the things everything else needs: infrastructure, CI and deployment, containers, environments. On an imported codebase it is scoped to what is missing rather than rebuilding what works.

It covers the layers, not just the features. Persistence, authentication, the core domain, and a real user-facing shell early enough that the product is demoable rather than a backend with a UI promised later. Where a DPIA or threat model exists, compliance work is part of the backlog rather than a phase at the end.

It is ordered by dependency, not by wishlist. Every initiative records what it depends on, and priority follows that graph: nothing is scheduled before the thing it needs.

It is estimated. Each initiative carries a size, deliberately spread across small, standard and large rather than everything landing on the same number.

It is traceable. Each initiative cites the documents it came from, so you can see why it exists. Security work cites the threat model and DPIA; anything user-facing cites the user flows.

One thing it deliberately does not do is create initiatives for cross-cutting work. There is no “Testing” or “Error handling” initiative, because those belong inside every other one. A backlog padded with those looks thorough and defers the actual work.

Read it before you build from it

The backlog is a proposal, and it is the last cheap moment to disagree. Reordering, resizing or deleting an initiative now costs a click; discovering the sequence was wrong three builds in costs the builds.

You are done when the project has initiatives.

Before you plan an initiative in detail

Connect the project’s repository. Detailed planning requires it: Taiga reads the code before it decides on concrete steps, so the plan describes changes to your codebase rather than to a guess about it.

Define an environment at the same time. It is not required in order to plan, and it matters more than that makes it sound.

It matters most for the very first initiative. That one builds your foundation: infrastructure, CI and deployment, containers, hosting. It is the pipeline from your repository to your cloud, and those layers are planned as one because they are coupled: the infrastructure definition feeds the pipeline, and the pipeline deploys to that infrastructure.

Planning it without an environment means planning that pipeline against a guess about where it terminates. Every later initiative inherits the result.

Both live in Project Settings.