Integrating UI Design and Scrum: Consultancies and Clients

Earlier this month, I received a question from a participant in of one of Michael James‘s CSM courses about how to integrate UI design into the Scrum framework. I’d already been working on a post addressing this subject broadly, but the inquiry provided an opportunity to summarize my main points while including some specific considerations for design consultancies doing Scrum while managing client relationships. He writes:

Hi Luke,

Any tips on how to integrate Scrum into the interaction design process?

We often have to deal with delivering functional specifications (including the wireframes) up-front for sign-off with the client. Call it sprint zero if you like.

I’m interested in your recommendations and experience on this.

Below is my reply in full:

There are two parts to the answer: one addressing the perceived tension between Scrum and the typical predictive process model used by most designers (analyze and design first before building), and the other addressing the dispersal of team members across organizations in a provider-client relationship.

There are a few ways to address the first:
In cases where there are large, imposing design problems that will require time, negotiation, and multiple iterations to figure out before anything gets built – say, determining the navigational structure of a new website – write analysis and design backlog items for the typical design steps, with the title or done criteria describing the artifact that will result from the effort. Here at Danube, we’ve done so by naming them “Round 1 Sitemaps,” or “Round 1 (…2, 3) Wireframes.” These backlog items rarely require the participation of every team member, but usually there are other backlog items that can be worked on by the rest of the team that don’t require the participation of people working on analysis & design. Not every piece of work in a Sprint needs to be swarmed on by every single team member.

For smaller backlog items that can be designed and built within one Sprint and do require participation by the whole team, there’s no real way around having to scale down the time allotted for design so that it’s in proportion to the Sprint. This essentially means you have a miniaturized waterfall process within your Sprint. This is merely being pragmatic, and is a workable compromise provided this approach is used in conjunction with the next technique, which is…

Get the whole team used to iterating over Sprint output in successive Sprints. Rarely is any person’s or team’s first attempt at something the best or final version, and often it’s simply not good enough. This ‘inspect and adapt’ tenet of Scrum applies as much to designs, code, or any other output as it does to the process itself. The thing to keep in mind is that just because a backlog item has been completed doesn’t mean the feature it describes is automatically now blessed as fit for release. If the output of a Sprint doesn’t yet adequately satisfy the business need or meet the PO’s satisfaction, it’s a candidate for rework. More on how Scrum roles and your duty as a designer on a Scrum team play into this decision, below.

As for Scrum roles and dispersal across organizations:
First let me say that I have yet to practice Scrum in a design consultancy environment. We’re a small corporate organization and our relationships and Scrum roles are clearly defined. I have, however, worked for design consultancies and am familiar with their particular design & development and client relationship challenges.

I gather from your statement that your clients – the ones requesting functional specifications (including wireframes) up front for sign-off – are handling the development. It also sounds like some think they’re practicing Scrum, though it’s clear from the example that they’re not, quite. If they were, then wireframes, sitemaps, and other design artifacts would be produced in Sprints in collaboration with the rest of the Scrum team. Asking that the design be finalized “up front” and then thrown over the fence to development is just more waterfall, no matter what process development uses thereafter, because the first requirement of a Scrum team is that it be cross-functional. Design, after all, is work necessary to build a website or software product just as much as programming is. Of course, we all know that sometimes design needs time to come up with something to build before building begins, but I’ve already addressed that above. My point here is that designers are equal members of any Scrum team that requires the input of design in order to complete a product. If you’re providing design, then you’ll need to place designers as team members on the client’s Scrum team. If you can’t logistically have them working in the same room with the client’s employees, you could at least have them meet regularly and participate in all the typical Scrum events such as daily standups, planning sessions, reviews, and retrospectives.

Even if your organization is doing the designing and the programming, you still need to integrate the client somehow with the Scrum framework. The client roles would certainly include Stakeholder, but possibly even Product Owner. Of course, if your client isn’t familiar with Scrum, then you’ll have the extra task of bringing them up to speed in addition to designing and coding. This presents a dilemma: The Product Owner is a pivotal and difficult role even for experienced Scrum practitioners. Do you just throw an uninitiated client into it? Probably not. In this case, the consultant account representative (your employee) would most appropriately be the Product Owner, and would coach the client Stakeholders on the process while representing their interests to your design & development team. Most account reps at consultancies already perform a similar function, but making this role official might require a level of training and responsibility they don’t currently have.

Your role as a designer on a Scrum team:
As a designer, you are an advocate for the user – the human half of the human-to-computer interface you’re building. Often, on a team of computer scientists and business types, you may be the only team member that has perceptual biases in this direction. It’s therefore your duty to argue for rework if a component may in some form deliver functionality, but fails on user criteria; Nobody else may be equipped to do so. In the end, as we all know, these criteria are almost always subjective. But you should already be used to making convincing subjective arguments for design. This skill becomes even more crucial in a Scrum environment where the pace is increased and decisions are hard-coded on the fly. Since the Product Owner is the ultimate arbiter of business value in the product, you’ll most often be making your case for design with the PO. He or she will be balancing design refinement along with feature richness, performance, technology enhancements, and a myriad of other competing factors.

And herein lies the golden kernel of Scrum for a designer: The design doesn’t have to be perfect! It does have to be the best design possible, but only in the time you have and only in proportion to the other criteria of importance to the Product Owner*. The Scrum framework inherently takes care of ensuring most of that for you. As a designer, then, your challenge becomes getting the most time and flexibility within Sprints and before the release to be satisfied that the design is good enough – good enough, that is, until the next time you get to work on it.

*There is a parenthetical thought here: that design may in fact not be important at all to your PO. Value for design is likely to ebb and flow with changing needs of the marketplace and the product. But if this is the case consistently, you as a designer may be in the wrong job. A lack of value for design may not necessarily be un-Scrum, but it could be un-you.

Download the PDF version: Integrating_UI_Design_and_Scrum

Luke Walter

Luke Walter is a Certified Scrum Trainer® and Agile Coach, helping organizations maximize value delivery using the Scrum framework and Agile development practices. He guides senior management, development, and operations through the challenges intrinsic to agile adoptions, enabling them to adopt more meaningful measures of progress and realign for effectiveness. A 9-year Scrum veteran with over 8000 hours logged on high-performing Scrum teams, he brings an uncommon depth of real-world agile experience to organizations seeking to transcend procedural and cultural barriers to success.

Posted in Agile
4 comments on “Integrating UI Design and Scrum: Consultancies and Clients
  1. Michael James says:

    I just met a designer who’s split between three different teams, and unable to progress in any direction because of all the signoffs (from parties with conflicting motivations) required before being allowed to build anything. He seemed pretty stressed out.

    And then I read this extreme opposite approach, live (deployed) code within one day, and almost reckless iterations after that. This wouldn’t work for everyone, but it’s interesting to think about:


  2. Luke says:

    Thanks for the comment, Michael. The subject of over-allocating a designer to many teams is one I’d like to address in the near future.

    I also read the Paul Buchheit post you linked to. His comment about many ideas that sound good in theory turning out to be crappy in practice struck a chord. This doesn’t mean it’s a waste of time to try rough implementations of early ideas, but in fact the opposite: you should try them as soon and often as possible in order to see what doesn’t work. This pays dividends of its own beyond satisfying the familiar ‘user feedback early and often’ goal of Scrum. In doing so, you may discover other ideas or combinations that you wouldn’t have thought of otherwise.

    This technique is familiar to most designers. While in integration with other disciplines, design traditionally tends toward waterfall, internally, it’s very experimental and iterative: Designers are taught to throw down any early idea that comes to mind, avoiding self-censure in the beginning stages of a project so that creativity is not stifled and a maximum of concepts and freeform associations is generated. This has two benefits: you’re less likely to reject something that may pan out later, and you’re also more likely to find associations between ideas that your more critical consciousness might otherwise reject as having no promise themselves. It’s common for many designers to be most proud of those solutions that came about not from some immediate flash of divine inspiration, but rather from the ‘happy accident’ that arose from an open mind and the proper experimental approach.

    @Michael James

  3. Gareth Holt says:

    I’m new to this organisation, and starting to bring in some Scrum practices. There’s been a tradition of wireframing and sign-off before development starting which I want to get away from so we can start delivering value faster.

    I’m not sure whether the “wateration” approach as described above is the best approach. I can see IA/design taking place in the first half of the sprint and development in the second half. Even if we then re-work things next sprint, it’s getting away from stories being done done at the end of a sprint. I can’t really see this working.

    All I can come up with is some combination of the following: Get the Product Backlog in shape with all high priority stories broken down into small chunks and ready for development. Being ready should mean any IA/UCD work is complete at a story/backlog item level – maybe this can be done on a separate cycle, or one sprint in advance ? Do a Sprint Zero to set overall goals and vision, and allow time for high-level IA (and some systems architecture) to be done. More collaboration between IA, the SME and development – start working as more of a Scrum team.

    Anything else seems to go against the Scrum grain. I’m not the kind of person that would blindly adhere to a method, but I don’t want to get too far away from the ideal either.

    Any good suggestions welcome. Oh, and just to complicate matters further, the (small) team also has to support and maintain existing applications…

  4. Luke Walter says:

    @Gareth Holt
    I would strongly caution against your proposed approach of decoupling by default all UI design from coding by “completing” the design beforehand to get it “ready for development”. Sure, the larger and more encompassing the feature, the more waterfall-like you will want to treat its analysis and high-level design (the Information Architecture). But the smaller and more isolated a feature gets (more toward the User Interface side of things), the more you can design and build it on the fly, with minimal pre-designing.

    On the smallest features, all I usually get is a day or two of concepting before I present the wireframes or mockups to the team. We then have a round of discussion and feedback, and either decide which one we’ll try out in code, and/or I’ll do another round incorporating the feedback. Once we have a coded working prototype, we often revise or tweak it (still in the same Sprint, here), which may require revised mockups. For most small feature changes or additions, that usually gets us to something we like and that works. Occasionally, though, after revision and review, we still find it doesn’t really satisfy like we thought it would, and suggest a rework of it in the subsequent Sprint according to a new story that describes the desired changes. The point here is that the whole team is collaborating on the feature as soon as possible, and no artifact – mockup or unit of code – is considered final until the PO considers it so.

    I hear you on the desire to be finished with a feature by Sprint’s end, but remember that ‘done, done, done’ simply refers to a *story* being ‘potentially releasable’ at the end of a Sprint. That means it has to work to all expectations outlined in its done criteria, and be tested (if possible) and documented so that you could release it if you had to. But it doesn’t mean you have to. Also, a story does not always equal a feature; They can be written to quite focussed criteria that describe pieces of a feature. Assuming a story always does equal a feature builds in rigidity that will discourage the flexibility necessary to ‘inspect and adapt’.

    While I’m not particularly a fan of usability testing, the one sure benefit the practice seemed to offer was to break folks of the idea that ‘built-as-mocked-up’ was synonymous with ‘ready to release to the public’. Mockups and especially wireframes are really just illustrated hunches about what might be a good way to arrange an interface. Of course, this is a rhetorical argument; Obviously, the better the designer and the more time you have to critique and revise the designs the closer they’ll likely be to successful final interfaces. But those illustrated guesses are often proven incomplete or sometimes wrong once they’re built. Unfortunately, there’s no real substitute for having to build them to see.

Leave a Reply

Your email address will not be published. Required fields are marked *