Backlog to shipped release — without a separate planning tool.
GForge doesn’t have a separate “Agile module” living next to the real product. Sprints, releases, and backlogs are built from the same tickets, queries, and boards you already use for everyday tracking — no second tool to learn, no data to keep in sync.
The backlog is just another release
There’s no dedicated backlog feature in GForge — and that’s kind of the point.
A real Roadmap — two real releases, and a backlog sitting right alongside them.
Create a release, name it however your team likes (package::Backlog is a common pattern), and give it a planned date decades out. It behaves exactly like every other release: tickets get assigned to it through the Milestone field, the same way they’d point at any real, shipping release.
Save a Tracker Query filtered to that Milestone, point a Planning Board at it, and the backlog becomes a live board you can groom — drag tickets out of it and into a real release as your team commits to them. Same tools, same mechanics as everywhere else on Ticketing.
Track it to actually shipping
Progress, remaining work by assignee, and a burndown — for one real, not-yet-released version.
Once tickets move out of the backlog and into a real release, this is what tracking it looks like: a live percent-complete bar, remaining work broken out by assignee, and a burndown estimating when it’ll actually be done.
A Release is the same object GForge’s File Release System uses to host downloads — so once the work is done, the team publishes real installers and binaries to that exact release. Worth being upfront: GForge doesn’t stop you from publishing to a release that’s only half complete. That’s a discipline your team keeps, not a rule the software enforces. See CI/CD for how those files actually get published.
The same Kanban board, doing sprint planning
Columns by Sprint, rows by Assignee — the same board mechanics covered in depth on Ticketing, here doing sprint planning instead of daily triage.
We already covered how Planning Boards work: any saved query, any grouping, a real Kanban board with drag-and-drop that respects the same workflow rules as everywhere else. For sprint planning, that same board becomes a grooming tool — filter to your backlog release, group columns by Sprint, and drag tickets in as your team commits to them for the next cycle.
Full mechanics on Ticketing — this page won’t repeat them.
Running the sprint, day to day
Every project gets an auto-populated Standup — browse any teammate’s queue, scoped to just this project or everything they’re on.
Once a sprint is underway, Standup is where a team actually runs it: what everyone has open, what they’re actively working on, and a live activity feed of commits, ticket updates, and builds — generated automatically, nothing to fill in by hand.
Every user also gets a personal version of this — the My page, with its own kanban-style To-Do and Doing columns — scoped to just their own work. See Standup in full on Ticketing, including how My page is genuinely different from Standup itself and the quick-access queue in the site’s main navigation.
Closing out a sprint
A real, closed sprint — completed vs. carried-over counts, a burndown, a velocity trend across sprints, and a retrospective written right on the page.
When a sprint closes, Sprint Cutover can bulk-move whatever’s still open onto the next one in a single action — no re-triaging tickets one at a time. The Performance Trend chart tracks completed work across every past sprint, so a team can see its actual velocity, not just guess at it.
The Retrospective panel reuses the same versioned wiki engine behind ticket Notebooks, pre-loaded with a simple What Was Good / What Was Bad / Ideas / Actions template. It’s entirely optional — plenty of teams skip it — but for teams that want the discipline, it’s already there, not a separate tool to adopt.
The fundamentals, done right
Sprint, a Real Ticket Field
Every ticket can be assigned to a Sprint — the same field that groups cards on Planning Boards and scopes the Project Sprint page’s own burndown.
Bulk Sprint Assignment
Multi-select tickets in Tracker Item Browse and assign a Sprint to all of them in one action — the same Mass Update tool used for any bulk field change.
Catch It Before It’s Too Big
Saved queries can filter by whether a ticket has children, so grooming can catch work that should be split into Breakdown sub-tasks before it ever reaches a sprint.
Want to see how your team’s day-to-day work surfaces? See Standup on Ticketing.
Plan your next sprint with what you’re already tracking.
Start free, or talk to an engineer about migrating your existing backlog over.