sinraWhat is a Capability?
A capability is a concrete product feature: something your product will be able to do once it is delivered. It lives at the level of abstraction that product managers, developers, and stakeholders can all understand.
“CSV export for reports” is a capability. It is either shipped or it is not. There is no ambiguous “partially done” state.
Capabilities vs Epics
The key difference is completeness criteria:
| Epic | Capability | |
|---|---|---|
| Defined by | User stories grouped together | A concrete product feature |
| Done when | All child tickets are closed | The feature works as defined |
| State | Often stays open indefinitely | Binary: delivered or not |
| Communicable to stakeholders | Rarely | Yes, directly |
An epic can stay open for months as new tickets are added. A capability has a scope decision at the start: when this feature is shipped, the capability closes.
Capabilities in Planning
Capabilities are the unit of planning at the release level. When you define a release, you assign capabilities to it. This answers “what will version 2.4 include?” at the feature level, not at the ticket level.
This makes release planning communicable:
“Version 2.4 includes: CSV export, email notifications, and role management.”
That sentence works in a team standup, a stakeholder meeting, and a product changelog.
Linking Capabilities
Each capability connects to:
- Project: the high-level initiative it belongs to
- Release: which version will ship this feature
- Issues: the specifications, plans, tasks and bugs that describe and build it
- Testings: QA test cases that validate it, optionally one specification at a time
This chain gives full traceability from strategic goal (project) down to individual tasks (issues) and validation (testings). See Traceability.
Issues by Specification
The capability page does not show a flat list of issues. Each specification forms a group that contains its plans and its tasks, in the order of the chain, drawn as a tree with one line per issue. Each line carries its own markers on the right:
- the status of the issue and, for a specification or a plan, its realization (Not started, In progress, Done) with the tasks done out of the total
- the number of tests that verify a specification, or No test yet
- the estimated time of a specification, when it is not zero
A specification without any task says so. Issues without a parent (bugs, isolated tasks, orphan plans) are grouped apart, after the specifications (“Without parent”). Issues from other capabilities that Concern this one are listed separately under Concerned issues; they never count in its progress.
Release of a Capability
A capability belongs to one release at most, and it decides the release of all its issues. Move the capability to another release, or remove it from any release, and every issue follows in the same operation, finished or not. A capability is never split across two releases. When you place a capability in a release for the first time and it has no wished release yet, Sinra also copies that release into the wished release. See Releases.
Capability Body
The capability body uses a rich editor. Teams typically write:
- User-facing description of the feature
- Acceptance criteria
- Technical notes and constraints
- Links to design assets
Because capabilities are shared between product and engineering, this body becomes the living spec for the feature.
Progress Tracking
A capability’s progress is visible through:
- Tasks and bugs done out of the total. Specifications and plans do not count here: their own progress is the realization shown on each line.
- Time estimated vs spent
- Testing acceptance status
The phase of a capability on the product dashboard follows the same logic. Specifications and plans are writing work, tasks and bugs are development work. A capability whose specifications are written but whose plan is still being drafted is in the specification phase. It moves to development as soon as a task or a bug is in progress.
This gives a fast, honest read on whether the capability is truly close to done or just has most tickets closed.
Delivery next to the writing status
The writing status of a capability only says whether its spec is written. Next to it, Delivery 2/5 issues counts the development issues finished out of all of them, so a capability whose spec is done is not mistaken for a delivered one.