The work model

SRP has five objects. Four of them hold work. One of them, the task, is the work.

Object	What it is	Has a date	Ends	Health
Project	Where a team’s work lives. One per client or per team. Holds the backlog and all history.	No	No	None
Iteration	One project’s time-box. A set of that project’s tasks due by an end date.	Yes	Yes	Yes
Initiative	A promise to deliver something by a date, made of work items.	Yes	Yes	Yes, with reasons
Work item	One piece of a promise: a deliverable, a decision, or a blocker. Links the tasks, external issues, events, people and notes that move it.	Optional	Yes	Yes, with reasons
Task	A unit of work inside one project.	Optional	Yes	Badge only

How they connect:

• A project holds tasks. An iteration takes some of those tasks and gives them an end date.
• An initiative holds work items.
• A work item links to what moves it: tasks from any project, GitLab or GitHub issues, events, people and notes.

An initiative never holds a task directly. A task links to the work item it delivers.

The short answer

A project is where your team’s work lives. One per client or per team. It never ends. Every task goes in a project.

An initiative is something you promised to deliver by a date, when the work is spread across projects, teams or tools, or when the thing that can block it is not a task at all, such as a client sign-off or a decision. SRP watches initiatives and tells you when the promise is at risk.

If it is one project and one deadline, you do not need an initiative. Use an iteration.

Where health lives

Health lives only on objects that have a deadline and a boundary: iterations, initiatives and work items.

Projects never get health. A project has nothing to be late against, and it holds the old backlog. A project health would always be red, and it would be a count, not a conclusion.

Tasks get a health badge in scoped views (a project, an iteration, My Work), where the list is short and you can see the cause on the row. Tasks do not get stored health or reasons. See Health.

The rules

1. One project and one deadline is an iteration, not an initiative. This stops the same small piece of work from being created twice with the same name.
2. An iteration belongs to one project. It cannot hold tasks from another project, decisions, or blockers.
3. Task-to-task links are dependencies. They tell an iteration why a task is stuck. They do not give the linked set a date, an owner, or a health.
4. A work item rolls up. It goes red when any task under it is overdue, blocked or unowned, and it names the cause. A task never rolls up its linked tasks.

Who needs which part

Below a certain size, none of this matters. One project, ten tasks in an iteration, you look at the list and you know.

The value starts when the work no longer fits in one head: fifteen client projects, five teams, a promise whose pieces sit with people you do not talk to every day. That is when initiatives earn their place. Do not push initiatives on a one-project team. They will feel it as overhead, and they are right.