There are entire user groups and businesses devoted to how to best fit UX into an Agile project. A number of models are emerging that discuss how UX fits and how sprints need to be structured in order to get the best out of UX.
One of the basic premises of Agile is “good enough” or “just enough.” This is NOT how waterfall projects are structured (they’re focused on “do it right” and “make it complete”). This shift in thinking is often extremely difficult for organizations and product teams. A number of the models address this shift in thinking.
So how do we do it?
The three most popular models appear to be:
1. Add a Sprint 0
In this model, the organization adds a Planning sprint to the project. During this sprint, the Product Owner (often a BA or Project Manager) works with the UX Pro to define the parameters and framework for the product. This typically includes:
- Initial market research and competitive analysis
- Initial product definition
- Initial product flows
- Initial user research
- Initial user goal delivery planning
- Initial user delighters identified
- Initial product wireframes and model definition
This is a LOT to include in a three-week sprint, and Sprint 0 is often given 1-2 months for completion. The goal is that when Sprint 1 starts, enough of the initial work is done that the product team can begin work with a reasonable understanding of what they’re building.
Pros: The product team has a clear understanding of the vision; the product team feels comfortable starting because they understand what they need to deliver; and the user research work is given the time it needs.
Cons: This is essentially a modified waterfall. The planning is mostly done up front, which means that it’s less of an Agile project. This makes small “a” agility more difficult in the project.
Austin Govella describes this as Modeling in his blog Agile + UX: Six Strategies, at http://www.thinkingandmaking.com/view/agile-ux-six.
Jean Claude Grosjean, an Agile Coach, calls this having vision in his blog at http://www.agile-ux.com/page/3/.
2. Use Parallel Track Development
In this model, BA/UX work 1 sprint ahead of the Dev/Test. Essentially, each sprint becomes a mini-waterfall.
Pros: The BA/UX work has plenty of time to “get it right” and talk to users who may not always be available. The requirements are clearly nailed for each user story, and dev clearly understands what their sprint goals are.
Cons: The vision can shift without the shift being communicated to the entire team. Dev/Test often feel like they’re not included and not told what’s going on. The user stories can be diluted/changed over time, and frequent re-shuffles are required to ensure that the project stays on track. The Scrum Master is really important in this type of project. Small “a” agility is reduced.
Jeff Patton describes Parallel Track Development in his Best Practices blog at http://agileproductdesign.com/blog/emerging_best_agile_ux_practice.html. His best practice is based on original research by Lynn Miller at Alias in 2005. (Check out the original article here.)
BTW – I highly recommend this blog. These best practices are considered to be emerging standards in the field.
3. Use Modified Kanban
Kanban is a type of Agile implementation where the work is defined and prioritized according to specific criteria, and it then managed in one-day increments. A compressed workflow is defined for the project, and the developers simply pull work from the queue as they complete it. The idea is that the prioritization is the driver, and that the team works on the pieces that have the highest priority.
In the modified version of Kanban, the workflow is defined so that the BA and UX work happens first, and then the dev output is user tested immediately.
Pros: The BA/UX work is done for each piece of work, and each team member knows exactly what the status of each piece of work is. The work happens really fast, and the business gets a constant update on where things are and what’s going on. It’s easy to add small “a” agility into the project by simply adding work or shifting priorities.
Cons: Because the Kanban process is modified, it’s not as fast as pure Kanban. Kanban is difficult to “sell” to the organization because it can’t really be timeboxed. When new work is added or priorities are changed, people are pulled from work that’s not yet complete (because it’s no longer a one-day exercise) – this results in a fair pile of incomplete work that often becomes lost time.
And the Verdict is…
UX and Agile can play well together, especially with some planning. I personally have found that three best practices are key:
- Using parallel track development
- Doing parallel user research
- Up-front research is extremely important
Oh yeah. And from recent experience? Make sure the entire team has taken some Agile product cycle training.