# Progress you can see

Handing work over is not the end: when things get built and how far they have got are managed in the same place.

## Choosing a dashboard view

The AI assistant is the entry point after login; the dashboard opens from "Home" in the sidebar. Members with editing permission can switch the dashboard to suit the work they are doing.

![PM on Rails dashboard. Requirement readiness, your work, delays and the cycle in one list. Before: you assembled progress by hand. After: the material for review and decisions arrives on its own.](https://pmonrails.com/docs-img/dashboard.png)

| Tab | What to check |
| --- | --- |
| Prepare for development | Readiness of documents, requirement cards, scope and stories, an input for asking the AI, the requirement review list (AI review five at a time), with links to the next screen |
| My work | Your assigned tasks, schedule and next pieces of work |
| Progress and management | Workspace owners and administrators see overall progress and items needing attention; other members with editing permission see their own work |

Before a sprint starts, you can begin with "Prepare for development". You can return to that tab after development starts. Members with read-only access see a viewer-facing review dashboard.

## Updating progress through work and integrations

Record a task's start, review or completion from the board or MCP. **Once GitHub integration and the task's pull request link are configured, pull request activity also updates the task's status.** Sprints and daily summaries update automatically as described below.

- **Reaching main completes the task automatically** — when a GitHub pull request linked to a task is merged into the default branch (main), that task automatically becomes "done" and **the parent story's status is recalculated automatically** (if everything under it is finished, the parent completes too). A merge into a feature branch is recorded as "waiting" and completes once that branch reaches main. The link works from either the branch name or the pull request body ([GitHub integration](https://pmonrails.com/en/docs/github.md)).
- **Sprint status advances by date** — 'Planned → Active → Complete' switches automatically from the start and end dates (no manual operation needed).
- **Daily progress is recorded automatically** — How much of the active sprint has been burned through is snapshotted every day and drawn on the burndown.
- **Delays are detected and announced automatically** — Every morning, tasks that are **overdue / due soon / missing a due date / left untouched for a long time** are detected automatically and their assignees are notified. Everything the whole team needs to watch is gathered into a single [morning development summary](https://pmonrails.com/en/docs/notifications.md).

## Change history (history and notifications in one place)

![PM on Rails change history. A timeline of who changed what. Before: change history lived in chat. After: you can follow updates in the same flow.](https://pmonrails.com/docs-img/activity.png)

Open 'History → Change history' in the sidebar to follow what has moved in the project in chronological order. Even if you missed a notification, this is where you catch up on recent movement such as new pull requests and tasks making progress.

- **For you** — The full history of notifications for the selected project. Notifications from other projects are not shown. You can read further back than the recent ones shown on the bell. Opening it marks unread notifications in this project as read; unread notifications from other projects stay on the bell.
- **Whole project** — Everything that happened in the project (who, when, what), newest first. Task creation, status changes, assignee changes and so on are included.

![PM on Rails roadmap. Cycle or quarterly plans and the chunk being built now. Before: you asked when it would land. After: you can follow the current place yourself.](https://pmonrails.com/docs-img/roadmap.png)

## Roadmap (epics)

- **Drag an epic bar to move or change its period**. The change is saved immediately.
- Status is chosen from 'To do, In progress, Done'.
- Supports colour-coding and filtering by label (release name, quarter, theme and so on), assigning an owner, ordering between epics, and linking child stories.
- **Dependencies between stories and between epics** — 'Epics that must finish first' can be specified in an epic's detail panel and appear on the roadmap as ordering ([dependencies](https://pmonrails.com/en/docs/tasks.md) can also be set on tasks and scenarios).
- **A story's period does not depend on a sprint** — A story has its own start and end dates and you can change them by dragging on the roadmap (which sprint it gets done in is decided on the board).

## Sprints (working in fixed periods)

![PM on Rails sprints. Dates, assignments and progress. Before: what this sprint would build was verbal. After: the cycle moves by date.](https://pmonrails.com/docs-img/cycles.png)

A sprint is **a unit of iteration** that says 'we will get this far in this period' ('Planning and design → Sprints' in the sidebar). Rather than letting work drift, you cut it into fixed periods and repeat 'decide what to do in it → do it → look back when it ends', which makes both progress and pace visible. Cutting it into one or two weeks, or whatever length suits the team, is common.

- **Create a single sprint** — Create a sprint by **specifying only the period (start and end dates)**, from when to when.
- **Decide what to do in this sprint** — Assign the stories and tasks you will get through this time to that sprint. What you decide here becomes 'the promise for this round' and the baseline for the burndown and capacity.
- **Status advances from the dates by itself** — 'Planned → Active → Complete' is calculated from the start and end dates. There is no need to switch it by hand. Once the end date passes, a completion notification is sent automatically.
- **Leftovers go to the next sprint** — When a sprint with carry-over enabled ends, the unfinished tasks move to the next sprint automatically.
- The assigned tasks are moved day to day on the **board**, grouped by story.

![PM on Rails board. Tasks in To do / In progress / Review / Done. Before: implementation moved and the board stayed stale. After: pull request activity returns to progress.](https://pmonrails.com/docs-img/kanban.png)

**By default the board is filtered to 'the current sprint'.** Only the stories and tasks assigned to the selected sprint are shown, and the view toggle at the top ('Current sprint' / 'Also show work not assigned to a development period') lets you also mix in items with no sprint assigned (the backlog). Backlog stories can be pulled into the current sprint all at once with 'Add the entire backlog to the sprint'.

## Burndown and velocity (the pace of delivery)

The dashboard charts how much of the active sprint has been burned through.

![PM on Rails burndown. Remaining work against dates. Before: delay stayed invisible until the deadline. After: the cost of starting with open questions shows up week by week.](https://pmonrails.com/docs-img/burndown.png)

- **Total (scope) and completed amount** — The total of all estimates (the upper line) and how much has been completed so far (the rising line) are recorded every day. Today's position and the remaining days (shaded) are shown too. In the example above: 'total 23h / done 12h (52%) / remaining 11h'.
- **Scope changes show up too** — Tasks added along the way are reflected in the total line, so you can also see whether the work is growing.
- **How it counts** — Actuals count only the tasks completed after the sprint started (anything already done before it started is excluded).
- **Pace over time and forecasting (velocity)** — From the pace of past sprints, it gives you a sense of how much you can take on in the next one.

> If the burndown is not moving, check that the sprint is **active** (start date ≤ today ≤ end date) and that the tasks are linked to the sprint through their story.

## Member load (avoiding overcommitment)

See, member by member, whether a sprint has been packed too full.

- **How much someone can do (capacity)** — Set 'how much this person gets through in one sprint' per member (for example 13 points).
- **Availability** — The proportion of that person you can actually use in that sprint (holidays, other commitments and so on reduce it). For example, 50% if they are only half available.
- **Usable amount** — Capacity × availability. For example, a person with 13 points at 50% availability has **6.5 points**.
- **The load display** — 'Assigned amount ÷ usable amount' colour-codes how busy each member is.
  - Room to spare
  - **Warning (90% or more)** — Getting close to full
  - **Overloaded (120% or more)** — Too much; a signal to revisit the split (for example, 8 points assigned to someone with 6.5 usable points → about 123%)

> Members with no capacity set do not appear in the load display. Set it under 'Project settings → Integrations → Capacity / utilization'.

## Following the connections (traceability)

- From any item you can **walk in both directions** (requirement card ⇄ requirement ⇄ story ⇄ scenario ⇄ task, up to 6 hops away).
- Check 'which requirement card is the basis for this requirement' or 'which requirements are affected by this decision' straight away. It is available from conversation ([AI assistant](https://pmonrails.com/en/docs/ai-assistant.md)) and from [MCP](https://pmonrails.com/en/docs/mcp.md) for engineers.

## Automatic estimates (AI plus a correction for individual differences)

Use it from 'Get an AI estimate' on the task edit screen (open a task on the board and choose 'Edit').

![PM on Rails AI estimate. A proposed value and its reasoning. Before: estimates were instinct. After: people accept or reject, and the number stays on the story and task.](https://pmonrails.com/docs-img/estimate.png)

- From the task's content and the information around it, AI proposes **a two-step outlook** (a standard expectation and one with slack); the final decision is a human one.
- Based on the assignee's past **duration (from starting work to finishing it)**, it shows **a recommended value** such as 'about 6 hours if this person does it (9 hours with slack)'. A task whose assignee changed after work started is dropped from the sample rather than counted in full against the final assignee.
- Note: because this duration includes waiting time, it is not pure effort but 'a forecast of how long it will take'. For people with little data it leans towards the team average and estimates conservatively.

## Next steps

- [AI assistant](https://pmonrails.com/en/docs/ai-assistant.md) / [Claude Web, Claude Code and MCP integration](https://pmonrails.com/en/docs/mcp.md)

---

https://pmonrails.com/en/docs/progress