I would like current and backlog columns merged into one

Arlette, you're right that it's at least partly a terminology issue. The term "backlog" is from Scrum, where "sprint backlog" refers to the stuff that's been committed to be done this sprint (iteration). "Queue" might work better for the general (non-Scrum) audience.

But I also agree with Jonathan that the division between Current and Backlog as currently implemented is a bit confusing and appears arbitrary. And even if the two were merged, there would still be a clear line between in-progress stories and unstarted stories. Just picture the backlog working exactly like it now does, but being positioned just below the "Current" panel, not to its right, and you'll see where Jonathan's coming from.

I also see people trying to move a story in the backlog into the end of the current iteration but the story doesn't show up there it shows up at the top of the backlog, they then try to re-drag it and re-drag it and then end thinking it is a bug in tracker. When I tell them to consider them one column and that nothing else can fit into the iteration they are moving the story into so it gets pushed out, then everything clicks for them.

yeah, maybe "backlog" is confusing with scrum... "upcoming"? "scheduled?" ... you could use "past" "present" and "future" tabs...

I too have had trouble explaining the icebox (but only a little). the fact that it's prioritized like the backlog is a little counter-intuitive to its purpose (at least how i perceive it-- a repository for unprioritized stuff). It's tempting to try to maintain order there...

sure, if there were some way stories were organized there that was different than the queue, that would probably make more sense-- but what would it be? and how would people understand it? in the end i'm happy with the metaphor, love it's strengths and can live with its weaknesses.

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!

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.