A whiteboard-style agile planning tool built on top of Trac
Switch branches/tags
Nothing to show
Clone or download
cburroughs hard coded support for infoneeded
These need to come out into config variables
Latest commit 23090ff Mar 6, 2013
Type Name Latest commit message Commit time
Failed to load latest commit information.
src/webroot hard coded support for infoneeded Mar 6, 2013
.gitattributes well, not binary files Mar 6, 2013
.gitignore ignore any local config files Mar 6, 2013
LICENSE.txt initial commit Dec 28, 2011
NOTICE.txt initial commit Dec 28, 2011
README.md readme updates Dec 28, 2011



TracBoard is a whiteboard-style Agile planning tool built on top of Trac!

What it does

TracBoard displays a large-format, card-like view of development tasks within milestones. It allows you to move them around easily as you and your team move your way through your sprints. It works for planning activities as well as for monitoring mid-sprint burndowns and swimlanes.

How it does it

TracBoard relies entirely on data stored within a Trac setup. It assumes you use Trac and have a workflow that generally supports agile sprints. It hooks up to Trac via the XML RPC API using the user's authentication, and does not duplicate any data at all -- there is no additional data storage for TracBoard.

Think of TracBoard as simply another view onto the core Trac system; one that makes some assumptions about the structure of your Trac data, but gives you a much more intuitive whiteboard-style interface.

TracBoard is PHP and should run on a fairly vanilla configuration.

Why you might care

TracBoard came out of a need for a whiteboard-style visualization of our development milestones, but a desire to avoid yet another tool when Trac met so many of our detailed tracking needs. We absolutely did not want to have to manage another database of items to be worked on, when all of our detailed defects and other work were managed effectively in Trac. We wanted one database, but with a more useful view than Trac was providing.

If you find yourself struggling with the need for a convenient board-style visualization and planning tool, but not wanting to deal with duplicate data or with using one system for defects and another for feature requests, take a look at this.

A Quick Tour

TracBoard has three main views:

  • Roadmap
  • Sprint
  • Swimlane


The Roadmap view is useful for planning development sprints. It lets you view any number of milestones in parallel, including the special Backlog milestone, and move items between them. Defects, stories, and features are represented as cards, which can be grouped and colored according to numerous different schemes (priority, owner, severity, and more).

The Roadmap view

see larger image


The Sprint view is useful for moving items around within the context of an individual development sprint. Its easy to see the status of various development items within the current sprint. Items are represented by cards as they are in the roadmap view, and have the same types of options.

The Sprint view

see larger image


Finally, the Swimlane view is another view on an in-progress development sprint, oriented in terms of per-story swimlanes. A swimlane is a row of activity around a specific story, making it easy to see the state of all of the items that are related to that story. The same coloring options apply.

The Swimlane view

see larger image

Requirements and Setup

Caveat Emptor. TracBoard is an internal-use tool that we built to better visualize our Trac data. It is not fully vetted for use in Trac setups that are not identical to ours. In other words, if your Trac is not configured in the same way that ours is, it may not work. That said, we're happy to help you try to get things up and running if you'd like to try, and are anxious to build out the flexibility of the setup.

TracBoard is PHP, and is runnable directly from the source distribution. Edit src/webroot/config.inc.php with your own configuration and go from there.

About Trac Workflow Requirements

TracBoard makes several assumptions about the underlying structure of the Trac system; Actions and Fields need to be set up identically for TracBoard to function properly. We're working on improving the flexibility of TracBoard's Trac interface.

The Trac configuration TracBoard assumes is, in brief:

  • development sprints correspond to Trac Milestones
  • milestones are all named in the form YYYYMMDD_*, with special-meaning TBD and Backlog milestones
  • tickets are organized into Pipelines, implemented as custom fields, representing streams of work (teams, in our case)
  • ticket types are story, defect, feature, and task, where story tickets have special meaning and are assumed to have dependent tickets representing the elements of work that need to be completed for the story


Feature Requests

  • move subtickets when moving pris on parent ticket (probably some more general version of this is possible as well)

  • save state for which coloring groups are on/off

  • lighter fonts when tickets have dark color

  • make story/ticket id copyable

  • coloring:

    • "enable all" and "disable all" for coloring
    • hide rows
  • in swimlane, make stories have their own appearance

  • in sprint view, be able to drag between columns to change status

  • in swimlane view, ability to add new top-level stories

  • in swimlane view, allow tickets to be dragged into other swimlanes (meaning a re-parent)

  • add wontfix quick-action in edit view

  • when doing drag and drop:

    • should be able to drop into groupings (not just columns)
    • should show up right away in the new location, not wait for a column refresh
    • shouldn't be able to drop into the region where it already is
  • be able to limit/filter views to only a certain component, for individual planning (use tracboard itself as an example, or maybe "data request"). maybe "any" field as well, some kind of regex or something

  • Projector stylesheet

  • More device-specific/optimized display on ipad

  • make colors for color-by-who static, not dynamic (so people always get the same color)

  • notification to other connected clients when items are moved

Possible Bugs

  • cards should wrap in rows, aligned to top (in Chrome, they wrap at bottom)

  • make sure counts in group and column headers update when dragging and hiding (inc and dec appropriately)