ndp's dashboard

I just call it "Unstart", and yeah it happens enough that it would be nice to be able to do it with a click or two less.

I understand some of the arguments for having two columns - people like a separation between what is current and what is not. However, it is confusing and arbitrary to use *this particular UI device* to show that separation. I am guilty of submitting a bug relates to this:

http://getsatisfaction.com/pivotal/to...

Backlog currently divides up items into iterations based on velocity. But it treats the first iteration as special and moves it to another location on the screen. This creates behaviors which violate user expectation. In my case I could not drop an item into the backlog as I had expected (and the documentation supported my expectation!). Also, if I manipulate the velocity things zip from one list to the other. It is true - I understand the magic now. But the point is that choosing a different UI device to separate current from future iterations would reduce confusion and the attendant amount of explanation and/or bug reports.

I say keep a clear distinction for what is "current", but do not separate a list into two parts of the screen. There are many other ways to highlight what is current. Perhaps the current iteration can be bounded with a thick border and the word "Current" can run vertically alongside the items? Maybe the items can be shaded or have a particular background color? A little "You Are Here >" arrow would be kind of funny, but would serve the purpose. I am sure there are a boatload of ways to highlight the top of the list without beheading it.

Not really. The issue is not a misunderstanding about where the drop target is located or about "what's going on". The issue is that I want to be able to drop items in the backlog and cannot. As danp points out, this is by design. A better solution (IMHO) is to merge current and backlog as suggested in another issue (http://getsatisfaction.com/pivotal/topics/i_would_like_current_and_backlog_columns_merged_into_one). They really are part of the same list the way that Tracker treats them. – Duffy, on July 25, 2008 22:20

Perhaps this is a place where a little animation could clarify what's going on... perhaps it goes where you drop it, and the bounces into the backlog as it doesn't fit...

We're working on an API, and should have something out there within a month or so. The first version will be basic, but it should allow you to access and update story information using REST and XML or JSON.

i like the idea too! we started using Tracker after using other solutions and so Iteration #1 doesn't make sense for the first iter we're doing in Tracker.

I want to be able to import lighthouse tickets into tracker.

Ok, Tracker should notify you of new story comments now. There is a new preference for this email in 'my settings', and it's on for everyone by default.

The next release of Tracker on April 29 has updated error messages to help clarify what to do if this problem is encountered.

I've had this problem a two (or was it three?) times. It seems unfair to ask for their exact name and initials...

If it's a privacy issue, why don't you just not reveal the name and initials until the recipient accepts the project invitation.

I like this idea. Also, if you are starting a new product release it would be nice to start from 1 instead of 265!

I like having current and backlog in two columns.

Current uses your velocity to predict how much stuff you can get done in the current sprint. Anything else bubbles over to the backlog.

I think having them separate is a more obvious reminder of your velocity. If they were in one column they would just blend together.

And I like it when we get ahead of our velocity and work from the next column!

A couple thoughts:
1. We settled on using JIRA and Tracker in tandem on a couple projects, so coordination between them would be useful. On one project, we did our iteration planning in one tool (not tracker, but the same function), and then when we started the iteration, we put the stories into JIRA, each as its own task. JIRA provides workflow and commenting that tracker doesn't need. So facilitating this, coordinating IDs, automatically linking things would be nice.

2. We almost always have a Confluence wiki page backing a story or set of stories. People want somewhere to write more, upload lots of images, etc. Tracker has this, but it is more "comfortable" in a wiki, and people are just used to it. Also, often several stories have a shared wiki page, which tracker doesn't handle.

So some sort of automatic linking would be convenient... we just copy and paste URLs from the wiki into Tracker. We never have pasted tracker links into the wiki.

3. Finally, I don't think having a simple RSS feed of the current iteration would hurt. I don't mind keeping tracker up all day in a tab, but I bet some people would dig the RSS feed more.

Not at the moment, but we have custom point scales in our near term Tracker road map.

I appreciate that tracker prescribes much of the process, eliminating choices that are meaningless or problematic... so I don't feel that more point choices will make us any more productive or our estimates any better...

A couple points, though:
- zero pt stories are allowed. I wrote a separate report requesting the ability not turn this off.
- It _would_ be useful support larger pt values (13/20/40 etc.) for "epics". We've had to find out some way around this. We've used a couple techniques (unsuccessfully):
(a) don't estimate these stories until we can break them up
(b) our highest pt value is "illegal" and denotes a story that needs to be re-estimated. These are both "hacks" around the tool

It would be nice to do this the right way.

The choices are cool, but be careful. At some point at the beginning (starting the first story?) your choice of point scales is locked forevermore.