I can see 4 ways of UX fitting in with an Agile methodology like Scrum – and remember Agile is the philosophy, Scrum is a methodology for doing Agile. It can be problematic because the UX process and the Scrum sprint format don’t naturally sync together. Like a relationship, you have to work at it for both parties to be happy.
These recommendations are based on my own experience of several years working in Agile teams, and recent research of other people’s stories. Your experiences may differ…
Light
This light approach is the least disruptive and easiest to do. However, there is a some risk that the Scrum team, including the Product Owner, rejects some UX input for the simple reason that UX people aren’t present in the Scrum team all the time. They’re not there during the daily standups and so can’t defend UX when the team makes decisions like choosing which user stories to develop from the backlog.
There are 3 ways to intervene with this light approach, and you can combine any number of them as appropriate:
1 – A UX sprint before dev work starts [Minimum]
A UX research team defines the requirements, personas, user journeys, and wireframes of the whole application before dev work starts. They also validate the wireframes through conceptual walkthroughs with the customer and testing with users. It is important to have a detailed interactive prototype that the dev team can play with to get an instinctive feel for what they will be developing. This should include precise behaviours that the interface should demonstrate according to different user interactions. This is better than dense written specification documents as no one wants to read those.
The Product Owner from the Scrum team is a member of this UX research team. When they start dev work, they define and choose user stories from the backlog which respect and support the design, and they can defend or further explain details of this design to dev team members.
It is possible that no UX people will attend dev meetings, but they must at least be there to present the prototype to the Scrum team for the first dev sprint.
In principle this is a one-shot deal for the UX team, but in reality they should intervene again near the end of the dev work, to test the final working application. There is a risk that developers have made changes to the interface or workflow without consulting the UX team in order to work around technical issues. Enough time should be built in to the schedule to smooth out these modifications and retest.
2 – Design spikes [Minimum]
If dev work has already begun, we can add value by helping the Scrum team to validate prototypes through user testing or other types of evaluation and communicate the benefits in Scrum terms – ie defining what user stories are really worth working on, thus making significant time savings.
This approach requires no change in schedule or work method for the Scrum team, and the UX team can intervene at any time during or after the dev work. However, the Product Owner and perhaps the Scrum Master should take part in the UX activity, communicate the results to the Scrum team, and put those results into practice.
It is possible that no UX people will attend dev meetings, but it would be good if they helped the Product Owner to communicate the results of the UX input to the Scrum team.
3 – A parallel UX team partially integrated with the dev team [Recommended]
As before, the Product Owner is a member of both the Scrum Team and the UX team. Both teams work in parallel, but the UX team still needs to start at least sprint or two before the dev team.
The UX team has an idea of the overall application and defines the user stories through a research phase before the dev team starts work. At this point they can take 1 of 2 approaches:
- If they have enough lead time, the UX team can research and create a prototype of the complete system, and deliver it as the stable product vision to the dev team. They then act as a support role to help developers translate the details into a working product. They do this by being present in certain meetings or even by sitting in the dev team 1 or 2 days per sprint.
- If they don’t have much time, the UX team and the dev team agrees which user stories they will focus on and in what order, then in each sprint the UX team will produce narrow and deep prototype chunks to illustrate the user stories that the dev team will work on in the following sprint. The UX team carries out user testing to validate each chunk before they deliver it to the dev team. There are regular meetings with at least the lead UX person, the Product Owner, and the Scrum Master to communicate the details of these prototype chunks. As in option 1, a UX or UI person is available to support the Scrum team in case of need.
This approach attempts to emulate full integration of the heavy approach, but without the tensions that can go with it.
Typical scenarios in the light approach
These are the usual scenarios for how we can combine approaches:
- Just approach 1 (UX pre-sprint) – This sets the Scrum team on the right course, but then the UX team is not around to help with course adjustments.
- Just approach 2 (UX design spike) – This can add great value at any time but it cannot make fundamental changes, even if they are needed.
- Approach 1 and 2 together – This optimises chances of overall success with the lightest touch. We tried this in my work at Five by Five with various clients, and it worked out quite well given the constraints you are usually under as a consulting agency. One downside however is that because it is still a light approach, finer UX details may slip through the cracks.
- Just approach 3 (parallel work with partial integration) – This maximises chances of overall success, and the small details that can have big effects are not forgotten. The UX and the dev team get to know each other better and have a greater sense of shared ownership and responsibility for the product.
Heavy
If done well, this approach could see the biggest benefits, but it is the most disruptive with no guarantee of good results. It is very hard to do and some people even think it is fundamentally impossible. I worked like this for several years in various teams, with mixed results and a lot of arguments with developers and managers!
4 – Direct full-time integration of UX people into a Scrum team [Not recommended for most projects]
This approach needs advance planning, A LOT of goodwill from developers in the Scrum team, and a Scrum Master and Product Owner who are motivated by UX. The UX people and Scrum developers need to have a good relationship, and the UX people should never be seen to dictate the direction of work to the developers, without referring to objective user research or testing.
Both the Scrum and UX work cycles need to be modified to allow at least partial synchronisation. A method needs to be found to accommodate the transverse nature of UX work with the narrow and deep nature of dev sprints. The UX team will share the Agile customer role with the product owner.
The usual approach is that the UX team starts a sprint or two before the main dev work with a research phase. The UX team then has an idea of the overall application and proposes a list of use cases which are more abstract than the usual Scrum user stories. The Scrum Master or Product Owner then translates these use cases into Scrum user stories. Then in each sprint the UX team produces narrow and deep prototype chunks to illustrate the user stories that the dev team will work on in the following sprint (so that mean the UX team is always one sprint ahead).
If the UX team doesn’t have enough time in each sprint to user test each prototype chunk, user testing of larger chunks or even the whole application prototype will need to done at some point. The team should build in time to make adjustments according to the results of this user testing.
The UX people are there to defend their designs in the daily stand-up meetings, sit near the developers and closely collaborate with them to find alternative solutions to design problems, so that the application keeps on course and stays aligned with the prototype.
