expert Agile
A Kanban and Scrum board that is a Redmine query. Every filter, column, grouping and visibility rule you already use on the issue list applies to the board unchanged — and a saved board is one row in Redmine’s own queries table.
Agile plugins usually build a second, parallel world: their own filters, their own permissions, their own idea of which issues you are allowed to see. This one does not. The board is an IssueQuery subclass, so it inherits Redmine’s filtering, sorting, grouping and visibility rules wholesale, and the board settings ride along in the query’s own options column.
What it does
The board
Columns are your issue statuses
Drag a card to change its status. The moment you pick it up, every column shows whether your workflow lets this card in — green where it may go, striped where it may not — from the same check the server enforces the move with, so a blocked column simply does not take the drop. Columns come from the statuses you already have, with optional advisory WIP limits that flag an overloaded column without ever blocking a move. Statuses sharing a Prefix: naming convention merge under one header. Cards show whichever fields you pick — assignee with avatar, story points or estimated hours, percent done, a description excerpt, and any query column including custom fields.
Swimlanes
One lane per person, tracker or version
Project, tracker, status, priority, author, assignee, category, target version or epic becomes a horizontal lane, each with its own issue count and story-point total. Those are the fields a team actually splits its work by; percent done, dates and the private flag are not offered. Boards can be saved privately or shared with the project, and a parent project’s board carries its subprojects’ issues. The global board, linked from the application menu, carries every project you may see.
Epics
Epic, story, subtask — on Redmine's own subtask tree
Pick the trackers whose issues are epics, and an issue belongs to the nearest epic above it in Redmine’s subtask tree — no extra table, no custom field, so the parent filter, the REST API, the Gantt chart and the story point roll-up all see the same thing. Cards carry their epic as a coloured badge and a subtask names its story; a story counts its subtasks done. Group the board by epic for one lane per epic, each headed by its progress, and drop a story into another epic’s lane to move it there.
Epic overview
Every epic, its stories and their subtasks in one tree
The Epics tab lists every open epic of the project with what is done — issues and story points, as a bar and in numbers — and its stories and subtasks as a tree, with status, assignee and points. The same progress shows on the epic’s own issue page. Only issues the reader may see are counted.
Colours
Any colour, by tracker, status, priority or project
Cards take their colour from the tracker, the status, the priority or the project, and column headers can take the status colour. Any colour works — a colour area, a hue slider and a hex field, with the eighteen palette shades as swatches — and the card’s background tint is derived from it and kept light, whatever was picked. The picker, Coloris, is bundled with the plugin, so nothing is fetched at runtime.
Estimates
Story points where Redmine expects them
Stored per issue in the plugin’s own table rather than smuggled into a custom field, offered as a configurable value list (modified Fibonacci by default) and restrictable to the trackers where they make sense. They appear on the issue form, in the attribute table, in bulk edit, and as a sortable, filterable, groupable column on the issue list.
Sprints
Sprints are a real thing, not a renamed version
Name, description, start and end date, and an open → active → closed lifecycle: activating a sprint stands the previous one down, a sprint cannot be closed while it still holds open issues, and a closed sprint takes no new ones, so its burndown and velocity stay what they were. Sharing works the way Redmine versions do, with the same rules on who may share how far: the whole project tree takes a sprint manager of the root project, all projects takes an administrator. Deleting a sprint unassigns its issues — it never deletes them — and a shared sprint that other projects still plan into cannot be deleted at all. Redmine’s own versions stay usable for release planning alongside.
Sprint boards
A board that follows the running sprint
Narrow any board to one sprint from its options, or with sprint_id in the URL. Active sprint follows whichever sprint is running, so a saved sprint board is still right after the next iteration starts. Columns, counts and story-point totals then cover only that sprint, and a closed sprint can still be opened for its review.
Planning
A backlog you can actually drag things out of
The backlog on the left, one lane per sprint beside it, and a second tab that plans into Redmine versions instead. Each lane is headed by its issue count, story-point total, date range and days remaining. It has the same filter panel and card fields as the board, saves named backlogs, and remembers where you were when you come back to it.
Epic planning
Plan stories into epics the way you plan them into sprints
A third tab in the planner puts the stories without an epic next to one lane per open epic. Dragging a story into an epic makes it that epic’s subtask — journaled, under the permission to manage subtasks — and its own subtasks go with it.
Sprint review
Complete a sprint in one step
Complete sprint shows what was done and what is still open, then moves the open issues to the next sprint, back to the backlog, or into a new sprint created on the spot with its name counted up and its dates following on. It closes the sprint and can make the target the active one, so a board following the active sprint is right straight away. Every issue moves like a planner move, under the same permissions and the issue’s own validation; if a single one cannot move, nothing is written and the page says which and why. Also over the REST API.
Issue list
The issue list knows the sprint
Redmine’s own issue list gains a Sprint filter — one or more sprints, Active sprint resolved each time the list runs, any sprint or none — and a Sprint column that sorts, groups and goes into the CSV export. Saved lists such as “everything in the current sprint”, sprint exports and bulk edits of a sprint’s issues come with it.
Charts
Five charts, from what actually happened
Burndown, burnup, velocity, cumulative flow and cycle time — in issues, hours or story points, by day, week or month. History is replayed from the issue journals rather than sampled nightly, so a chart you generate today is right about last month. Measured lines stop at today; the ideal line runs to the end of the range and can skip weekends.
Why this one
- We wanted something simpler, and no more paid plugins. That is the whole reason it exists. It is GPL-2.0-or-later like the rest: no licence key, no fee per server, nothing to renew.
- Board order is computed on the server as a fractional rank. A move sends only the dragged card and its two neighbours and writes one row. Browser-side re-indexing of a whole column corrupts order under concurrent drags and silently reorders cards paginated out of view.
- Chart history is reconstructed in a single pass over one journal query, then cached — not by re-scanning every issue’s journals once per date bucket.
- No inline JavaScript. Views render markup and data crosses into the browser through a JSON island, so the board works under a
script-src 'self'content security policy. - Workflow limits show before the drop, and refusals say why. Blocked columns are marked while you drag. What the workflow cannot know in advance — a field the new status requires, say — is refused after the drop with the tracker and both statuses named, the transitions that are open listed, and a link for admins straight to that tracker’s workflow.
- Agile rights are Redmine’s rights. A drag that changes a status needs the same permission the issue form needs for it, story-point totals count only issues the reader may see, and publishing a global board, chart or backlog is reserved for administrators, as it is for queries in core.
- The REST API writes, not just reads — story points and sprint assignment are both writable, and sprints have full CRUD.
- Completing a sprint is all or nothing. The issues move and the sprint closes in one transaction, so a sprint is never left half-moved — one issue that may not move stops the lot, and is named.
Testers wanted
Try it, break it, tell us
These plugins are young and move quickly. The suites run on every Redmine from 5.1 to 7.0, but our own installation is only one setup — we would like to hear from people who run them somewhere else: another mail server, another theme, next to other plugins, or with a workflow we never thought of. Something broken, something missing, something that works but feels wrong: all of it helps.
The bug form asks for the plugin version and your environment; pasting the table from Administration → Information covers the rest. To hear about new versions, watch the repository on GitHub for releases.
Compatibility
- Latest release
- v0.10.2 2026-11-04
- Redmine
- 5.1 · 6.0 · 6.1 · 7.0
- Database
- MariaDB, MySQL, PostgreSQL
- Additional gems
- None
- Migrations
- 5
- Licence
- GPL-2.0-or-later
No additional gems. Chart.js and the Coloris colour picker are vendored with the plugin, and drag and drop uses the jQuery UI that Redmine already ships, so nothing is fetched at runtime. Works on MariaDB, MySQL and PostgreSQL.
Installing
- Download the release archive: redmine_expert_agile-0.10.2.zip
- Unpack it into your Redmine's `plugins/` directory:
cd /path/to/redmine unzip redmine_expert_agile-0.10.2.zip -d plugins/ - Run the migrations:
bundle exec rake redmine:plugins:migrate NAME=redmine_expert_agile RAILS_ENV=production - Restart Redmine, then enable the **expert Agile** module on a project. The backlog planner is a second module, **expert Agile Backlog**, so you can hand it out separately; its *Manage backlog* permission is also what lets someone set an issue's sprint.
It can be installed alongside another agile plugin — every class, table and route of ours is prefixed to avoid collisions — but enabling two agile modules on the same project is not supported. Story points and sprints are off until you turn them on in the plugin settings.