About a year ago I wrote a post “Combining Design and Development Stories in Tracker” for the Carbon Five blog. In that post, I describe my experience writing separate UX and development stories in one backlog. Recently, a few people have approached me to ask my current thoughts on the topic. Do I recommend Tracker for managing UX activities? What do I think about combining UX and dev activities in the same story? My thoughts are below. What’s your experience? Please leave me a comment!
Q: Do I recommend Tracker for managing UX activities?
A: A tool is just a tool. I used Pivotal Tracker because that’s what my team wanted to use. My advice would be pretty much the same if we were using Trello or JIRA or Confluence or paper cards or any other issue tracking tool. The point is the conversation that happens and who participates.
Q: What do I think about combining UX and development activities in the same story?
A: My current thinking on the subject is that there’s an adoption curve. Teams grow more comfortable thinking about UX and development work holistically when they understand the “big picture” of the project they are working on and have engaged, collaborative working relationships with each other.
The Agile UX Adoption Curve
Through my own projects in the past year, and by listening to other people share their own experiments with this, I think there’s an adoption curve. Designers show up, provide value and form relationships and UX work is gradually drawn into the team’s process. I’ve seen teams move through stages that are roughly like this:
- Designer shows up at standups to consciously represent they are part of the team and learn what’s going on. UX work is discussed with PM and not visible to the development team.
- Designer works closely with PM and participates in iteration planning meetings to guide the scope of stories written. Designer shows comps/wire frames at the start of an iteration planning session and facilitates conversation to help the team envision what they are making.
- Designer maintains work in some parallel system, for example, Pivotal (development stories) Trello (PM/design stories) or two walls of cards in a team room. Dev team has visibility into design activities but it’s not integrated.
- After trying to deal with the complexity of work on two boards and blocking issues, team realizes that ux design and validation work has to be pulled into stories, team starts to use tags and epics to identify stories that contain various activities (design, validation, styling). Designers and developers start to pair more at this point.
- Team realizes that it all has to be considered together and starts to write stories that include development and design work together. Teams start to break down the distinction between “developers” and “designers” as strict roles start to blend into each other.
I’ve noticed that “complication factors” (power dynamics, huge team, distance collaboration, team members shifting in and out) tend to keep teams in the first steps of this journey. Teams that work together closely over time tend to get farther down the list.
I’d love to know what you think about this. Please share your own experience in the comments below.