Skip to main content

Delivery

Project management: boards, backlogs, epics and sprints

Plan work in the backlog, run it on a board your team configures, and group it under epics and sprints. Every issue keeps its own key, type, priority, assignee and history.
Illustration of the Matrix board: the product's default To Do / In Progress / QA / Done columns, which each project can replace with its own stages. Placeholder issues, not customer data.

What you get

Each item below is functionality in the product today.

A board your team shapes

New projects start on To Do, In Progress, QA and Done. Any project can replace those with its own stages, defined once in Settings and reused across projects that work the same way.

Drag-and-drop that means something

Moving a card changes the issue's status for everyone, and the change is recorded on the issue's audit trail rather than disappearing into the board.

Backlog and sprint planning

Keep unscheduled work in the backlog, pull it into a sprint with a start and end date, and see the active sprint from your own dashboard.

Epics above issues

Group related issues under an epic so a long piece of work reads as one thing on a report, and give every person a My Epics view of the ones they own.

Issue keys, types and priorities

Each project has a key, so issues get a stable identifier like MAT-118 that survives being moved, renamed or re-prioritised. Issues are a bug, a story or a task, at high, medium or low priority.

Sub-tasks under a story

Break a story into sub-tasks that carry their own assignee and status while still pointing back to the parent's key.

Comments, mentions and attachments

Discuss the work where the work is. Rich-text comments are sanitised before they render, and mentioning someone emails them a link straight to the issue.

Notifications people can live with

Field changes email the people who care, with the old value and the new one side by side, and assignees get a single daily digest of the issues on their plate.

Project profile, resources and access

Each project keeps its own profile, its documents, a discussion thread and an access list controlling who can open it.

The board matches how your team works, not the other way round

Most tools give you a fixed set of columns and expect the team to adapt. Matrix ships sensible defaults — To Do, In Progress, QA, Done — and then lets a project define its own stages, because a data-migration project and a support queue do not move work through the same steps.

Stages are a catalogue in Settings, not a per-project free-for-all. Define the set once, apply it to the projects that share a shape, and every report that groups by status keeps working across them.

  • Default columns on a new project, so nothing needs configuring before the first card
  • Per-project stages when the default is wrong
  • Stage definitions live in Settings and are reused, not retyped

Planning above the board

A board is a view of the current sprint. The work that has not started yet lives in the backlog, where it can be ordered, grouped under epics and pulled into a sprint when the team is ready for it.

Above a single project, portfolio and enterprise backlogs and boards show the same work across several projects at once — useful when one team runs four engagements and you need to see all of them in one place.

The part most boards leave out: the hours

A card moving to Done tells you the work finished. It does not tell you what it cost. In Matrix, the Daily Status Report records hours against the project and the specific issue, so the Hours Per Project and Effort Allocation reports are built from the same rows as the board.

That is the difference between a board and a delivery system: you can answer "is it done" and "what did it take" from one place, without exporting anything.

From an empty project to a working board

The setup path a delivery lead actually walks, in the order the product asks for it.
  1. 1

    Create the project

    Give it a key, an owner, a scrum master, a technical lead and a business owner, plus the client, the timeline and the hours you have to work with.

  2. 2

    Choose its stages

    Keep To Do / In Progress / QA / Done, or apply a stage set that matches how this kind of work moves.

  3. 3

    Grant access

    Add the people who should see the project. Access is per project, on top of the role permissions each person already has.

  4. 4

    Fill the backlog and group it under epics

    Write the stories, tasks and bugs, and attach them to the epics that describe the bigger pieces.

  5. 5

    Plan the sprint and work the board

    Pull work into a sprint with a start and end date, then run it on the board. Sprint analytics and the project dashboard read from it as you go.

Delivery: common questions

Can each project have different board columns?
Yes. A project uses the default To Do, In Progress, QA and Done columns unless you give it its own stages, which are defined as a reusable catalogue in Settings.
What issue types does Matrix support?
Bug, story and task, each with a high, medium or low priority. A story can have sub-tasks, which keep a reference to the parent issue's key.
Do people get emailed when an issue changes?
Yes. Field changes send a notification showing what changed, the previous value and the current value, with a link back to the issue. Mentions in a comment email the person mentioned, and assignees receive a daily digest of the issues assigned to them.

Related

Or go back to all features.

Try it against your own work

A workspace takes a couple of minutes to create. Put one real project in it and see whether this shape matches how your team already works.