Combining Design and Development Stories in Tracker

Posted on by in Design, Process


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.

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.

Where Next?

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.


  Comments: 23

  1. For a project with 5+ devs, 1 UX, 1 PM, I took a different approach and liked the results. I kept Tracker focused on dev stories, and used Trello to manage the pipeline. Both were totally transparent to everyone, and the latest assets (of whatever fidelity) needed to estimate and/or deliver a story were continually brought over from Trello to Tracker. If stories in PT were blocked pending design, they were labelled as such (and sometimes moved to the icebox).

    For a bigger team, I liked keeping it easy for a developer to open Tracker and know that the top story was the most important one, rather than having multiple “lanes” (no pun intended) mixed into the hierarchy of stories.

    I also just found Trello fast and easy for iterating through design versions. The whole thing was relatively low ceremony and moved smoothly.

    But my own thoughts are perpetually evolving and I think my partner Jeff Gothelf would be more on your side, Lane.

    I do like the notion of having velocity for both dev and UX, but am a bit hesitant on merging this into a single velocity and keeping the concept of velocity truly actionable. I would need to try it!

    • Hi Giff. We’re using Trello and Tracker on a client project I’m working on. In that case, there’s a much larger develpment team, several PMs and more need for up-front pipeline management. I think the process the team chooses will always depend on context and appreciate your sharing what’s working for you!

  2. Kristen Johansen

    (Hi Lane, long time no see!)

    Let me know if you ever get fibonacci estimation for design stories to work – we tried for years to do this and we were always grossly off, because there were so many things that were hard to predict – stakeholder wrangling/input, early phase stories that weren’t yet really articulated, usability study results, etc. We also caused a lot of heartache for the teams when we tried to include design stories in overall team velocity because it introduced a huge amount of fluctuation as we changed the design during the ideation/validation process. The developers hated it, and it made it difficult for the designers to have the flexibility they needed if an initial design failed.
    We eventually started tracking design stories with a separate kanban board, and marking their corresponding user stories in the scrum team’s backlog with where they were on that kanban board so the team knew how close they were to being ready to be picked up. That seemed to help give visibility into where we were with the design without screwing up the team actually building it.

    • Hi Kristen! Thanks for your comment. One of the things that reduces false starts and thrash on this project is having a well-defined shared vision, which is held in the project brief. By having a clear, narrow-scope target, we’re all solving the same problem and there’s less design waste. I’ve also tried separate design and development backlogs as you suggest and that works too, especially when there are many designers who contribute to many agile development teams, and you’re balancing near term detail design activities with long term strategic design activities.

    • We’ve seen the same frustration around trying to estimate design activities. As developers we have already had to learn that not all activities are stories and that we need to meet the criteria for a good story if we want to be able to give useful estimates. I wonder if it is reasonable to apply or a similar set of criteria to design activities to divide them into estimable stories vs other activities which either need definition or should not be included in the team’s velocity.

  3. Thanks for the great article. It gives us some starting points on getting design and development activities synced up. I would really like to hear more about your design process around getting to a UI framework, and how that informs the organization of work to epics. I am most curious about how you name UI elements as epics vs features, how (or if) you use those in storymapping, and how they end up beings used in pivotaltracker’s epics and labels system.
    thanks again!

    • Hello Tony! Thanks for being the first to comment! I’ll queue up another post to go into this area in more detail.

  4. On my project (a video game) we have two artists, two game designers, and one developer. We are currently mixing all our stories together in Tracker and estimating them too. It definitely messes up any possibility to measure velocity–the art, design and programming points are not aligned at all and have no tendency to converge. I like some of the commentor’s idea to have a separate velocity measurement for design vs. development. I’ll try that next time.

  5. With a product team of 4 designers and 8 developers we tried to include design stories in the unified tracker backlog but it was too high-maintenance what with the dependencies you need to manage, and how it muddies the “next in queue” approach.

    Next we abstracted the UX tasks into their own tracker project, but it’s just not the right tool for that kind of work (though we could do some estimating there, since the scale was specific to the design work).

    Because we were all collocated, we moved to a physical kanban board. (Trello is a good virtual option for this.) The board had cards for needs/features, and they would get translated (and mapped) to multiple tracker dev stories. That way we could see where a feature was at a level higher than individual stories as it moved from the ‘opportunity backlog’ to release.

    The kanban cards also grouped into releases, so we had three levels:
    1. themed releases, made up of
    2. features, decomposed into
    3. estimated dev stories

    As an example:
    release: Students can meet/interact with classmates
    feature: class list includes photos, basic info, and links to detailed profiles
    story: main course page shows scrolling list of students in reverse chron order of registration

    We then measured the UX work in kanban fashion, with rates of throughput, WIP limits, etc.

    • Hi Tim, thanks for mentioning themed releases and their relationship to features and stories. Even more than the tools we use, I believe this way of thinking about the product and organizing work creates a situation where good design and development can happen.

    • I also wanted to mention, Hooray for small, co-located teams of poly-skilled makers πŸ˜‰

  6. Hey Lane,

    Obviously if it’s working well for ya carry on, but I’ve seen problems with separate design stories on teams in the past.
    This used to be my preferred tool to get everybody to understand the work that UX folk did – but in more recent years I’ve begun to think that it can get in the way more than it helps. These days I see it more as a transitional tool rather than a long term solution.
    The problems that I’ve seen with separate UX stories are:

    * They can become something that gets dropped when pressure situations occur (it’s ‘only’ a design story…)

    * They get away from, on agile teams, the idea that *all* stories deliver direct business value (or Running Tested Features or whatever). I don’t like design stories that fail to do this, in the same way I don’t like development ‘stories’ like ‘build database layer’.

    * They tend to stay the sole job of the UX person and seem to act as a bit of a barrier to getting the whole team to help swarm on stories. They highlight the work – which is great – but they label it ‘ux’ so it becomes a subset of the teams responsibility rather than the whole team’s responsibility.

    I’d be interested to see how you feel about them in a years time – or as the team grows. (I wonder if these are really Rob/Lane stories rather than dev/design stories… if you see what I mean).

    I’d also love to see some examples of your dev/design stories and the relationship between them.



    • … and I now see that I didn’t actually talk about what I do instead… which is to just have stories (or, more often these days hypothesis/experiments). Nearly all of them will involve both UX and dev input – possibly in different proportions. The output is RTFs and learning.

      Where we spend a lot of time is thinking about what ‘done’ means for the story. That’s where UX folk can have a lot of input in how they’re involved. In both figuring out the learning needed (what are our research goals) and the quality of the feature delivered to the user (what are our ‘experience’ goals).

      Hopefully that makes some vague sort of sense πŸ˜‰

    • From my perspective, we’re trying to overcome a weakness in the tool we’re using (Tracker). If there was a way to model channels (simplest case: design and build) and have that reflected in the workflow, then our natural process would fit better within the tool. We’ve simulated channels with labels and it works okay (designers click on a label, e.g. “needs design” and get search results in priority order of stories that need attention. This becomes their backlog.

      Separate stories comes with a cost. This experiment is to see if that cost is more or less than other things we have tried.

      • Eww – adapting yourself to the tool πŸ˜‰ πŸ˜‰ Kill the tool!

        I’m not sure what you mean by channels here…. are we talking about things like swim lanes on kanban boards?

  7. One last post and I’ll shut up πŸ™‚

    What value is point based velocity giving you? If you stopped counting points and just did the next most important story – what bad things would happen?

    (While I think point based estimation is much better than the really poor up-front non-reality based estimation that many folk used before, I’m not sure that it’s the best option overall. Especially if you have a really good incremental process and a good handle on what the most value things to deliver next are.)

    • @adrianhoward:disqus After a couple of weeks (iterations) we hone in on a velocity that, while never completely stable, does give us reasonable forecasting during planning. As a consultancy working on generally smallish projects, it’s important that we stay very focused. One of the best ways to help our clients share the same focus is when Tracker says we don’t have enough time to finish what’s in the milestone(s). That’s when real prioritization happens.

      We have discussed test driving a project with no estimates (all set to 1), but haven’t performed that experiment yet. If the stories are all roughly the same size and the team has good throughput, then the differences wash out in the averages (as do poor estimates now) and you still get a meaningful velocity. Has that been your experience?

      I’ll post another comment about estimating design stories.

      • Yup that’s pretty much my opinion. If you’re going the estimation route then you estimate the whole story – dev and design. If you can’t do that with some level of confidence split/thin the story.

        These days we run internally with something pretty close to your ‘no estimate’ style. We just count cards. However we have a flow/kanban style with “disney” style markers for ‘1 week’ / ‘1 month’ waits on story completion based on our running averages. We use this to figure out clients / internal facing deadlines and schedule clashes.

        If you’ve not seen it already you may find Arlo Belshee’s presentation on Naked Planning of interest – it’s pretty much what our internal system has evolved to on the estimation / time management front (our ‘done’ is a bit different but that’s a different conversation).

  8. Courtney Hemphill

    Tim, we tried a similar approach on a recent project with 4 developers, and one (sometimes two) designers. We did our best to keep everything in tracker organized around weekly releases geared toward a specific user test scenario. Most high level design was done using physical spaces and a dedicated project room. We would then translate discussions and design work into actionable stories in tracker that could be either an acceptable working feature or a design specification that could be accepted by the product manager and then translated into a development story.

    We ended up using epics and labels heavily to help with organization and isolating queues for different resources (this could be a developer, copywriter, designer, product manager, etc). Although we did not estimate design stories on this project, I have tried this previously and found it to be difficult at first but helpful in the long run. Once a pattern for design stories has been established it was helpful for the product manager to have insight into the tradeoffs of spending more time on design versus development and also allowed the designers an opportunity to better manage their time. We also found that it kept things moving forward so that if dependencies started to line up, a discussion would naturally occur about additional staffing that might be needed or ways to eliminate the dependencies.

  9. Recently a couple people have approached me for an update. I’ve posted my current thoughts on the subject here.

Your feedback