As a user experience designer in the agile world, I recognized a while ago that my job is as much about influencing my team’s DNA to include best practices for UX design as it is about actually designing. I’ve supported anywhere from three teams (with a total of sixteen developers) to a single team (with with six developers). No matter what the ratio, though, there’s always been more user interface to design than I can execute (even when I worked ungodly hours). With more work to do than I could cover, some UI design had to be done by other team members.

And yes, even now, that terrifies me. But that’s reality, so I’ve had to go to greater lengths to make sure that the entire development team shares a concrete understanding of the user’s motivations and fears.

User stories have helped me get there. I like to pair user stories with personas derived from user research, so that the “As a x” portion of the story becomes “As Michael.” By marrying the two together, I gain two things:

• The personas, which historically were read through once before being forgotten, gained greater prominence through repetition–actually achieving that mythical goal of becoming part of the team vocabulary.
• The user stories became even richer, as each story written from Michael’s perspective drew on the combined history of the user research, the persona itself, and all of the other Michael stories. What was an isolated and generic user story becomes one part of a rich narrative about a specific archetypal user.

Because the user story is present every day during the sprint, tying the user stories to the user research creates a powerful reminder to keep the user at the center of every decision.

Photograph by drewgstephens

Eventually, I decided to step back from the details of an iteration and focus instead on the patterns of how we worked. I watched in planning as we did everything technically right. We lined up the user stories we wanted to execute, decomposed them into tasks, and then triple checked that our estimates on the task cards fit into our actual available time. We even factored in some time for the unknowns that would crop up. By all measures, we were primed for success.

The next morning’s scrum revealed the problem clearly. One by one, we all stepped up to the board and pointed to a task card that we planned to work on that day. And each team member pointed to a task card related to a different user story. One person even pointed to two small tasks on two separate user stories.

On the first day of our iteration, our team of seven started eight different user stories. At the end of that iteration, all eight of those user stories were incomplete.

Our problem? We were approaching our scrum board like it was one of those carnival games where you shoot water canons at targets to make your horse/hot air balloon/clown/whatever charge toward the finish line. As soon as the starting flag waved, we each grabbed a cannon and plugged away in isolation, hoping that our horse/hot air balloon/clown/whatever would cross the finish line before time ran out.

We had a couple of mental model problems with how we approached our process:

• We assumed 100% success at all of the user stories we planned to execute, so we made no effort to maximize the amount of success for the what-if scenarios.
• We saw a single finish line at the end of the sprint, so we did nothing to try to fully complete stories before that deadline.

Like most process problems, understanding the issue was ten times harder than fixing it. The solution was obvious: make every effort to limit the number of user stories in play at any given point in the iteration. Focus on pushing a story through the process completely—all the way to acceptance from the product owner—before starting a new story.

If we focused three or four water cannons at one target, we’d push our horse/hot air balloon/clown/whatever past the finish line quickly, and then we could tag team another target.

So what about your team? Are you aiming at as many targets as you have team members, or are you controlling risk by keeping the number of stories in play to a minimum?