Recent activity
Subscribe to this feed
A comment on the idea "API - state change dates" in Pivotal Labs:
Thanks for the quick reply. The progress report looks great, it's almost exactly what I need, the only thing that is missing is the ability to filter stories based on the owner. I could start off with a report, and then use an api call for each story but that seems overkill, plus I'd have to screen scrape to generate a report and I'd prefer to only use the api. – sandro, on November 18, 2008 22:34
edward replied on November 18, 2008 22:02 to the idea "API - state change dates" in Pivotal Labs:
This doesn't answer your question directly, but have you seen Tracker's progress report?
http://www.pivotaltracker.com/reports...
It lets you do what I think you're looking for.
A comment on the idea "How about custom point values" in Pivotal Labs:
+1 for epics.
Someone suggested an idea that I liked: an epic is a story with arbitrary size (pt value) that can't be started.
This would be great for high level planning but prevent you from cheating the system by skipping detailed estimating. – asalant, on November 11, 2008 00:05
edward replied on November 09, 2008 21:46 to the question "Is there a demo project in Tracker for use in demoing Tracker's features to a new user and/or for training purposes? (there was in fact such a project in Tracker in the past)" in Pivotal Labs:
Greg,
There's not one available for just anyone to use, mainly because demo projects quickly get pretty messy. During demos, stories get moved all around, and after a while you have to do some work to clean it up. (In fact, I clean up my demo project after each demo). If the project were public I think it would quickly become very messy, and not a good example project.
So, for now you'd need to make your own. I like the idea, though, of the ability for Tracker to generate a dummy project on demand per user.
Marcello de Sales replied on November 04, 2008 09:59 to the idea "Sprint burndown chart" in Pivotal Labs:
Hi Heidi, could you please send to me please marcello.sales@gmail.com!!! Your example will help me a lot with my grad school research...Thanks!!!
beaner2k replied on November 04, 2008 09:13 to the idea "Sprint burndown chart" in Pivotal Labs:
A comment on the question "why can't I add attachment to icebox item?" in Pivotal Labs:
can you make it so that you can add an attachment prior to saving? – AlanEdge, on October 14, 2008 20:35
edward replied on October 14, 2008 20:34 to the question "why can't I add attachment to icebox item?" in Pivotal Labs:
A comment on the idea "Automatic change of owner upon Deliver" in Pivotal Labs:
Maybe a compromise could be to leave it in the queue, but not display the action-buttons, so that it was visually distinguished as something waiting on someone else's action -- that's something I'd like to see in the Current view for items that are not yours to act on, as well (per my other suggestion thread). – chrisw, on October 02, 2008 21:03
edward replied on October 02, 2008 20:54 to the idea "Automatic change of owner upon Deliver" in Pivotal Labs:
Got it: the change you're asking for is to just not have it be in your "my work" list after it's delivered.
I think the reasoning for the way it behaves right now is that it's partly your "job" to make sure the requester (a) knows it's ready to accept it and (b) to have a conversation with the requester as he/she is accepting in case questions/issues come up. Also, until it's accepted, it's "hanging in the balance" and Tracker doesn't really consider it done.
However, I can understand not wanting to see it any more if you're working through a long list of stories in "my work" and you want the feeling of knocking them off one by one.
A comment on the idea "Automatic change of owner upon Deliver" in Pivotal Labs:
Right, but what I mean is that if I am the owner, after I deliver something, it stays in the My Work queue, despite my not having any further work to do on it. – chrisw, on October 02, 2008 20:28
edward replied on October 02, 2008 20:17 to the idea "Automatic change of owner upon Deliver" in Pivotal Labs:
Dick replied on September 25, 2008 20:00 to the idea "Sprint burndown chart" in Pivotal Labs:
I would love a copy of the googledoc also, if you could send it over, i would appreciate it. Thanks!
Dick
dick.mcmullen@csu.mnscu.edu
edward replied on September 02, 2008 15:08 to the discussion "pivotal for fixed budget projects?" in Pivotal Labs:
Concerning deadlines: yes, Tracker lets you add a deadline to a release marker. Once you have a release with a deadline, the release will go red if you're projected not to meet the deadline; also, in the "charts" tab you can see a release burn-down chart. To set a deadline, first create a "release" story, then prioritize it in the backlog, and finally open it up and enter a deadline date.
Rob Baillie replied on August 30, 2008 16:48 to the idea "How about custom point values" in Pivotal Labs:
In fact, we'd probably like to be able to have two levels of estimation. Yup, I know, but bear with me.
Before we get into nitty gritty detail on stories we t-shirt size everything (S,M,L,XL), and then assign broad costs to those t-shirt sizes.
An iteration or two before we start a story we'll detail cost it (drill into more functional and then ultimately technical detail).
It's useful having the t-shirt cost because that costing is done en-masse as a relative complexity costing, and so that provides the team with a means of re-adjusting overall project estimates as stories are accepted.
The detail costing exercise is really just a means of getting the team talking about detail in a group so everyone knows what's coming, though those in charge of planning like to think that the detail cost is more accurate that the t-shirt (it sometimes is), and therefore have both available.
YY replied on August 22, 2008 20:20 to the idea "Sprint burndown chart" in Pivotal Labs:
Heidi replied on August 22, 2008 17:42 to the idea "Sprint burndown chart" in Pivotal Labs:
Heidi replied on July 31, 2008 01:03 to the idea "Sprint burndown chart" in Pivotal Labs:
Hi - I've seen that. It's a nice chart but it doesn't get granular enough for us to use it.
Some type of visual way to identify clogs or bottlenecks in our system is what we need so we can try to fix things during the sprint - before our sprint is over.
If we can see, for example, that a lot of stories remain each day in deliver state we can have a discussion about how to speed up our qa delivery process (which is what we use the deliver state for). So then we can try to course correct and keep things moving.
Or maybe some stories stay in accept/reject too long and we need to speed that up to get quicker feedback from our product owner. (We have one person who goes through stories in accept/reject all during the sprint).
And sometimes there is a need to add stories during a sprint. Bringing visibility to that can be really powerful since there is a cost to adding points.
We can get this type of info by looking at the Current column in tracker each day, but to be able to see this for a period of days helps us get the bigger picture so we can take action and meet the goal we set a the beginning of the sprint before it's too late.
edward replied on July 31, 2008 00:14 to the idea "Sprint burndown chart" in Pivotal Labs:
Sean marked one of edward's replies in Pivotal Labs as useful. edward replied to the idea "How about custom point values".
| next » « previous |
Loading Profile...


