pWidget is a new 3rd party tool for Pivotal Tracker. It’s an embeddable widget, that can be shown in any iframe, and shows stories from multiple projects. Configure it via URL params to show stories matching a search result, from specific projects, in label-specific priority order, and more!
Check out the pWidget page for more details.
For other helpful tools, see the Tracker 3rd party tools directory, and subscribe to the RSS feed to stay on top of new ones as they’re added.
The next San Francisco Tracker User Group (SF.TUG) meetup will be on Wednesday, September 28, at 6:30pm, in the Pivotal Labs office in San Francisco.
If you’re new to Tracker, or could use a refresher, this is your chance to get an introduction. It’s also a great to chance for more advanced users to give direct feedback, or ask all those difficult questions (e.g. just how do I organize that rapidly growing engineering team?)
There’s also a secret agenda for this meetup. We’d like to get your feedback and discuss a big feature that’s under development – Epics, designed to address a range of needs and scenarios from coarse-grained user interface design, to easy-to-digest team visibility of large features. Come and get a sneak preview!
Beverages and light snacks will be provided.
We’ve just published a new video that introduces the concepts behind Pivotal Tracker. It talks about the agile process that works best with Tracker, including story breakdown and estimation, prioritization, and workflow. If you’re new to Tracker, or would like to make sure you’re getting the most of out of the tool, this should be 8 minutes well spent!
Happy Friday! We’ve just rolled out some changes to Pivotal Tracker, which we’re hoping will have a very noticeable impact on usability, especially for those of you who manage large projects. You can now select multiple stories with a few clicks, using shift-click, and drag them together to a new location. Also, iPad usability has been greatly improved – for example, story panels can now be scrolled with one finger, and you can move stories via drag and drop
Changing business priorities on large projects has always been a bit painful for us, having to drag stories one by one. Cloning panels helps with this, but really, what we’ve always wanted to do is just select a whole group of stories, and drop them in their new place in the backlog or the icebox with one action. You can now do this, and it’s even possible to drag stories that are in-progress to the backlog or icebox and it just does the right thing (un-starts them).
Click on the screenshot above to see a larger version.
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.
The Stories drop-down menu has been changed – it now shows the number of selected stories more prominently, and we’ve removed the old bulk story move actions (move to icebox, etc), since this is now possible (and easier) with drag and drop. Note – the Stories menu allows you to unselect all selected stories, which can be useful if you’re moving a lot of stories around in steps.
Note: We realize the that the checkboxes are a bit small, and hard to click on – we’ll be addressing that in an upcoming release. Also, in certain panels and/or browsers, shift-clicking on a checkbox highlights text on the page, we’ll be fixing that as well.
We’ve addressed most of the major usability issues on the iPad, and Tracker (the web application) now supports one-touch scrolling of panels, drag and drop, easier expanding and collapsing of stories, and displays properly in both orientations.
In horizontal orientation, you can see up to 3 panels at one time, and 2 panels in vertical orientation. But, you can open others, and the panel section will slide sideways to reveal newly opened ones. Dragging sideways will move the panels left and right.
To drag a story, touch it for a brief moment, until it turns yellow, then drag it.
One of the reasons that all these usability changes were possible, and fairly easy, is because we’ve changed the underlying drag and drop library that Tracker uses. We’ve tried to test thoroughly, and there are some minor issues, but there is fairly good chance that you’ll find some as well. Please let us know, by email to tracker@pivotallabs.com, in the comments here, or over at Twitter.
We’d love your feedback on these changes. There are more new features lined up!
Last month at IxDA Interaction 11, we hosted an evening in our office in Boulder full of food, drink and discussion, to bring some of our learnings around Lean User Experience to the larger design community, and in particular to attendees of the annual international IxDA conference.
We had such a great time with it, and started so many great conversations, that we decided we had to do it again at SXSW. This Saturday, at Adaptive Path Austin, from 6-9pm, we’re hosting deLUX REdux, and you’re all invited. (Register at Eventbrite.)
Since we’ve been working with Eric Ries on his Lean Startup track this Saturday, we thought an event Saturday evening was a great way to share what we’ve learned with a wider community. And since we’re on the topic, why don’t you come see our own Parker Thompson on a panel with Eric at 9:30a, and join Janice Fraser from LUXr and myself on a panel at 12:30p with Dave McClure and Laura Klein.
So what is the event all about?
For the past year, we’ve been sharing ideas and discussing new ways to approach design and product development, to create better products, make happier customers, and reduce waste. We’ve been doing this while creating better integrated, more collaborative, more responsive teams. In that time, a number of us have been getting together on a regular basis to really sit down and discuss what works and what doesn’t, and to try to distill these ideas into principles and techniques that are repeatable and practical.
We’ve been itching to engage with the larger design community to start to break down the culture of Big Upfront Design, the Cult of the Rockstar Designer, and the culture of necessary infallability; to fight the blind application of Waterfall and to disrupt the antipatterns we’ve found so antithetical to effective collaboration with agile development teams; to encourage patterns that allow designers to embrace early customer feedback, and to test hypotheses quickly; and most importantly, to foster a deeper collaboration with the very folks who have the biggest impact on what we build. We’ve seen over and over that, when done correctly, a light-weight process gives designers more control, not less.
It’s out of this series of discussions that I first arrived at a framing of the problem space that I talk about in Enough Design, and it’s also through these sessions that we’ve found a growing community of designers, product people, enterprises and other developers who are working to develop better techniques for integrated product development. We’ve found the conversation immensely valuable in our practice, and we hope to learn and share with more of you.
So if you’re a designer in Austin for SXSW, or just someone who cares about usable techniques for bringing Lean principles into the development of compelling User Experience, come join us on Saturday for deLUX REdux. This is a free event, but space is limited, so please RSVP through Eventbrite.
Thanks so much to Adaptive Path for sharing their Austin office with us, and to everyone at LUXr, Hot Studio, Sidereel, Cooper, IDEO and the Balanaced Team for their help making this happen.
This Friday at Pivotal Labs Boulder, we’re hosting an evening of food, drink and discussion, to bring some of our learnings around Lean User Experience to the larger design community, and in particular to attendees of the annual international IxDA conference.
We, in this case, is a group of smart folks I’ve had the privilege to work with over the past year, a working group called the Balanced Team. This particular event is the result of the hard work of people at Cooper, Hot Studio, LUXr, SideReel and Atomic Object.
For the past year, we’ve been sharing ideas and discussing new ways to approach design and product development, to create better products, make happier customers, and reduce waste. We’ve been doing this while creating better integrated, more collaborative, more responsive teams. In that time, a number of us have been getting together on a regular basis to really sit down and discuss what works and what doesn’t, and to try to distill these ideas into principles and techniques that are repeatable and practical.
We’ve been itching to engage with the larger design community to start to break down the culture of Big Upfront Design, the Cult of the Rockstar Designer, and the culture of necessary infallability; to fight the blind application of Waterfall and to disrupt the antipatterns we’ve found so antithetical to effective collaboration with agile development teams; to encourage patterns that allow designers to embrace early customer feedback, and to test hypotheses quickly; and most importantly, to foster a deeper collaboration with the very folks who have the biggest impact on what we build. We’ve seen over and over that, when done correctly, a light-weight process gives designers more control, not less.
It’s out of this series of discussions that I first arrived at a framing of the problem space that I talk about in Enough Design, and it’s also through these sessions that we’ve found a growing community of designers, product people, enterprises and other developers who are working to develop better techniques for integrated product development. We’ve found the conversation immensely valuable in our practice, and we hope to learn and share with more of you.
If you’re a designer in Boulder for IxDA, or just someone who cares about usable techniques for bringing Lean principles into the development of compelling User Experience, come join us on Friday for deLUX. This is a free event, but space is limited, so please RSVP through http://pivotallabs.com/landing/deLUX.
Pivotal Tracker makes it easy to add stories to you project. Hit Ctrl-A, type a quick sentence along the lines of “As a user, I can…so that…”. On most of our projects, we find ourselves discovering new stories all the time, based on the continuous feedback loop that Tracker encourages. Not all stories end up in the backlog, but it’s liberating to be able to capture new ideas and user feedback as they occur.
The downside of this is that the icebox, where all new and unprioritized stories live, can grow out of control very quickly. It’s not uncommon for longer lived, active projects to end up with hundreds, even thousands of stories on ice.
A large and growing icebox can be a burden. Your project takes longer to load, it’s harder to find that story you’re sure you added just a few weeks ago. It becomes harder to focus on the future, due to what feels like ever growing debt of promises and yesterday’s priorities.
In our eternal optimism as software developers, we like to hang on to our stories. We know we’ll have more bandwidth just as soon as we get through this month’s big release. Besides, we’re hiring, right?
The reality is that on most software projects, the rate of new story discovery far exceeds the rate at which stories get completed. Typically, a new story in the icebox either gets prioritized and moved to the backlog fairly quickly (either immediately or in the next planning session), or it ends up staying in the Icebox indefinitely. New priorities have a way of displacing older ones.
Stories are perishable, and get stale over time, even when on ice (so to speak). It’s good practice to clean up your icebox regularly, and delete stories that have been sitting there for a while, and are unlikely to see the light of day any time soon. The old stories may have seemed really important at some point in the past, and involved the whole team spending hours in front of a whiteboard or a table full of cards writing them, but if the feature becomes a priority again in the future, you’re probably better off doing it again, based on all the new knowledge you’ll have by then. The important thing is the conversation and a fresh flow of ideas, not so much the stories themselves.
To preserve the ideas and any comment discussion in these old stories, it’s a good idea to export them before deleting them. You can do so by selecting them in the icebox via the selection boxes to the right of story titles, and using the Actions menu to export them. You can also export the entire icebox on the project Export CSV page, which is accessible via the Actions menu in your project.
Another option is to move old icebox stories from your active project to a separate project, which serves as a searchable archive. You can move stories from one project to another via the Actions menu as well.
We typically keep exported old stories in a Google Docs spreadsheet, shared with the entire development team. The flexibility of a spreadsheet makes it possible to slice and organize the stories in arbitrary ways, and the shared nature of Google Docs make it easy to for anyone on the team to go back and look for ideas from the past, even to re-import selected stories back into your Tracker project if it’s really needed.Use the Icebox as an inbox, for continuous review of new stories, rather than a permanent storage device. As new ideas, feature requests, and bugs come in, triage them regularly. If a new story is really important, for example a production bug, you’ll probably drag it into the backlog immediately. Otherwise, review newly created stories with the team at the next iteration review and planning session, and either estimate them and prioritize them (by dragging them to the backlog), or move them into a system better suited for long term storage, like a Google Docs spreadsheet or a more general purpose project management or issue tracking tool, like JIRA or Lighthouse. Tracker has built-in integrations with these tools, allowing you to bring back and link stories easily with drag and drop import.
Three interesting new user-contributed Pivotal Tracker tools have been added to the growing 3rd party tools list this week:
From vizio360, this is a Google Chrome extension that allows you to visualize your current iteration as a card wall, with columns for each story state.
Adds a slide out panel to your rails app that directs clients to test stories that have been marked as ‘delivered’ in Pivotal Tracker. Thanks to PLUS2 for this one.
Text-based tool for tracking story completion per-user on Pivotal Tracker, from Joshua Szmajda.
We’re looking forward to trying these on some of our own projects at Pivotal. Thanks to everyone who’s shared their work with the Tracker user community so far, and let us know if you’ve written something new that you’d like to share.
I often hear questions from Pivotal Tracker users about how to organize teams and projects. We also see many requests for features that would make it easier to see stories from across multiple projects.
Tracker is designed for full immersion in one project at a given time. This stems from how we work at Pivotal Labs.
We organize teams such that a single team (and the people on that team) have a single backlog (and Tracker project). This means that within a team, there are no conflicts in terms of priorities, there is less context switching, and the team is completely focused. It leads to more consistency from iteration to iteration and therefore a steadier velocity, which allows you to have a more accurate insight into how long the rest of the backlog (or a release) might take to complete.
We also make it so that anyone on a given team can grab the next available story from the top of the backlog (or the current iteration). This implies few or no specialists (there is no back-end guy), and is generally referred to as collective ownership. It increases overall efficiency by allowing the team to dynamically re-balance, and minimizes reliance on any individual person (which among other things, leads to more relaxing vacations for developers).
The project’s customer (or product manager) focuses on prioritizing stories in the backlog, and the development team is collectively responsible for delivering software based on the backlog.
We use labels to tie related stories together within a project. These can represent a major feature, specific end customer, etc. Labels can help answer questions like, how much work is left in this large feature?
A single backlog for the entire team does put more work on the plate of the owner of the backlog (customer / product manager), as he or she has to constantly make potentially difficult prioritization decisions, but, thinking hard about priorities is a good thing, and it allows the development team to focus on getting more work done. That ultimately makes everyone happier.
Also, there are people in certain roles (for example executives and designers), that given their nature, tend to be involved with multiple projects at once. Tracker could certainly use some features to help these roles, and we’re thinking about these, but overall, it’s more oriented towards enabling the immersed team.
A single team/project can get large enough to the point where it becomes challenging to manage a single backlog. For us, this point is generally reached with 5 to 6 pairs of developers (or 10 – 12 people). Assuming that more developers can actually add value to the overall project (this is not always the case), it’s probably worth considering splitting the team into multiple smaller teams, each with their own single backlog.
To avoid knowledge and cultural silos with multiple teams, we find it helpful to rotate a few people around teams every iteration. It’s important to maintain consistency (and therefore a steady velocity), so you don’t want to shift too many people around too often – usually rotating just 1 person (on each team) each iteration is enough, assuming you’re pairing and switching pairs within each team often.
In a multi-team (and Tracker project) environment, the product/project manager acts as a load balancer, and allocates work across the multiple teams/backlogs by considering velocity, dependencies, etc. This is typically a full time job. Tracker doesn’t have much out of the box to help with this, but we’re thinking about this as well, although it may be that some of this kind of work is better done in a spreadsheet, or other, more traditional project management tools. (As a side note, we did recently add the ability to move stories between Tracker projects, making things a tiny bit easier for people who manage multiple teams/projects).
I’d love to hear your thoughts on any of this, including suggestions for how to organize large projects and multiple teams (and how Tracker can help with that).
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.
To learn how to set up Zendesk integration for your project, visit the integrations help page. Once enabled, you’ll see a new panel in your project, allowing you to see and drag/drop Zendek tickets into the backlog or icebox. Story comments and state changes will appear in the corresponding Zendesk ticket as comments.
Note: At the moment, the Pivotal Tracker target in Zendesk does not create linked stories in Tracker. We’re working with Zendesk to enable that, and make the two integrations seamless.