Here's a screenshot of our Dashboard (click to enlarge):
The left column (Current) contains our sprint items. We have a somewhat “loose definition” of a sprint, because our team is allowed to pick additional items from the middle column (Backlog) anytime they want. We do have a “planning meeting” every Monday, but (for this project) we see no reasons to go through the motions of actually planning and estimating all sprint items. The Product Owner (that’s me) sits with the team, and we can do these things on-the-fly throughout the week.
You can see that Pivotal Tracker distinguishes between features (marked with stars) and bugs (marked with cute little ladybugs). The small blue stripes are our estimates (in story points). With bugs we don't get to choose story points (which is exactly how it should be!) Unfortunately the range of numbers for estimates is a bit limited in Pivotal Tracker. You can only choose 1, 2, 3, 5 and 8. That's it. In our case 8 means “too big, and has to be cut into smaller stories before we start”.
We are numbering the stories and bugs ourselves, because the (long) ID's that Pivotal Tracker provides are too cumbersome to work with. And besides, they are not shown on the dashboard. (Feature request for Pivotal Tracker: add an easier auto-number system please!)
There are multiple statuses in the Current column. In the screenshot above there is one story that I (as a Product Owner) can Accept or Reject. We release multiple times per week, whenever we feel like it. So I do this every time a new version went into production. In this screenshot the top story is already accepted (green background color). Eight stories are in development (they must be Finished a.s.a.p.); four stories are ready to be delivered to production; one story was rejected and must be restarted; and one story hasn't started yet. (You can see that the name of the button is the next action to be performed on the story.)
The middle column contains our backlog. These are the items that the team is allowed to pick up at their leisure. You can see there are both reported bugs and features in this column. And some features at the bottom have not been estimated yet (showing multiple stacks of blue stripes). When a developer clicks the Start button, the story (or bug) is automatically moved to the Current column, and the name of button changes to "Finish".
The right column (Icebox) is mine, and mine only. This is where I, as a Product Owner, can organize and prioritize all my crazy ideas. I keep these in a queue until the backlog (middle part) is sufficiently emptied by the team. The team cannot touch the icebox (but they are allowed to add their own ideas for the product). You can see that most of the features in the icebox have already received a preliminary estimate from the team. (I asked for that.)
Pivotal Tracker automatically calculates the velocity of the team (upper right corner). From this velocity I can see that the items in the Current column will probably keep them busy for most of this sprint, and the features I gave them in the Backlog column are enough for at least another week. Pivotal Tracker is actually smart enough to calculate how much work can go into a sprint (based on your velocity) and automatically adds another week in the column when the story points exceed the limit.
The only real problem I have with this dashboard is that I cannot easily print it. This is a problem when I want to compare it with our physical task board. (Feature request for Pivotal Tracker: add a Print Dashboard feature please!)
I’m just showing this as an example of how our team self-organized the process and the tool into a situation that works for us. It’s a bit of Scrum, and a bit of continuous flow, and that’s fine. Note that I’m not here to promote Pivotal Tracker. But we found it’s a nice tool that matches how we like to work in this project. You may want to give it a try.