Inability to drop to Backlog is annoying
Tracker tries to be too clever. I originally submitted a bug report because I found it impossible to drag items to the Backlog. But the bug was already closed with the explanation that this is the intended behavior.
First: Your documentation reports that dropping things in the backlog is permitted. If you maintain this behavior you should know about that inconsistency. Please see https://www.pivotaltracker.com/web/he...:
"The Backlog holds prioritized Stories. The order here does matter - Stories at the top of the backlog are the most important, and will be worked on by the team earliest. To prioritize a new Story, drag it from the Icebox to an appropriate place in the Backlog or the Current Iteration. If the Backlog is empty, drag the Story to the top of the Backlog panel."
Second: I am unlikely to use a tool that holds my feet to the fire over someone else's idea about process. It is neat that you autogenerate iterations/releases. However, if I feel I'm being restrained from pushing things around where I want them I will probably stop using the tool. I like the interface and the general concept, but an application that is "too clever" is going to displease people like myself who occasionally see fit to do things the plain old unclever way.
Just my $.02. Generally a good tool.
First: Your documentation reports that dropping things in the backlog is permitted. If you maintain this behavior you should know about that inconsistency. Please see https://www.pivotaltracker.com/web/he...:
"The Backlog holds prioritized Stories. The order here does matter - Stories at the top of the backlog are the most important, and will be worked on by the team earliest. To prioritize a new Story, drag it from the Icebox to an appropriate place in the Backlog or the Current Iteration. If the Backlog is empty, drag the Story to the top of the Backlog panel."
Second: I am unlikely to use a tool that holds my feet to the fire over someone else's idea about process. It is neat that you autogenerate iterations/releases. However, if I feel I'm being restrained from pushing things around where I want them I will probably stop using the tool. I like the interface and the general concept, but an application that is "too clever" is going to displease people like myself who occasionally see fit to do things the plain old unclever way.
Just my $.02. Generally a good tool.
1
person likes this idea
I like this idea!
Tell me when this idea gets some attention.
The more people who like this idea, the more it gets noticed.
The more people who like this idea, the more it gets noticed.
-
Inappropriate?Are you maybe talking about the fact that the drop-zone in the back log is hard to see? you have 100 pixels or so of space that a story can be dragged into.
This area should really be more clear ---> I'm thinking it should by styled with a dotted line around the area and the words "drop zone" -
Nope. I was really talking about the fact that you cannot drop to an empty Backlog. -
Thanks for clarifying ... you just need to estimate your stories or make more stories. -
Inappropriate?Disclaimer: I know Duffy :)
This may be confusing, but Dan explains the justification pretty well in the closed bug: "Think of the current iteration as a view of the top of the backlog. Tracker automatically moves stories from the backlog to the current iteration, until the current iteration "fills up" based on the initial velocity of your project, and story estimates."
In other words, you can complete as many stories in your current iteration as your velocity says you can. Say your velocity is 10, and you only have 5 stories in your current iteration. If you drag a story to the top of the backlog (or to an empty backlog), then that story will automatically go to the current iteration. Otherwise, what are you going to do with those extra 5 points of velocity? Drink beer on Thursday and Friday (which I'm in favor of)? Seriously, though, if the real reason you don't want it in the current iteration is because you don't EXPECT to get 10 points of velocity (maybe people are on vacation), then the correct way to deal with that is to adjust your velocity for the current iteration (which Tracker lets you do).
Perhaps you saw this as a problem because your backlog was empty (which never happens after a project is past the first planning session), or you did not have all your stories estimated (which would have filled up your current iteration to velocity)?
-- Chad -
Inappropriate?Thanks for the rapid response, Chad. :)
I think, given your assumptions about the types of project Pivotal Tracker users will be handling, that your and Dan's responses are fine. Really I must admit that I am likely an outlier in your userbase. I cannot afford to pick up a "by the book" process. The leniency I am urging in Tracker is aimed at accommodating cases that might be unique to my environment, though perhaps others will see the value as well.
An example (the one that brought me here):
I am working on a federated identity project between the three Arizona state universities: U of A, Arizona State (ASU) and Northern Arizona U (NAU). I can plan implementation only to a certain point. Beyond that point I'm waiting for the other universities to complete tasks. Those user stories that await ASU and NAU participation cannot yet be estimated and cannot be prematurely addressed (ie. even if they are high priority I cannot address them in the current iteration even if I have not maxed my velocity). So yes! I want to knock off early and drink on Thursday! But I don't want it to affect my velocity. I am still able to do X points in Y timeframe. Y just didn't include Thursday and Friday this week.
Ok, so I'm just weird. I can accept that :) To move forward I can use the Icebox the way other tools use their Backlog - its a place user stories hang out when they can't yet be scheduled. This is different than the use your documentation suggests, but so be it. However, I would still urge that "clever" features be added cautiously. Automatic movement of user stories into Current from the Backlog is nice if my process can accommodate that. But since mine cannot I want the discretion to keep Backlog and Current separate (really they could just be collapsed into one list, no?). I guess I'm saying I'd rather have iteration projections and the attendant shifts between those two queues as "suggestions" not automatic actions.
Alright, that's my crazy as a bedbug "what about myyyy feature???" rant. I still dig the tool!!
I’m a cantankerous user
Loading Profile...



EMPLOYEE

