One of the fun things about working at Carbon Five is that we get a chance to work on product ideas we design and build ourselves. This gives us an opportunity to experiment with technologies and processes that interest us. Recently, I’ve been contributing to Carbometer:Blog, an information radiator that visualizes details about blog traffic.
This project is led by a Balanced Team which includes a developer (Rob), a designer (Lane) and a product owner (Christian). We thought this would be a great opportunity extend our agile process to look at user experience (UX) and development activities in a unified way and put all our stories in Pivotal Tracker as a unified backlog.
From my perspective as the user experience (ux) designer on the project, I think it’s important we have a unified design/dev backlog so that:
- UX activities are visible to the team for transparency & prioritization.
- The team can understand how UX activities support the project and where design need and design debt exist.
- Designers are full members of the team even if they don’t write code. By being part of the regular process of building products there’s a greater chance for developers to get a designer involved, and more natural opportunities for cross-functional pairing and cross-training.
- Stakeholders have high visibility into UX activities that block the implementation of other features.
How We Use Tracker
Here’s some specifics about how we include both UX and development stories in Pivotal Tracker.
- All stories are created in Tracker, anyone can add to icebox. Stories are pulled into the backlog during iteration planning meetings. So far on the project, Lane creates design stories, Rob creates development stories.
- We’re using Gollum to set up a separate repo for design documents and non-code project materials. If a story can be delivered to the GitHub wiki repo and accepted by the product owner (Christian), it’s a feature, otherwise it’s a chore.
- Design feature stories don’t have the “as a..I want…so I can..” format unless it makes sense since the “customer” for most design stories is actually the developer (“as a developer I want a wireframe so I know what to build”).
- Because we are using Fibonacci numbers for estimation and we don’t have a reference scale for design stories, we decided to assign them zero points.
- Design stories are tagged with the appropriate epic when possible, otherwise they get a general “design” tag.
- Feature epics are named “#epicname” so they show first in case there are two tags.
So far we’re really happy with the way this is working out, however I feel there is still room for improvement. Here are a few things we plan to reflect on and try later.
Develop Fibonacci scale for design stories
By not assigning a size to UX stories, we don’t get better at predicting how long UX activities take and we don’t have visibility into the project’s true velocity, which needs to account for both design and development stories. The blocker seems to be that we don’t have an equivalent scale for design stories and development stories. As I mentioned earlier, we’re using Fibonacci numbers for estimation. The reference scale we agreed upon for development stories was: a one pointer was building out a simple page with minor testing, a three pointer was building out a page with the modification of the full MVC stack, a five pointer involves the implementation of a full MVC stack, an eight pointer was an epic story that has to be decomposed. If we assigned design stories points without an equivalent scale, the tracker velocity would become unreliable/inconsistent. I believe that it is possible to create an equivalent Fibonacci scale for design stories. Rob and I plan to reflect on this and try it out together during our next iteration planning meeting.
Full team participates in story estimation
I’d also like to see everyone on the team size all the stories together. At this point, we’re separate–only developers participate in sizing development stories and design stories are not sized. Even if designers and developers don’t entirely understand all the steps involved in each others’ work, I think over time the working group can learn to recognize different sized stories even if they involve activities they aren’t familiar with.
What else do you want us to write about?
Here are some other other practices we’re experimenting with on Carbometer:Blog. Please let us know in the comments field if you’d like to hear more on any of these topics.
- Unified design/dev acceptance workflow. We’re using two GitHub repos, one for code, one for design and other project artifacts. When I finish a design story, I include the URL of the page in the wiki for acceptance.
- Well-defined, shared, product vision via a short project brief. This brief defines the biz objective, personas, scenarios, and success metrics. We read this document as a team and revise as necessary at the start of each iteration planning meeting.
- Design at the lowest responsible level of fidelity. The whole team engages in quick, collaborative design sessions to form rough UI sketches. Having a UI framework allows us to name elements at a conceptual level and use them as epic names. Once we have this general agreement, design and dev are able to to work independently before we have wires/comps.