Long ago, way back in the early 2000s, Pivotal Labs was a growing Agile project management and engineering consultancy. Business was good, but organizing and visualizing project work was arduous. In response, Pivotal engineers created Pivotal Tracker, the project management tool we all know and love today.
What was noticeably absent from the early days of Pivotal Labs is the inclusion of designers. Since we began as an engineering organization, the Pivotal process included in Tracker was specific to engineering work. This process is great for development (where the desired outcome of a story are well-established) but less ideal for creative work, which often has changing requirements, undefined desired outcomes, and uses a generative approach to problem solving.
Fast-forward to today, where software teams are now a diverse group of engineers, designers, testers, content writers, and so much more. While our own design team grew, we struggled to use Tracker to manage design work. We tried a number of other services, including Asana and Trello (which many creative teams use), but ultimately came back to Tracker.
Here’s how (and why) we use Tracker for managing our design work.
As with development stories, the design team conducts planning meetings where we point and discuss stories. Like the development team, most of the value we get from these meetings is the discussion of story complexity, strategy, and dependencies.
Once we’ve discussed and pointed stories, here’s the general pattern we follow:
A dedicated design project has a number of benefits:
It lets you see what everyone on the design team is working. Unlike most to-do list apps, Tracker has specific state for started work. This allows the design team to see what work someone has picked up, and also lets them visualize if someone is working on too much at once. This also allows developers to see what the design team is working on, and provides the team with background on a particular design without having to go to another tool.
It forces your product manager to make a decision. Oftentimes, a PM will sit on a design that a designer feels is “good enough” for now, but perhaps not as far reaching as the PM would like it to be. This is a slippery slope, and can slowly transform an otherwise lean team (that is iterating quickly and getting customer feedback) to develop long-running, overanalyzed features. Subsequently, these features can grind on forever without receiving adequate customer feedback. “Deliver”-ing a design story informs our PM that this is done for now, and forces them to accept the design in its current state, or reject it with specific corrections/improvements.
It’s a go-to place for feature discussions. We use a number of tools outside of Tracker to communicate as a team (e.g., InVision for getting detailed design feedback on mock-ups and flows, Slack for chat, and Dropbox/Google Drive for file collaboration). But we still need a central place to have discussions and make decisions. Tracker stories serve as a place to do this.
Simple feature stories will do for one-off tasks (e.g., a drop-down menu for labels). But for bigger design tasks, like our Charts refresh, we’ll create a dedicated epic for the work in the development project. This epic acts as a source of truth for any grander product questions. Granular design work is addressed in individual stories.
Any updates to the design are reflected within this epic. While it’s sometimes important to include designs specific to a story in that story, this can be arduous to maintain, and we opt to keep the source of truth in the epic.
In our development project, stories will frequently need design details to be completed. Color information, transparency, spacing, and font size are all considered at-time design needs which are inappropriate for a high-level epic.
To address these needs, the product manager or developers will add a “needs design” label to a story that needs more detail, usually with an associated comment detailing what is needed. This is convenient for the designer, who can save a search with the “needs design” label, allowing them to queue stories needing design detail.
For more involved stories, we’ll add a “pair with designer” label. This tells the developers that it’s to their benefit to grab a designer to work through a story. This avoids the PM rejection cycle, and allows the designer to inspect an implemented design prior to delivery.
Finally, testers will include a “design accept” label on stories that require a designer to take a look at work prior to approval. Similar to “needs design,” this lets a designer queue up any work needed for them to review. Once a design is accepted, we may put a “design accepted” label on the story to signify that we reviewed it (sometimes we accept it outright if the testing team has already reviewed it).
Tracker is primarily a tool for lean software engineering management, and probably always will be. But given the changing nature of what it means to be a development team, we know we have to make Tracker a better tool for designers and specialists along with developers.
Improved integration with third-party tools: We already have support for Google Drive, but in the future we’d like to have better support for tools like Dropbox. How awesome would it be to update your mocks on Dropbox, and have them automatically updated in Tracker? That’s a rhetorical question, of course, because it would obviously be awesome.
Better support for custom workflows: A common myth about designers is that we don’t have a workflow. This is partially true: we don’t have a single workflow. We use a number of approaches depending on the task at hand, and these approaches may need adjusting if something changes or doesn’t work. At the moment, we use labels to create ad-hoc workflows within design and engineering stories (as you’ve already seen), but we’d love to be able to hack the Tracker process in some way.
Cleaner conversations in stories: Stories with lots of comments begin to get noisy and difficult to follow. This is especially true if there is an ongoing discussion in the story (a frequent experience in design stories). We’re exploring ways to collapse or group conversations in a way that makes scanning them easier and faster.
Tools to help designers focus: Developers are usually working on a narrower part of Tracker than designers or specialists (by focusing on My Work, or the top of the backlog). We’ve already done a number of things to give specialists more project breadth, including robust search (including saved searches), multi-project workspaces, and global notifications. We’d like to continue this by giving designers more tools to organize their priorities and react to team needs.
How do you use Tracker for managing design stories? What would you like to do? Please let us know in the comments below, or email us!
Category: Pivotal Tracker
