Agile User Experience Design

Writing User Stories

“Colocated product development teams typically capture user stories on note cards,” says Pabini. “But if you’re working on a distributed team, you can start by identifying themes that describe specific features and capture their epics and user stories in separate tables. These tables may comprise the following columns:

• User Role—As a user, I can…
• User Story—I want to…
• Value—So I can…
• Conditions of Satisfaction—Verify that…
• Notes—Details from discussions
• Priority
• Level of Effort

“Write an epic describing each feature, then iteratively break the epics down into user stories. But avoid decomposing epics into user stories too far in advance. When writing user stories, determine the proper level of detail to provide, as follows:

• Write small, fine-grained user stories and conditions of satisfaction, and capture any notes from discussions for top-priority features—that is, features the development team will implement in the next few iterations. As a team, set priorities and estimate the level of effort for these user stories. User stories should typically take only 1 or 2 days to implement and no more than 10 days.
• Write an epic and the key user stories—and any other user stories your team wants to capture—for features the development team will implement during later iterations. Write only epics for low-priority features that the team plans to develop in much later iterations, features that the team may defer to a later release, or features that the team may decide not to implement.

“There are two ways of adding detail to user stories: by writing additional, more fine-grained and subordinate user stories or by adding conditions of satisfaction to existing user stories. These approaches are not mutually exclusive.”

Getting to Clarity: Identifying Exception Cases

“With the time constraints in the design-as-you-go world of agile, I find that UX does a good job of identifying and designing for the happy path, but in my experience, the main gaps have come around the alternate paths and exception cases that did not emerge,” responds Mike. “To counter that, I often write quick use cases to identify and describe potential exception cases—for example, the system times out before the user finishes a task—to make sure we have covered those contingencies in our design.”

The Importance of Physical Proximity

“One of the most common and significant gaps is a physical one,” replies Adrian. “Designers are often physically separate from the rest of the development team. To work well, agile relies on cross-functional teams working together. The process is built upon rapid feedback loops that need close communication between everybody on the team to be effective. If a designer isn’t available to address design issues as they arise, they either become a bottleneck to progress or just get cut out of the loop.

“One of the common patterns you’ll see in successful agile/UX combinations is having the UX designer embedded with the rest of the product development team. Once the team has a designer in residence, the other issues that you encounter are much easier to address. I’ve created a presentation on some methods that UX professionals can adopt to better work with agile teams: ‘Developer/Designer Cross Training (or How to Get Developers to Do Your Work for You)’.”

“Both UX Design and Engineering should be part of a product development organization to ensure that fewer barriers exist between these teams.” advises Pabini. “When UX instead resides in a services group, it’s often a struggle for UX designers to get developers to think of them as an indispensable part of a product team. A UX designer’s being colocated with a Development team is ideal. In fact, one of the principles of agile development is that entire product teams should be colocated. But if, as is all too often the case today, you’re working with a distributed team, follow the sensible advice agile guru Mike Cohn offers in his presentation ‘Scaling Agile to Work with Distributed Teams’.” (PDF)

Using Sprint 0 to Combine Agile and UX

“In my mind, the best way to combine agile and UX is to use Sprint 0—which, in an agile development process, is when you define the backlog—to do UX design, which then feeds into the backlog,” suggest Tobias. “This may seem to be contrary to the agile idea—no big design up front—but this is design, not coding. UX design is not carried out by architects or developers, so those roles are not affected by that workload. But they do get better inputs going into their sprints. From a project and product management perspective, you need to plan the time for an extended Sprint 0.”

Tobias recommends Daniel Rosenberg’s article, “The View from Here: Garbage In, Garbage Out, the Agile Way,” which appeared in User Experience Magazine.

“No matter what type of development process a product team is following—but especially on an agile development project—it’s imperative that sufficient time be allocated for UX design,” says Pabini. “On an agile project, that typically means UX design needs to stay one sprint ahead of Development, starting with Iteration 0. However, when front-end development is part of User Experience, it’s possible for there to be a much closer coupling between User Experience and Development, and UX deliverables can be working code instead of the detailed documentation that agile purists abhor. For more about combining UX design and front-end development, see Jim Nieters, Amit Pande, and Uday Shankar’s column, ‘Great User Experiences Require Great Front-End Development’ in this issue of UXmatters.”

What Does It Mean to Be Truly Agile?

“I’ve worked in several agencies that followed an agile or semi-agile development process,” says Jordan. “It’s definitely a different way of working. If you simply accept that agile is a development process, I think you’ve overcome the first hurdle. I once worked in a semi-agile environment in which the final deliverable was a set of PSDs—it didn’t work well. Since agile is a development process, it really needs to result in functioning software—at least a running prototype.

“The only other major hurdle I’ve faced is that very few people really understand how to run a project in a truly agile way, so most places don’t try. It’s hard enough to educate a whole product team on how to adhere to an agile process, but when you start including vendors who use a waterfall process, it becomes almost impossible to complete a project in a truly agile way.

“When agile is implemented properly, the first question to answer is how to incorporate User Experience into each sprint. The most effective way of working that I’ve witnessed is to create a site structure in Sprint 0, then team up with creative and development for the rest of the sprints. In some cases, the role of User Experience might be merely consultative, helping the Development team to create solutions to each user story or epic.”

“I believe the gaps between User Experience and any development process are all in people’s perceptions. My experience in analyzing and implementing projects using about a dozen different development processes—including 150 agile projects—is that the real gaps lie within each of these processes,” says Steven. “Assumptions get made—‘we all do that’ or ‘oh, the Business Analyst does that,’ but without formal guidelines as to how to do it. For example, in agile, epic and user story creation is often rather muddled and prone to resulting in very developer-centric products that might work, but are not necessarily useful. User Experience can fill this gap by using our processes of discovery, analysis, and design to write user stories for products that really meet user needs and business goals by truly fulfilling a singular vision of a desired product.

“Another place User Experience can help is in determining the success of a project and being a key player in acceptance testing. If you work in an organization that is sufficiently agile to launch products before they are final—and is not beholden to corporate IT launch windows—it can be hard for developers and product owners to identify the feature set for a minimally viable product. UX professionals can draw a straight line from goals, objectives, principles, and vision statements to the current product and help everyone to decide whether now or three sprints later would be the right time to launch.”

Pabini offers this advice, “For a deeper understanding of agile software development, I recommend that you read Mike Cohn’s books and other writings:

• User Stories Applied: For Agile Software Development—This is a great book on writing user stories and one of the few books on agile development that takes user experience into account at all.
• Agile Estimating and Planning—Since accurate estimation of development effort is a key part of the usefulness of user stories, this book is highly complementary to User Stories Applied.
• Mountain Goat Software—Mike Cohn’s Web site offers a treasure trove of information about agile software development. The site’s Resource Library includes articles, presentations from his workshops, and videos of some of his conference presentations.

“Armed with this information, you’ll be able to take a more proactive role on an agile product team and make contributions to the team that will give you greater credibility among developers. As a UX professional, it’s always helpful to demonstrate that you understand good software development and project management practices.”

In Conclusion

“To fill the perceived gaps, you just need to fill them,” recommends Steven. “Be prepared to defend the value of user experience as an evidence-based practice. The perception is often that it’s drawing, drawing is art, art is opinion, and everyone has an opinion—and one beholden to schedules and processes. But demonstrating the value of user experience is the strongest proof.”