danp's dashboard

Hi...anyone who is a member of a project can accept stories, or make other changes. We made it this way in order to encourage collective (team) ownership, and to make Tracker as easy to use as a shared whiteboard of story index cards. You can use project history, though, to see who accepted a given story.

Hi, thanks!

We're actually about to start work on an integration framework (using the API) that will make integrating Tracker with various bug/issue management tools and community support forums easier, both for developers and end users. Satisfaction makes a lot of sense to integrate with, so watch for progress on this.

In the meantime, you could actually write an app that that used the existing Satisfaction and Tracker's APIs to automatically "push" new problem reports in to Tracker. There are some examples here:

http://www.pivotaltracker.com/help/th...

Hi...generally, we try to align "projects" with stable teams, in order to have predictable velocity. Flip is the potential for projects to get very large, and hard to manage. One approach is to maintain a Tracker backlog for a few months out only (or the next couple of releases), and keep longer-range plans outside, for example in a shared spreadsheet, which allows you to react more easily as business priorities change. Also, labels can be very helpful to keep track of related stories - we use them quite extensively.

hi, you can use UTF8 characters, but Tracker doesn't support other languages, yet. we're really hoping to tackle that at some point in the next year.

hi...this will be fixed in the next release, which will most likely be sometime this week.

hey Chris...in case you don't see the Twitter reply, your current iteration is set to be 3 week long (that's why the date range label is yellow). click on it to change (or revert) the 3 week override.

capacity calculation takes iteration length into consideration.

The search results panel shows a point total at the top, as well as the # that have been completed.

Every project is different, but we've found that project planning at the team level is more effective than managing/allocating individuals on the team. Stable teams tend to have fairly predictable velocity, and with a prioritized backlog of estimated stories, work allocation happens without any overhead (people grab stories as they free up).

Sorry about that, it was an issue at our hosting provider, but it's been resolved.

Hi Alex, stories don't actually have a started_at time. The info is available in story history, but we haven't exposed that via the API yet. We hope to in the near future.

thanks
dan

hey Scott...it's a common issue on long-term projects. here are some approaches:

- use labels liberally to organize, for helping to find stories (and you can use the Labels & Searches panel more)
- do an occasional icebox cleanup. commonly, if a story has been sitting in the icebox for a while, it's very likely to stay there forever. chances are it's better to just write new stories if/when the given feature comes up again.
- once you clean up the icebox, get in the habit of reviewing stories that get added regularly. if the story is important, put it in the backlog. if it isn't, ask yourself whether there is any point in putting it in the icebox at all.

dan

Hi, unfortunately you can only export up to 400 at a time at the moment. One way to work around this is to use search to choose specific stories to export, then "select all", and use the Actions dropdown to export those specific stories.

Also, it's possible to use the API to pull out story data, but you'll need to write a bit of code to do that.

We hope to increase the # of stories that can be exported in the future, sorry about the inconvenience. If this is a blocker for you, please email us (tracker at pivotallabs.com), and we'd be happy to do a custom export for you.

thanks
dan

Hi, to deal with sprints/iterations that are unusual, for example vacations, you can use the team strength feature:

http://www.pivotaltracker.com/help#wh...

By default, team strength is 100% for each iteration, but it can be adjusted. For example, if your team is at 50% that iteration, Tracker will assume it can complete half the project's velocty.

Also, independently, you can adjust a given iteration's length, if you decided to extend or shorten a particular sprint. More about that here:

http://www.pivotaltracker.com/help#is...

Let us know if you need any further help.

Hi, if your iteration has rolled over (to the next one), your accepted stories will be in the Done panel. If they are not there, please send us your project ID and we'll take a look.

Hi Morgan...thanks for reporting this. I did find an accepted story for this bug from a year ago, but it either got re-introduced, or we didn't verify it properly at the time. It's related to Andy not having an email address, somehow. In any case, we'll fix it right away.

To get stories in the icebox, use a filter, with state:unscheduled.

http://www.pivotaltracker.com/help/ap...

Sorry, we should have updated this thread. The API does support getting stories by iteration, and/or the different "groups" (done/backlog/current). More info here:

http://www.pivotaltracker.com/help/ap...

Hi David, we don't currently have plans for a Mylun connector, but we are starting to think about various tool integrations. In the meantime, it may be possible for you to build something like this, using the Tracker API.

Hi, sorry for the inconvenience, but this is an unscheduled down time, and required to address an urgent issue. We anticipate it to be fairly short.

Hi, thanks for letting us know, we're investigating. We have a theory as to why this might be happening, related to a recent API change.

Hi,

We like to think of stories as a placeholder for an on-going conversation, and encourage developers to communicate with product owners often, especially just prior to starting a story. In general, we try to break every feature/requirement down into small, concise stories, where each builds on existing functionality, and adds business value to the product incrementally. It's the process of breaking larger features down into small stories that uncovers a lot of the detail. Also, since requirements tend to change, we find it easier to keep up by having the backlog of stories act as the knowledge of current requirements, rather than separate, static requirements documents that need to be kept in sync with a changing reality.

Nevertheless, it is still useful at times to link from stories to external resources such as style guides, interactive mockups, etc. We use the description field and/or comments for this.

The "deliver" action in the story workflow is used to communicate that the implementation of a given story has been deployed to some environment (demo/staging/QA), where the product owner can verify that it meets requirements, and works as expected. The primary focus here is on early customer feedback, but this verification and acceptance step could encompass quality as well, and QA could essentially play the role of an extended customer. The Tracker story workflow does not explicitly support QA verification as a separate step, but for teams that do have that need, it's possible to use labels for additional workflow steps (for example "ready for QA", "QA verified", etc). In the future, we hope to add the ability to add custom story workflow steps.

Hopefully this will help, and sorry it took so long for us to respond to your question.