Scrum Agile Project Management

Two Ways Agile and UX Can Work Together

This article presents the value of integrating just-enough user-centered design (user experience or UX) in an Agile development process like the Scrum approach of Agile project management.

Author: Niki Dare, UX Manager, Asynchrony Solutions

We all know design is important in the development process, even in projects developed through Agile methodology. But how far will just-in-time design really get you in creating a great user experience? Integrating usability and design into the agile process is a hot topic right now. Many people have offered up opinions, including taking advantage of Iteration zero and infusing each story or task with user-centered design principles. But the big dilemma still remains. How much upfront design and usability is too much to be considered Agile?

Two Ways Agile and UX Can Work Together

As a designer, I have been fortunate enough to be a member of several development teams that each followed their own unique process. Although what works well for one team doesn’t necessarily suit another team’s needs, the principle of integrating just enough user-centered design can be applied successfully within almost any agile development project:

Pre-Iteration Planning

Truly embracing Iteration zero, I have found pre-iteration planning to be extremely effective. This tactic works great if you have a client that knows what they want about a week in advance and is willing to mostly stay committed. Essentially the user experience team works an iteration ahead of the development team. A short pre-iteration planning meeting is had with the client to determine their upcoming needs for the next iteration. Often we have had these meetings on Mondays and then the development team is able to estimate the upcoming iteration’s work that Friday based of the user experience that the design team envisioned. Depending on the client, guerilla usability testing or un-moderated, remote usability testing on low-fidelity wireframes fits in nicely with this method since both can be prepared for quickly and yield an immediate response.

This method is most successful when there is an overall understanding of the application and its functions that is agreed upon. It also helps when the stories that are slated for upcoming iterations are somewhat related so some thought can be put into the user experience of a given workflow.

Minimum Marketable Features

The idea here is that a succinct set of tasks are identified as a minimum marketable feature. This feature, that should take no more than a couple of months to complete, is then well-defined and understood by the user experience and development teams. Similar to using iteration zero, it is best to allow the user experience group to be a feature ahead of the development team. For the first feature it may be helpful to start with something that is development heavy.

During the couple of months that the development team is coding a feature, the user experience group has a bit more time to breathe and conduct moderated usability testing to drive the creation of their wireframes, walkthroughs and screen mock-ups. Since this method mitigates features from being partially implemented (because the development team can’t move on to the next feature until this one is complete), the whole user experience can be evaluated and summative testing can be conducted after development is complete. The results from the usability study can be slated as an upcoming, minimum marketable feature.

Formative Testing vs. Summative Testing

Both methods include formative testing, or the testing that is done on low-fidelity prototypes before coding begins. Validating any new additions to the system, this type of testing is very beneficial to maintaining a good user experience. If you have an existing project that has not been focusing on your end-user’s experience and you are looking to incorporate user-centered design, then Hurrah! Welcome Aboard! Unfortunately you will have to set aside time to conduct some summative usability testing on the existing system and be willing to take action on those results. The most effective method is moderated testing conducted on-site so that the users can be observed directly and probed for as much insight as possible. Creating a test won’t take long once there is a good understanding of the system, but if user experience hasn’t been the main focus in the software development process then you may be in for a rude awakening.

The actionable items coming out of those results could fill an iteration or more, or even a release. The best thing to do is to conduct usability tests on individual processes or tasks in the system and then act immediately on the findings. Try to keep the scope of the test as narrow as possible so scripting the test is quick and too many development tasks don’t result from the testing.

The Danger of Only Doing Just-In-Time-Design

The Agile development process boasts doing activities just-in-time to mitigate waste and allow for requirements to change even while code is being written. Just-in-time design can work in cases where a high-level design or concept has been created and approved. It is easy to add an additional screen to an application with a well-thought-out user experience. But doing true just-in-time design can run the risk of losing sight of the big picture and creating a disjointed user experience or having to rework previously developed screens when new ones are added. I think just enough design work creates a better, more cohesive end user experience, saves time in development and ultimately saves the client’s money for adding in even more features.

As far as just-in-time usability is concerned, we must operate within each project’s specific time constraints. Formative testing can be conducted rather quickly and in-sync with shorter development cycles. There is no question that if the user is satisfied with the proposed system before it is built then there will be less rework when the software is released. Summative testing requires a couple of weeks at least; especially if it is being conducted on a system that wasn’t user-centered in the first place. A system can be dramatically improved from the results of summative testing, especially the first few rounds. Summative testing must be done after development of a feature or task flow is complete so that the user experience is cohesive and able to be tested by end users. The only aspect of a summative usability test that I would even consider to be just-in-time would be acting on the results of the test in the next possible iteration, above any new features.

I have yet to discover a blanket strategy for seamless integration of design, UX and usability into the agile development process. I think the best thing to do is understand the needs of your client and development team the best that you can and then start trying things until you find a good fit. Don’t be afraid to throw out an idea if it isn’t suiting everyone’s needs. The road will be bumpy, but don’t give up. Your users will thank you for thinking about their experience.

2 Comments on Two Ways Agile and UX Can Work Together

  1. You’ve wondered into a controversial area. In a perfect world (which we know does not exist), software developers, UX developers and testers are one unified team working on short sprints. The problem with this theory is simply that good UX development can be a huge time sink. The end users never know what they want until they see it. The back-and-forth required to reach consensus on the UX can easily take weeks.

    I find that it’s best to shelter the software developers from much of the UX development. They tend to get frustrated by the lack of consensus and the delays. For that reason, I like the sprint zero approach and/or some type of parallel track for UX and software.

    Thanks for sharing your insights!

  2. Good article and without doubt a hot topic in the community at the moment.

    It mentions above “Essentially the user experience team works an iteration ahead of the development team. A short pre-iteration planning meeting is had with the client to determine their upcoming needs for the next iteration. ”

    Can you confirm if implement production as a firm team split ? What I mean by this is, do you actually commit to be part of the development team as well, to implement and support the designs. In our setup we aim to have top level design which is available to the team and we mix designers into the production teams who work on implementation, but also awareness of the next sprint where they can plan slightly ahead. These plans/ideas are discussed with the PO and team halfway through the sprint for clarification. For us this works well as we deliver a working prototype as a cross-functional team for the sprint review which invites feedback early into the product.

    Also if there is a split in the teams as above, design quality can decrease by working in isolated disciplines/functional units? I have seen designs improved where designers discuss and work with developers for instance as designers can be made aware whats possible or not. On the reverse it can reduce time by providing discussion on alternatives etc.


3 Trackbacks & Pingbacks

  1. Software Linkopedia April 2011 | Software Development Musings from the Editor of Methods & Tools
  2. TapaGeuR » ITGIF – “IT-God” It’s Friday #23
  3. Agile and User Experience « Agile, Lean and Scrum

Comments are closed.