Here’s the big pay-off. We learned in Parts 1, 2, and 3, why UX and Agile complement each other, who the various players are across the teams, and how to build towards a minimum viable product (MVP). So now that the MVP is off and running, the UX team must figure out the best way to continue to work with the Agile developers. But how? How do UX designers continue to bring value to the customers and business while their Agile cousins keep iterating on the product? It’s like trying to load groceries onto a merry go round at full speed.
Fortunately, Agile provides a terrific framework for regularly collaborating with all the players be they the Product Owner (PO), customers, business analysts (BAs), or developers. Scrum teams typically hold various “ceremonies” throughout a sprint where the UX team will find opportunities for integrating their work. For our purposes, let’s focus on five of the most common ones. Note that none of this is set in stone. As you examine the Agile methods you use, find opportunities for engaging with the UX team similar to:
- Backlog Grooming
- Sprint Planning
- Daily Stand Ups During the Sprints
- Sprint Review
- Retrospective
In order for the UX team to guide the creation of the MVP, they needed lead time to do the initial research such as customer interviews, metrics reviews, and competitive analysis. This research typically occurs during Sprint 0, before the developers start writing code, and contributes to the backlog of proposed work. Now that the MVP is in place, the UX team has to work through that backlog while continuing to research and test improvements to the product.
Backlog Grooming
As customer advocates, the UX team continues to push for improvements that bring value to the customer. This starts with an assessment of the backlog. The UX team, the PO, and perhaps the BAs review the backlog, reprioritize the stories, and write new stories based on their initial research as well as any immediate feedback/metrics regarding the MVP. They are looking for the most pressing use cases that bring the highest value to the customer by considering the following:
- Additional detail gathered regarding the customers’ needs
- Changes in the goals of the business
- Ways to minimize risk while building new capabilities for the customer.
Once the UX team, PO, and BAs are comfortable with the notional prioritization they break the design requirements into manageable user stories. They then go into Backlog Grooming confident that they are still building the right product. Next, the developers determine how to go about building the next chunk of functionality. Backlog Grooming gives the UX team the opportunity to have quality face time with the developers as they groom the stories. This is a time the UX team can use to:
- Introduce the initial UX designs for the next set of functionality, such as interaction design, layout, and visual design. This gives the UX team time to highlight the customer and business value that the designs bring.
- Determine if the design makes sense from a technical perspective and whether the developers have recommendations that would improve performance or even usability. Presumably the UX team has already conferred with the developers to ensure the design is feasible, but this is a chance for the whole team to weigh in.
- Decide whether the requirements for the design should be contained in their own stories or if it makes sense to combine them with functional stories.
- Define the “Definition of Ready” as it pertains to stories that contain design tasks. Depending upon the complexity of the design, discuss the details of the acceptance criteria for the stories, and determine the level of fidelity of the wireframes / mock-ups that’s needed. The UX team will need to provide the level of detail that is “most responsible.” That means the developers see all of the detail they need to build to the design correctly without requiring the UX team to over-design. Sometimes they’ll need a working prototype, but sometimes merely a sketched wireframe will do.
Sprint Planning
Depending upon how the development team has mapped out its ceremonies, Backlog Grooming easily flows into Sprint Planning. Accordingly, Sprint Planning is another important occasion for the UX team to work face to face with the developers. Together they should pick up any work during planning that they didn’t complete during grooming and finalize how they are going to build the design stories.
The goal for the UX team is to ensure that the sprint concludes having brought the highest value to the customer. To do so, the UX team must provide the resources that the developers need to succeed. That includes:
- Furnishing the designs at the most responsible level of detail
- Talking through the stories and answering questions about the design
- Agreeing upon the acceptance criteria for each design story
- Recommending how the developers should assign points to each design story.
Once the entire team has discussed the intricacies of the story they agree that it is ready to be worked.
During the Sprint
While the developers are writing code for the current stories, the UX team is actually working on the designs for the next sprint and simultaneously evaluating the previous ones. To keep ahead of the developers, the UX team uses the upcoming stories to:
- Update the personas to account for any changes in customer needs
- Map out the user-flow of the upcoming functionality
- Assess the information architecture and navigation
- Create wireframes, prototypes, and/or visual designs
- Test the new hypotheses and designs with customers
At the same time the UX team validates/disproves the previous hypotheses they’ve made and evaluates the current customer experience. This entails:
- Holding usability tests
- Assessing metrics that reflect customer and business value
- Performing satisfaction surveys
- Using the above to recommend improvements to the UX design
Nevertheless, to stay in sync with the current sprint the UX team continues to collaborate with the developers. They attend daily standups to check the pulse of the current development and answer questions about the design stories. They also pair with the developers to work through any design challenges and finally, they assess if the acceptance criteria have been met from a UX standpoint.
Sprint Review and Retrospective
Once the developers deliver the functional and UX updates, portions of the entire team take part in the Sprint Review, the Retrospective, or both. During the Sprint Review the developers and BAs present to the stakeholders all of the work that’s been accomplished over the sprint. This is an important opportunity for the UX team to restate to the stakeholders the customer and business value that the UX improvements bring. Because the team has broken the UX work into small chunks, and the value to the customer is more incremental, there’s a risk that the UX work will become marginalized. As such, it’s imperative that the UX team emphasize the improvements they’ve made if only to justify the work they need to do going forward on behalf of the customer.
During the Retrospective, the developers and BAs discuss how to improve their processes and their working relationships. It’s important for the UX team to attend as well if only to confirm their role as part of the broader team. Furthermore, this is the best time to assess how well the UX team engages with the developers and the BAs. The UX team works very hard to uncover the many subtle nuances that will improve the customer’s experience. Accordingly, it takes durable collaboration among the UX team and developers to build those improvements correctly. The Retrospective gives both teams the opportunity to fine tune that collaboration.
The Gist
UX as a practice evolved as part of waterfall development. Nevertheless, an Agile team can absolutely take advantage of the riches that thoughtful UX methods bring to a product. The best way to take advantage of the UX team is to let them advocate for the customer and ensure you’re building the right product at all times. The UX team:
- Provides vital feedback regarding each iteration of the product, which supports Agile development
- Tests hypotheses for providing the best solutions with the least risk
- Gives the developers just enough design for them to iterate on the product and meet the acceptance criteria
- Coordinates customer value and business value so each sprint concludes with tangible improvements to the user’s experience
A product is never done. But you’ll always know what to build next by integrating your UX team with your Agile developers.