Most tools sort work by type of object. Sinra sorts it by moment of the project. Six verbs, always in the same order, that shape the navigation and the way the team thinks.

Ask five people on the same team where a feature stands. The product owner says “the spec is approved”. The developer says “I have two tickets left”. QA says “I haven’t received anything to test”. The executive says “it’s planned for the next version”. Everyone is right, and no one is talking about the same thing.

The problem is not a lack of information. It is a lack of shared vocabulary to place work in time.

Tools sort by object, teams think by moment

Open any project management tool. The menu lists types of objects: tickets, boards, versions, documents, tests. That is a database layout. It answers “where is this thing?”, never “what should be done now?”.

A team thinks by moment. We are scoping. We are producing. We are checking. That gap forces everyone to rebuild the state of the project in their head from lists that do not show it.

Six verbs, always in the same order

Sinra organizes its navigation around six steps:

Specify: describe what the product must do. This is where capabilities and their specs are written.
Refine: check that it is clear enough to commit. The team reviews, clears up grey areas, estimates.
Plan: decide what ships and when. Releases and cycles are filled according to the team’s real capacity.
Build: deliver. Everyone sees their issues, the current cycle, the current release.
Verify: make sure it is ready. Tests are run, the phase gate review decides.
Learn: draw the lessons. The retrospective and the postmortem feed the next specification.

These six words are in the sidebar, in that order. There is nothing else to learn.

The V-Model, without saying it

Read the list from top to bottom: the first three steps clarify, the fourth produces, the last two check what was clarified. That is the shape of a V. Nothing is built without a spec, nothing ships without verification.

But this V is not walked once per project, over eighteen months. It is walked with every release, sometimes every cycle. Rigor comes from the order of the steps. Rhythm comes from repeating them.

This is what teams that “combine V-Model and Agile” already do without putting it into words. The six steps give it a name.

What it changes day to day

Conversations get shorter. “The payment capability is in Refine” says in a few words what used to take a meeting: the spec exists, it is not estimated yet, it is not in any release.

Gaps become visible. A team that never opens Verify or Learn sees it in its own navigation. No report says it as clearly.

Newcomers find their way alone. A developer opens Build. Someone from QA opens Verify. Nobody needs training to know where their work starts.

What it is not

It is not an enforced process. No step is blocking, and a team of three can go from Specify to Build without ceremony.

It is not a method to get certified in. There is no role to appoint, no mandatory ritual, no coach to hire.

It is not a waterfall. Several capabilities sit at different steps at the same time. The six steps describe the path of a feature, not the team’s calendar.

An order rather than a method

Methods often fail because they ask the team to change before it produces. An order asks for less: knowing what comes before and what comes after is enough.

Specify, Refine, Plan, Build, Verify, Learn. Six words so that five people finally give the same answer.

The detail of each step is in the Workflow documentation.

Specify, Refine, Plan, Build, Verify, Learn: six steps to know where a project stands