Announcing Pivotal Tracker for iOS 1.5

Thursday, August 23, 2012

Today we released the latest Pivotal Tracker iOS app to the App Store. This is a major release that includes support for creating attachments, dynamic iteration calculation, and significant performance enhancements. We have also dropped support for iOS 4.x, which less than half of one-percent of our users have installed.

Add Attachments Directly From Your iPhone or iPad

Our customers who use Tracker to develop mobile apps and websites are going to love this: you can now attach photos to stories directly from the app. This makes it super easy to take a screenshot of a bug you find on your iPhone and share it with your team. We’ve been using it ourselves and it’s already our favorite feature.

In addition to attaching screenshots and other photos from your library, the app also supports taking photos directly from the app. This is a great way to capture whiteboards from meetings!

Dynamic Iteration Calculation

Iterations are now calculated dynamically within the app, allowing you to see the effects of your changes on your project’s backlog in real-time. As stories are dragged or edited, iterations will animate and change in response, allowing you to tell whether that change will delay your release or not.

In previous versions of the app, iteration information was calculated on the server and required a lengthy refresh in the app. With this release, you’ll have one less reason to wait while the app downloads the latest data from the server.

Improved Performance & Responsiveness

We’ve expended a lot of effort to ensure that every user of the app has a smooth, stutter-free experience with the app, allowing them to focus on quickly on the task at hand. To that end, our iOS app has been heavily re-engineered to take advantage of the multi-core processors on the iPhone 4S, iPad 2, and the new iPad.

The UI rendering has also been refined and optimized, resulting in velvety smooth scrolling. This should be true even for large projects!

Other Refinements

Besides the headlined items above, there are numerous small improvements we hope will make the iOS app an even more important part of your daily Tracker rituals:

The acceptance date of a story is now visible and editable, allowing users to backdate accepted stories.
The Search panel now displays an activity indicator while the project is searched for matching stories.
The Search panel is updated as changes are made, ensuring the results are always fresh and accurate.
Downloaded project data is encrypted on disk, ensuring sensitive project information isn’t compromised if the device is lost or stolen. To enable this, you must have a passcode set on your device.
Remote changes to the project are now detected more reliably, and now defaults to every 30 seconds instead of every minute. The change detection interval can be changed or disabled in the Settings app.
After dragging a story, the story is now animated into place.

The Future

Since our iOS app was first released over a year ago, our customers have taken to it quickly. In fact, more customers use the app than don’t. We’re committed to bringing all features from Tracker Web to the iOS app.

Tracker is uniquely able to provide users a “forests and the trees” view of their projects. As small changes are made in a project, Tracker is able to show the macro effects on your velocity and schedule as a result. Dynamic iteration calculation, which shows macro changes to your iterations in real-time as stories are moved, is one of the ways we’ve begun to highlight this unique aspect of Tracker.

Expect future releases to continue this trend, in particular as we begin integrating features like Epics. Stay tuned!

Airbrake – The art of fingerpointing

Ronan Dunlop

Wednesday, August 22, 2012

Airbrake is a great tool for identifying errors generated by other apps all in one place. I guess if you’re the offending app you might call it a rat, snitch, stool pigeon or fink – but to the rest of us it’s the canary in the coal mine that can save your butt.

As of today you can view Airbrake errors from within Pivotal Tracker and link activity back into Airbrake as a Tracker comment on the error it’s self.

The folks at Airbrake have explained in detail the two stage setup required to integrate Tracker with their app. Check it out here. If you’re new to Airbrake, it’s free for 30 days, so give it a try and tell us what you think.

Tracker Screencast: Shortcuts!

Charlie Springer

Monday, August 20, 2012

Shortcuts rock, make things easier, and let you move more quickly in Tracker. This screencast says it all but here’s the cheat sheet which you can get to with the ? button.

The seatbelt light’s off, you’re free to move about Tracker with your keyboard!
Wait till the end to hear about what’s coming up in shortcut development.

Tracker Screencast: Reorganize panels with multiple story selection, cloning panels, and more!

Charlie Springer

Wednesday, August 8, 2012

When you’re running East and the project goes West, it’s time to reorganize the backlog. This can be painful but Tracker comes to the rescue with multiple story selection and cloning panels. Here’s a little cheat sheet!

Dan Podsedly covered this in a blog post last year, here’s an excerpt:

To select multiple stories, use the small checkboxes to the right of story titles. If you’d like to select a range of stories, select the first story in the list, then shift-click on the last story. This will select all in the range, and allow you to drag them together, or use some of the other actions in the Stories drop-down, such as export to CSV or move to another project. Note: range select with shift-click only works in a single panel at a time, but you can select multiple ranges of stories across the whole project.

You can deselect a large number of stories in the Stories drop down menu.

Check out this short Screencast to see a demo of working with multiple stories in Tracker!

Tracker on the Agile Continuum

Marlena Compton

Tuesday, August 7, 2012

In Tracker support, I take delight in answering support requests we get from people on teams who are thinking through the way they make software and how Tracker fits into that process. Recently, a customer asked us if Tracker can support their team’s switch from a more Scrum-focused process to a more Kanban-focused process.

Typically when I get such questions, if I can’t answer them myself, I look through our Tracker blog posts or our Community forum to see if I can’t find something salient. In this case, I found very little information. Knowing that Scrum vs. Kanban is a debate happening for many of our users and, indeed, within the Agile community itself, I decided to ask the Tracker Team: what do we think about Kanban and Tracker?

Glen, a Tracker Developer, says:
“If there were a continuum between Kanban at one end and strict Scrum (per-iteration story commitment), I think that within the Tracker team we’re actually about 75% of the way toward the Kanban end. We operate much closer to “pull” than we do to commitment, letting stories ebb and flow through the Backlog, periodically refilling the Backlog with batches from the Icebox as it becomes clear that we’re getting toward the (meaningful) bottom of the current work pile. And we let releases migrate to logical times in the workflow, rather than being rigid about either their content or timing.

On the other hand, there remains significant benefit (in our opinion) to estimating stories and computing velocity. The discussions of relative complexity and difficulty that we have when we estimate stories is valuable to the team, and having a cost associated with stories and features is an important factor in whether the Product Owner decides they should be prioritized or not. And having a record of iteration velocity tells us lots of interesting things about how the team is performing–in particular, periods of significant velocity drops indicate a struggling team and signal that we should be looking for a cause and something to fix.

In short, our opinion is that you should do what Tracker does, rather than either ‘real’ Kanban or ‘real’ Scrum.”

The rest of the team agreed pretty quickly with Glen, and it’s worth decomposing his response to see how this applies to working with Tracker.

Operating closer to “pull” than to commitment with the flow of stories through the Backlog

Understanding pull vs. push is central to understanding Kanban. In her book, Leading Lean Software Development: Results are not the Point, Mary Poppendieck describes a push system as, “managed by “pushing” a predetermined plan to the operating environment and tracking task completion against that plan…You manage a pull system by managing the queues, instead of by scheduling the details of the work..” On the Tracker team, instead of deciding on a large set of stories to be completed for a release, we are constantly prioritizing new stories in our Icebox and Backlog. Because we do this, the most important tasks are always at the top and automatically get “pulled” into Current when an interation changes.

Releases migrate to logical times in the workflow, rather than being rigid about either their content or timing.

While XP and Agile brought us out of the dark ages of big-bang releases in favor of smaller, more frequent releases, there are now varying flavors of frequent releases. In XP and Scrum, releases are typically associated with the end of an iteration, but they don’t necessarily have to be. On the Tracker team, we focus on flexibility within an iteration. This is part of the logic behind Tracker’s release markers. The release markers have a date, but that date does not have to coincide with the end of an iteration, neither is the marker tied to a certain set of stories. We have Epics for that. You can read more about both Epics and Releases here.

Having seen my fair share of support tickets where people ask questions about how they should expect their releases to change when using Tracker, I asked Glen to expand on how and why the Tracker Team releases the way it does:

”Tracker’s model for deployment tries to have frequent releases but to put them into the workflow so that they come after the completion of a batch of related stories. Some development processes are rigid about when releases happen (Every two weeks on Friday!!), and either make people work late to make the release timing or have a “train” model where releases are the train leaving on a particular schedule, and features either make it or they don’t, based on the code being merge-able before some fixed pre-release cut-off time that allows for integration/regression/etc.

Scrum tends to be a rigid work-late process, and Kanban is often either continuous deployment or a “train” process (admitting that their deployment wants feature delivery to be chunked, but only at the very end of the process).

The up-side of our process is that you don’t do silly things like make ‘empty’ releases or do a release a day before a big pile of features are done, causing their becoming available to users to be artificially delayed by the fixed release interval. The down-side is that you can get into a loop where some batch of features is always a day or two from being releasable, so the ‘next’ release keeps being pushed back a couple of days every couple of days, and then maybe you forget to release for a couple of weeks (or months). And that’s bad.”

Estimating stories and computing velocity helps the Product Owner prioritize

So far, much of what I’ve written about in our process is, as Glen said, pretty close to Kanban. Our team currently diverges from Kanban by using the estimation of story points and relying on the velocity calculated by Tracker which comes out of XP and Scrum rather than relying solely on the amount of time stories take to finish. In Kanban, focus is placed solely on the amount of time it takes to implement and deliver a story. The Kanban metric, Cycle Time is calculated by looking at the time a story spends in a queue instead of estimating it. Jeff Patton explains Cycle time and how it differs from using points and velocity in his post, Kanban Development Oversimplified.

When I asked the team why we estimate points vs. calculating cyle time, their responses revealed that points estimation is one of the areas in Tracker where team discussion and participation is expected. Tracker developer, David Stevenson points out that there is more than time involved in estimating stories, “PMs should have the ability to see what things are at least ‘easy’ ‘medium’ and ‘hard’. Then they should get immediate feedback when they try to do too many hard things, by realizing that they can’t get done quickly.

Kanban’s velocity based on time treats all stories the same, which only makes sense if you have a consistent mix of easy, medium, and hard stories, and don’t care when a specific story gets done.”

Our Product Owner, Dan Podsedly, who recently wrote the Tracker blog post, Velocity Matters, also weighs in on using Velocity vs. Cycle time. “There are certainly advantages/benefits to tracking cycle time, and being able to predict how long a given item might take to get from point A to point B in the workflow. Kanban focuses on this because it’s based on assembly line manufacturing, where the important thing is to optimize station queues and reduce costly bottlenecks.

While Kanban is popular these days, modeling software development based on station-to-station car manufacturing can have negative side effects, as it can lead to more silos (stations) and lines of communications. In my opinion, Tracker forces teams to act more like teams, and work together to get stories through a simple workflow and towards acceptance (the finish line). Instead of measure how long stories take to complete, we track rate of output (of business valued features), and use that to predict future pace of output.”

And of course, as already discussed, focusing on complexity, rathering than estimating/tracking time, drives the important conversations and allows the PM to make important (prioritization) decisions early on.”

The comments reveal an important, re-curring theme within the Tracker team. We don’t get too hung up about labels such as Kanban, Scrum or even Agile. No matter which tool or process your team is using, at the end of the day, it has to be about getting the software out the door given the people you have and the resources at your disposal. At its core, Tracker is about a team of people making software, not the labels they use to describe their process. Since every team has its own context, your mileage may vary although we are obviously happy if Tracker happens to be the tool that helps you the best.

Velocity Matters

Dan Podsedly

Wednesday, August 1, 2012

Last week, we made a slight tweak to how velocity is calculated in Pivotal Tracker, to handle team strength overrides in a simpler, more explainable way. As a result, if your project has an adjusted team strength in a recent iteration, you may be seeing a slightly different velocity.

Details of how velocity is calculated, and how team strength affects it, are at the end of this post.

This seems like a good opportunity, though, to step back a bit, and revisit the velocity concept in Tracker and why it (still) matters. Read on, even if you’re an old hat to agile and Tracker!

What is Velocity?

First, let’s re-define what velocity is. Christian Niles, our iOS engineer, recently gave it an eloquent description (inspired by his recent relaxed strolls through the streets of Paris):

“Just like a speedometer that measures how fast you’re hurtling through space, Tracker’s velocity is a measurement of how fast your team completes stories. Instead of miles or kilometers per hour, Tracker expresses velocity as the number of points completed per iteration.

Because Tracker stories are assigned point values instead of due dates, Tracker calculates velocity by averaging the number of points you’ve completed over the past few iterations. In Tracker, past predicts future.”

It’s About the Conversation

Yes, velocity does give you a glimpse into the future, in the form of more realistic estimates of when milestones will be hit, at least compared to wishful due dates. It’s obviously just an approximation, though, and the velocity number itself is ultimately not very meaningful outside the context of a given project.

What’s really valuable are the conversations that story estimation encourages within development teams (and their product owners). Conversations that uncover all kinds of assumptions and hidden scope, and give the product owner the insight to make value decisions at every step (is that 5 point feature really worth it, is there a simpler alternative?), which all leads to leaner, better product, and a more direct path to the finish line.

Having a crisp, prioritized backlog of estimated stories, and a steady velocity, lets you have really constructive conversations with your stakeholders when facing that inevitable change to requirements. Dragging those new stories into the backlog gives you immediate feedback about how the scope increase will affect the future timeline and planned releases, and allows you to make tradeoff decisions (“ok, let’s move these other stories down so we can still make that milestone”).

These conversations are where all the important tactical decisions are made, and there will be many, as you keep learning as a team, and the world keeps changing on you. Each one takes you closer and closer to winning the battle (and shipping great software).

Consistency is Everything

Steady state allows you to predict, at least roughly, when your project will hit important milestones. This gives your business the ability to plan ahead and to make meaningful tradeoff decisions (usually scope vs time), as you discover more scope (and you always do). Predictability is rare in the software industry, and only comes when you get your project to that zen-like state of steady, consistent pace, measured by low volatility (of velocity).

Achieving low volatility takes an ongoing effort, but the practices that collectively yield it are worth the effort on their own merit. Break down large features into small stories (that fit into a single iteration), estimate as a team, maintain a constant ratio of features to bugs and chores every iteration, deliver stories continuously, and have your product owner highly involved, available, and accepting those stories daily.

Managing Team Fluctuations

Unless you’ve got a team of cyborgs, or perfected cloning technology, chances are there will be weeks when a big subset of the team is sick (yes, that achilles heel of pair programming), on vacation, at a conference, or it’s just the usual between the holidays lull with a skeleton crew.

The team strength feature allows you to plan for that (or account for it retroactively), in terms of velocity. For example, if half of your team leaves for a conference one iteration, you might set your the team strength of that iteration to 50%. Likewise, if your team works all weekend to prepare for launching your product, you would set the team strength to 140% (since they worked 7 days instead of a normal 5 day work week).

Check out a short video on team strength here.

You can also adjust the length of a single iteration, for situations such as the big end of year holidays. Or you can use it to effectively put your project on hold, by combining iteration length override with a team strength of 0%.

Just the Formula, Please

How velocity is calculated is fairly straightforward, it’s the sum of all ‘normalized’ points completed over a given set of iterations (based on project settings), divided by the combined length of all those iterations, in weeks. ‘Normalized’ points are the number of points the team would have completed in an iteration at 100% team strength.

velocity_per_week(iteration_1, ..., iteration_N) =
    SUM(iteration_i.points / iteration.team_strength) /
    SUM(iteration.length_in_weeks)

Iterations with a team strength of 0 are excluded from both sums.

The formula above always returns velocity per week. The project velocity Tracker displays is always multiplied by the default iteration length, and rounded down to the nearest integer. For example, if your iterations are 2-weeks long by default, Tracker will multiply the per-week velocity by 2.

Learning More

We’ve got quite lot of detailed information about velocity and related topics in the Tracker FAQ, as well as the Getting Started guide. In particular, take a few minutes to watch the Introduction to the Concepts video.

If something still isn’t clear, give us a shout!

p.s. thanks to Richard Jones for the awesome Millenium Falcon pic. we want one!

Screencast: The current, the backlog, together again!

Charlie Springer

Monday, July 30, 2012

Today’s screencast is about understanding workflow in Tracker, with a twist of organization.

The Current panel shows you all of the stories your team is working on this week or “iteration”, including those that are in progress, as well as stories that Tracker thinks you’re going to get done based on velocity. As you’ve probably noticed, stories will jump from Current to the Backlog automatically as you move stories around, estimate them, etc.

If you prefer to see and think of the current iteration and the rest of the backlog as one continuous thing, you can combine them! Check out the screencast below, or just do the following:

Sign into Tracker
Open up your Profile
Scroll down to Project Page Preferences and check the ‘Include Current in Backlog’ checkbox
Head into your Project

Pivotal Tracker maintenance this Friday, July 27 at 8pm PDT

Dan Podsedly

Thursday, July 26, 2012

We’re planning to make a number of server upgrades tomorrow that require a bit of downtime. To minimize disruption, this update will happen after hours tomorrow, Friday, July 27, at 8pm US Pacific (PDT) time, and we anticipate it taking approximately one hour.

Please accept our apologies in advance for any inconvenience. To get the latest updates, and real time status of this maintenance, please follow @pivotaltracker on Twitter.

Zapier – A nifty Matchmaker for Apps

Ronan Dunlop

Wednesday, July 25, 2012

When it comes to app match ups no-one does it cleaner than Zapier. The way I see it, they’re the bread that surrounds a PB&J sandwich. Sure the good stuff is in the middle, but you wouldn’t be able to enjoy it without getting your fingers dirty if it weren’t for the bread.

As Zapier puts it, they make it easy to sync data between web apps; what’s more they can do this now with over 50 apps including Pivotal Tracker, Zendesk, Github, Wufoo, Mailchimp and Google this that and the other to name drop a few. Read more about their Pivotal Tracker integration.

The entire experience is drag and drop. The functionality is straightforward “if this then that”, or as Zapier calls it, Triggers leading to Actions. Plans range from Free to I need to think about this.

Working on multiple projects? Velocity got you down?

Charlie Springer

Thursday, July 5, 2012

The Tracker Team gets some variation of this question a lot:
“I work on one project one week and a different one another week and it’s really throwing off our project’s velocity. Is there something we can do to account for the changes in team strength?”

Check out this short screencast on how to account for those missing team members and adjust velocity on the fly.

I received this question from one of our recent surveys; if you respond to a survey in the future, leave your contact info so we can get back with you!

-Charlie out.