Fitting Big-Picture UX Into Agile Development

Tunnel Vision And The Problem With Sprint Zero

Since the wide adoption of scrum as a development methodology, designers have struggled to fit design practices into its framework. Scrum, with its iterative work ethic focused on a releasable product at the end of each sprint, tends to lead designers to focus on very small design questions that can feel divorced from a cohesive design vision or interaction concept. The result is design tunnel vision.

Designers have struggled with the need to step back and work on holistic concepts while at the same time supporting development teams that are actively moving forward on bits of functionality that, from a design point of view, cannot be easily divorced from the whole. For many designers, the process often feels like an effort to design an engine, wheel or windshield without really knowing in what kind of car these parts will need to be integrated.

To deal with this problem, agile organizations have come to rely on the concept of sprint zero, a preliminary sprint dedicated exclusively to preparing for the first sprint, during which design teams are generally free to address initial design concerns. For complex projects, however, sprint zero may simply not be enough to create concepts, perform research and imagineer complex systems. More importantly, as a one-time event that exists only at the start of the process, sprint zero assumes that the need for a design-centered thought bubble is discrete, as opposed to an ongoing concern during product development.

Although any sprint can theoretically aim to address design issues, the pressure on designers to not hold up the rest of the development team once normal sprinting has begun is enormous. However, the time needed to explore very complex design decisions could drastically slow down team momentum. Making short-term design decisions based on limited understanding could end up invalidating valuable chunks of team output, an outcome that should be avoided if at all possible.

Development teams have long had a reliable solution for taking extra time to work on thorny or ill-defined obstacles: the spike. Spikes, in their most basic forms, are time-boxed periods that are used for exploration, research and sometimes prototyping. The purpose of a spike is to explore information necessary to understand a development approach or a requirement or to make a story estimate more reliable.

With a few modifications, the spike construct can be adjusted to serve the needs of design teams while maintaining the overall structure of scrum and preserving momentum. I call it a design spike — a method by which design teams can address complex UX issues within the confines of the scrum process.

What Is A Design Spike, And What Makes It Different?

A design spike is a bubble of time during which the designers and potentially other team members focus primarily on design questions. Design spikes can take place at the start of a project or anytime during the normal scrum process, but the introduction of a design spike changes the nature of the working scrum team temporarily. A single project may have multiple design spikes, as many as deemed necessary by the team.

When a design spike is called, any development work that could be affected by the spike temporarily ceases. This is because design spikes inherit and create obvious dependencies in the agile process.

Design spikes drop into the normal scrum process and temporarily take the place of regular sprints.

Members of the development team who can move forward with work that would not likely be affected by design decisions may do so, pursuing non-dependant stories from the backlog during the spike. Remaining members can participate in research and design. Members also will contribute ideas to the design process, vet design ideas for feasibility, suggest alternative solutions and provide general estimates of work based on the designs being produced. Development insight is crucial to keeping the design process rooted in the reality of production. Again, the key point is that the team does not move forward with development work that could become wasted effort based on design spike decisions.

In organizations with additional UX and design resources, the team may also request to be temporarily augmented with new members. This is useful in situations where additional researchers or designers are needed for short turnaround testing and prototyping, but it is not required. These temporary team members would exit the team once the spike has ended.

So, What Happens To The Backlog, The Product Owner And The Traditional Sprint Artifacts?

The design spike inherits the product owner of the project but also adds another decision-maker: the design owner. The design owner will usually be a senior member or manager of the organization’s design staff brought in from outside the scrum team, such as a UX director or VP, although the spot could potentially be filled by a decision-maker from marketing or product, depending on the organization’s structure. The key is that the person in this role needs to have a design vision for what is to be built and the capacity to make decisions about a design’s viability relative to broader design considerations in the organization (e.g. other products, design patterns, style prerequisites, etc.).

The design owner is also partially responsible for approving the done-ness of a design sprint’s results. Both the product owner and design owner must agree on the done-ness of backlog items before the item may be considered done. The definition of “done” is decided during the design spike’s initial sprint planning meeting and is an agreement between the team, the design owner and the product owner. For most spikes, the definition of done will probably be tied to the definition and completion of design artifacts, research results and prototyping endeavors.

Why bother adding a design owner? In mature organizations with multiple product offerings that share a unified visual, interactive or brand language, design owners may be responsible for consistency issues that extend beyond a given project. Design decisions and product decisions might be at odds, and making transparent the process of these two constituents discussing and exposing the acceptability of solutions is key to the transparency of the design sprint. Formalizing the involvement of a design owner helps to ensure that the work being done in a design spike is being vetted and approved by senior design stakeholders and decreases the likelihood of later contradictions.

The design spikes also inherit the scrum product backlog, and the design team selects stories from the same backlog and accepts them into the spike, trying to complete as many as possible during a design sprint.

Design sprints work just like normal sprints but focus almost exclusively on design decisions. Design spikes should prioritize work to resolve the biggest unknowns in the current design first, and they do not need to follow the backlog’s priority order. For instance, if a high-priority item calls for displaying data in a certain widget, but a lower-priority item calls for including more data than the widget can currently accommodate, then the design team may select the lower-priority problem in order to think about how this change could affect the widget’s overall design downstream. Again, design prioritization is a different beast than product prioritization.

Importantly, because the spike focuses only on the design portion of backlog items and not the development portion, backlog stories are completed only from a design point of view. When the normal scrum cycle resumes, any stories calling for development work will still be alive on the backlog list, ready to be selected for a normal sprint.

The duration of the design spike is not generally time-boxed, but the team should aim to end the spike as soon as possible so that team resources are not left idle. The product owner may elect to time-box the design spike if necessary, although anticipating how long it will take to work through complex design issues can be difficult. The goal of each spike is not to produce potentially releasable code, but rather to provide actionable design decisions in the form of wireframes, mockups, prototypes or research. Design spikes work best when they are of shorter duration, providing a greater number of sprint reviews in which feedback from stakeholders can be gathered. The recommended time length for a design spike is one to two weeks. The spike would continue in the form of design sprints until the product owner and design owner decide that the spike has reached its goal or is no longer of use. All effort would then be made to return the team to its normal sprint schedule as soon as possible.

Each design spike may contain one or more design sprints, which work very much like normal scrum sprints but are focused simply on design.

As in a typical sprint, the design spike process retains all of the milestones that you’ve come to know and love: product backlog grooming, effort estimates, sprint planning, sprint reviews, sprint retrospectives. Those all stay the same, but the focus here is on design, not building, and all of those artifacts now track the design work that the team is aiming to finish.

When Do Design Spikes End, And What Happens Next?

When the product owner and design owner agree that the design spike has reached the point at which the normal scrum process should begin or resume, the spike ends. The design artifacts created during the spike are carried over into the normal product scrum to serve as starting points for the detailed design process.

The designers who were part of the design spike (some of whom might transition to be part of the scrum development team) serve as a resource to the development team on any open questions and design issues, and the scrum process starts anew. Importantly, these design artifacts are not set in stone. The development team still functions as an autonomous decision-making unit. They simply now have the benefit of a holistically designed foundation on which to build.

Design Spikes Let You Zoom Out, And Then Zoom Right Back In

In conclusion, design spikes give UX teams a framework to conduct big-picture design within the scrum process. They allow for comprehensive design bubbles that focus on holistic issues, rather than the granular design concerns that scrum sprints sometimes emphasize.

The design spike gives the team the opportunity to explore systematically rich UX questions from a macro level, and allows the team to break out into design-centric thinking at any time for the purpose of solving larger UX challenges. With the addition of the design owner as a decision-maker in the process, design spikes also offer large, mature organizations the opportunity to incorporate senior design stakeholders who can lend expertise and guidance on important design solutions.

With the adoption of design spikes, UX teams can leverage some of the flexibility that development teams employ in the agile process, while gaining the immensely important time needed to address design concerns that simply might not fit neatly into the hyper-focused needs of standard scrum sprints.