We've added Zendesk to the list of applications that Tracker integrates with. Zendesk is a "beautifully simple", on demand customer support help desk system. This integration allows your development team to prioritize and collaborate around Zendesk tickets as linked Tracker stories, bringing development and support closer together in your organization.
This Pivotal Tracker update allows you to see GitHub or other SCM commits in your stories, your project activity in your team's Campfire chat room, and introduces the first wave of integrations with other bug/issue tracking applications including JIRA, Lighthouse, and Satisfaction.
There is also a new version of the API (V3), with support for moving stories, file attachments, as well as activity web hooks. The first version of the API (V1) is no longer available.
Continue reading for more details on what's new.
The Pivotal Tracker API has now been available for just over a year, and we're really pleased with the rich variety of tools and applications that our user community has built with it, to extend Tracker's functionality. There are now integration tools, wrappers for various programming languages, mobile apps, an IRC console, and many more on the way (see the 3rd party tools page for a comprehensive list).
We're continuing to improve the API based on your feedback. Recently, we've added the ability to create projects, manage project members, and search for stories based on created and last modified dates. For the next API release, we're adding ability to move a story relative to another story, add file attachments, and get current project velocity and all labels. We're also adding support for Github post-commit hooks, so you can do things like "finishes #123456" in your commit messages.
The most exciting new feature that we're working on, though, is a push webhook, which will allow your applications to listen to activity in your Tracker project(s). You'll be able to register a URL, per project, to which Tracker will post all story changes to (as XML). With this webhook, we're hoping to enable a whole new class of 3rd party tools and applications, for example to facilitate 2 way integration with bug tools.
Most of these enhancements will be part of a new version of the API (V3), which we hope to have ready at the end of the year. As part of this release, we will also be turning off the first version of the API (V1), so if you're still using that version, you'll need to update your client code to V2 prior to that. V2 is the current version, documented on the [API Help page]. For the exact date of this release, watch this blog, or follow @pivotaltracker.
As always, your feedback is welcome. If you have ideas for other things that would be useful to add to the API, or have built a tool you'd like to share, let us know!
dan
We've made some minor changes to Pivotal Tracker this week, and added a few new features. As always, we look forward to you feedback on Satisfaction.
Ability to Override Length of an Iteration
Teams that use longer iterations occasionally run into situations where a particular iteration needs to be of a different length than the rest. One example is a Scrum team, running 3 weeks sprints, that decides to cancel a sprint in the second week. To keep Tracker iterations aligned with real-world cycles/springs, it's now possible to override how long a particular iteration is or will be, in # of weeks.
Click on the iteration start date to override it's length, or revert an override. An iteration's date range will appear in yellow if it's been overridden. Also, Tracker will automatically adjust how many points worth of stories fit into a longer (or shorter) iteration.
Explicit Project Start Date
Normally, the first iteration of a project begins the week of the date of the first accepted story. For multi-week iterations, it's sometimes desirable to specify exactly when the project started. You can now do this, using the Start Date field in your project settings.
If a start date is specified, your project will start on that day, or the date of the first accepted story, whichever is earlier.
Preview Balloon for Story Descriptions
Based on popular demand, the preview balloon is back for stories that have a description (but no comments). Note - you can see a preview for all stories by hovering over the story type and estimate icons.
Story Labels on the Left
We've moved the story labels back to the left of story titles. The motivation for moving the labels to the right (in the previous release) was to align story titles vertically, for easier visual scanning. However, we received a lot of feedback that this made it harder to see groups of related stories, for which labels are commonly used for.
We may introduce a way to either hide labels, or configure where they appear, but for the time being, we've moved them back where they used to be.
Enhanced Project Export
It's now possible to export a subset of the stories in your project, by choosing whether to include done stories, stories in current/backlog, or the icebox.
Current Day in Points Breakdown Chart
The points breakdown chart now includes data for the current day. Previous day counts are all based on a nightly snapshot, but the current day counts reflect the current state of the project.
We've added a new report feature to Pivotal Tracker, to help you analyze how smoothly your project is progressing. It's based on this popular idea, shared in our Get Satisfaction powered support community.
These new Points Breakdown charts help you visualize the progress of your project as stories move through different stages of completion. Stories start out as "Unstarted", then move on to "Started", "Finished", "Delivered", and then "Accepted" (unless they get rejected). The different colored bars show the point totals of the stories that are in each state at the end of each day. As days pass, you would expect the number of unstarted to go down, and the number of accepted to go up. If any of the other groups are especially big, the chart may help you identify bottlenecks in your workflow.
This breakdown is available for both the current iteration and the previous one. You can also use it to visualize the development of your entire project for the last 15, 30, or 60 days.
To access the Points Breakdown charts, click the Reports link on top of the page, or navigate from your project via the Reports option in the View menu.
At Pivotal Labs, we like to keep our Tracker stories as small as possible, so that each story describes a single, concrete feature that delivers incremental value to our project's customer. With small stories, there is rarely a need to break things down further, but sometimes it's still useful to keep a to-do list while working on a story. This helps keep track of all the little things you have to do, and lets everyone else on the project know exactly what's left.
To enable story tasks for your project, go to project settings, and check the 'enable tasks' option under Experimental. You should then be able to add tasks to stories, under the description field. Hover over a task to edit it, delete it, or move it up and down. You can also check off a task when it's complete, but task status does not affect overall story status.
Story tasks can be viewed and updated via the API.
As always, we look forward to your feedback. If story tasks are popular, we'll enable them for all projects, by default.
On Tuesday, July 21st, we're hosting "An evening with Palm's webOS" here at Pivotal Labs. Mitch Allen, Software CTO & author of the forthcoming book Palm webOS, and Jesse McDonald, Sr. Manager, Mojo Framework, of Palm, Inc., and I will be speaking. There will be some good introduction material from Palm and I'll be talking about Pivotal's experience developing for this new platform.
It's no secret we're fans of Palm's webOS and it's Mojo framework. We've been quoted often over the past few months about how productive the development environment is, especially for those familiar with web development tools & technologies. Over the past few months we have developed four applications that are currently available in Palm's App Catalog: Mobile by Citysearch, AP News, LikeMe, and Tweed, a client for Twitter.
We previewed Pockets, a set of code for helping with test-driven development, and Jasmine, our JavaScript testing framework in an O'Reilly Media webcast this week- it was well attended & received. Thanks!
Now that Palm has opened up SDK access to everyone, it's a great time to come learn what the fuss is all about and talk one-on-one with Palm engineers & Pivots about how to get started with webOS and Mojo.
Please register for & come to An evening with Palm's webOS. See you Tuesday!
Next Tuesday, July 14, at 10pm PST, Chris Sepulveda from Pivotal Labs will be broadcasting an O'Reilly WebCast on automated unit testing with the Palm Mojo SDK. Developer testing is at the heart of Pivotal Labs's development practices, and we're excited to be involved in bringing testing to Mojo development. The WebCast will cover the following:
- Introduce BDD & Jasmine
- Installing Jasmine & add related code to the app to support BDD
- Discuss how to write a failing test first, then add functionality to make a test pass
- Develop a simple webOS application test first, with the Mojo SDK
There's more information about the WebCast on webOSHelp.net.
Date: Tuesday, July 14th at 10 am PT
Price: Free
Duration: Approximately 60 minutes
To register: http://oreilly.com/go/palmmojo
We've added some new features to Pivotal Tracker.
Activity Feed
There is a new activity feed on the dashboard. The feed lets you quickly view recent events that have occurred in all your projects including new stories, comments and stories that have been accepted and rejected. You can subscribe to this activity feed using any blog reader that supports Atom. Click the Subscribe link above the feed or the feed icon in the browser address bar and your browser should handle the rest. Recent activity data is also available via the API.
Project Velocity on Dashboard
Another new feature on the dashboard is a small graph that shows the number of points accepted per iteration. The current velocity for each project is also displayed. If you hover over a project, you'll see links to some of the more commonly used project pages, including members and settings.
Improved Project History
The project history panel should now be more readable. Event timestamps are relative now (for example, "2 hours ago"), and updates to the same story within a short period of time together are bundled together. For example, if you add a new story, and immediately move it to the backlog, this will appear as one entry in the project history. You can also subscribe to a project's history feed by clicking on the feed icon in the browser's address bar.
Follow your project on Twitter
To give even more visibility to the activity on your project, Tracker can now tweet project updates. Create a Twitter account for your project (or choose an existing Twitter account), and configure your Tracker project's Twitter account settings on the Project Settings page. Remember - by default, Twitter accounts and tweets are public and searchable, so if you want to keep your project information private, make sure you enable the "protect my updates" option in your Twitter account settings.
Remember Me
If you select the "remember me" checkbox on the sign-in page, Tracker will do just that and you won't need to sign in again after re-opening your browser. To clear this "remembered" state, log out or clear your browser cookies. Resetting your password will reset "remember me" on all computers where you have previously signed in.
Time Zones
Tracker now supports time zones, allowing you to see all dates in your local time zone, and giving all project members a consistent view of iteration boundaries. Every user has a default time zone (based on what your browser tells us), but it can be overriden on the My Profile page. Projects have time zones as well - this defaults to the time zone of the user who created it, but can be changed as well, in project settings. The project's time zone controls when iteration boundaries occur. If a project's iterations start on Mondays, and it's time zone is PST, that means new iterations will start Mondays at midnight PST, and everyone in the world, will see the new iteration at that same time, even though they may be in different time zones. Someone in New York, for example, won't see a new iteration until 3am their time.
More information about what's new is available on the Pivotal Tracker recent updates pahge.
At Pivotal Labs we take Continuous Integration (CI) seriously. Every project has a dedicated machine that serves as a CI environment. Each checkin on the project causes a build to be kicked off. A "build" means checking out the code from scratch and running of all the project's tests, which, for a Rails project, means unit and functional tests, JavaScript tests and Selenium tests. For the JavaScript and Selenium tests, we run multiple browsers on multiple OS's (e.g. IE 7 on Windows XP, FF 3 on OS X, etc).
We consider it critically important to keep each project's build green (i.e. successful) at all times. A build is the heartbeat of the project: if it's green, everything is healthy; if it turns red (i.e. fails), the team is encouraged to jump on the problem and get it back to green right away. We want red builds to go away quickly; the longer a build stays red, the longer it takes to track down the problem and the more likely it is that additional tests will be broken (the "broken windows effect").
In order to facilitate this level of discipline, we've learned over the years that making the status of our CI environments obvious and visible to the team is critical. If a team isn't acutely aware of the status of its build, it's unlikely that a red build will get noticed and fixed quickly. You can have the CI server email the team, but that doesn't work very well when the whole team is pairing all day: it might be a few hours before someone notices the email. You can install plugins in your browser or system tray that show build status, which helps, but still, they're not always obvious enough. The best way we've found to keep the team informed is to display the status of the build high on a wall near the team as a big red or green indicator. That way, even when you're busy coding, it's easy to notice the build going red. These days we use 2 wide screen TVs, positioned in the office so that one is easily seen from any developer station.