Retrospectives

Automatic Creation

When a release is marked as delivered, Sinra creates its retrospective automatically. You never need to create a retro manually or remember to set up a Miro board at the end of a release.

Four Feedback Categories

Each retrospective collects feedback in four structured columns:

Any team member can add entries to any column. Each entry is attributed to its author.

Discussion on Retro Items

Each retro entry supports a comment thread. This allows the team to discuss a specific point without cluttering the main retrospective view. Use comments to dig into root causes on “Bad” items or refine “Improvement” proposals.

Release or Cycle

A retrospective is attached to a release or to a cycle (at least one of the two). A retro created when a release ships is attached to that release. You can also link a retro to a cycle from its edit form: it then appears in the list of retros on the cycle page, and on the release page when it has one.

Browsing Past Retros

All retrospectives are available in the Retros list, linked to their release. This creates a searchable history of what your team has learned. New team members can read past retros to understand recurring patterns and previous decisions.

Line breaks typed in a retro feedback are kept when it is displayed.

Tracked Actions

The decisions of a retro are actions, not free text. Each action has an owner, an optional due date and a status (to do, in progress, done, abandoned). An action past its due date is flagged as overdue; an action without a due date is never overdue.

• The owner moves their own actions forward; so does the person who created the action.
• The owner gets an email when an action is assigned to them, in their own language.
• Actions of retros and postmortems are listed together in Learn → Actions, filterable by owner, origin and due date. Product owners and managers also get an “Open actions” widget on their dashboard.

An action needs an owner and a due date. Late actions are counted in a banner on the retro and on the Actions page, where each action converted into an issue also shows that issue and its current status. When a retro is converted, the release or cycle is proposed only if it is not over; otherwise the current cycle or release is used.

Converting an Action into an Issue

Convert to issue opens the issue form already filled in: the title, a link back to the retro, the type (a task for a retro), the owner as assignee, and the release and cycle of the retro. Every field stays editable. Once saved, the action and the issue point to each other, and the status of the action follows the issue: done when the issue is finished, abandoned when it is deactivated, back to in progress when it is reopened. If the issue is deleted, the action gets its previous status back. An action converts into one issue only.

Participants

Add the people who took part in the retro. They are notified by email and find the retro in My retros, which also lists the retros where they own an action.

A new retro starts with the people the issues of its release or cycle are assigned to; add or remove others as needed.

Each line of the retro notes can become a tracked action in one click (the action form opens prefilled; owner and due date stay required). A retro lists the incidents (postmortems) of the same release or cycle, and a postmortem lists those retros. An open action written in both a retro and a postmortem is flagged Also elsewhere.