Nowadays scrum is mainstream and has found its way into almost every company in the IT industry - agile methods have become standard in the field of user experience. But yes, there could be problems in the way of working between UX/UI Design and the development teams.
I really enjoy being part of a cross-functional development team and working in an agile environment. As a UX Designer it is very exciting that everyone can contribute their ideas and an interdisciplinary exchange is possible, which generates many new ideas and suggestions.
The way of working in a guild is useful to work closely with the UX and UI colleagues from the different development teams and to have a good exchange and get feedback here as well.
In the following article I want to show my best practices about time problems and struggles with UX in scrum.
The question arises - should UX/UI work in a time-shifted sprint or implement/test a feature in the same sprint as the developers? How to find a good way of working to combine Lean UX and Scrum? There is no secret recipe that works for everyone, but below are a few tips and hints on how it could work.
It's difficult when UX and UI Design don't participate in scrum meetings, because there's a risk that important insights could be get lost and the product release could suffer. It is important that a team has a common goal, which is to solve users' problems in the best possible way. Any changes made by developers should be customer-centric and designed with a UX strategy in mind.
When all team members are involved in the same product, everyone works on the same product mission. The usability of the product can be ensured when UX/UI design and developers work together on a common deliverable. A common understanding is created and misunderstandings can be reduced.
Integrating the UX sprint into the developer sprint is problematic in terms of time. How can usability tests be performed if the corresponding topic is already in the sprint? Timing issues can also lead to flawed designs.
UX strategy & process must be seen as a whole, in an all-encompassing Customer Experience. For complex research or designs, prototyping or wireframing must also be done early, tested, improved and retested.
Of course, this approach varies from team to team and must always fit all team members. In scrum retrospectives, this should be discussed again and again and adjustments must be made if necessary.
Above all, it is important that the members of a successful scrum team have one thing in common: they are able to take a step back and ask themselves what and how much is really necessary to do a good job in the team.
What are the key points to combine Lean UX & Scrum:
To save some time - a possible solutions could be to put the UX&UI issues at the beginning of a product backlog refinement to discuss these stories first. This way, business stories can be discussed at the beginning and then more technical stories can be discussed in the second part of the PBR, leaving out UX&UI.
If the criteria of a story are met so far, it can be included in the following sprint. Compared to a parallel sprint, the design is done and thought through before the development team starts working.
Definition of Done and UX Stories? How can this work and exist in the sprint process? To increase the quality of the stories, the UX requirements should also be integrated.
So it should be recorded that the User Story:
Another starting point for promoting collaboration is a design review, which should take place one sprint before the actual development. In addition to the team-building aspect, developers often have very good suggestions on how to build the product. If both sides get involved, this can work very well. You could split the design sprint into two parts through the design review, the basic creation of the design in the first part and the second part after the design review. The feedback from this session should be used to improve the previous designs and work on the details.
How could UX be integrated into classic Scrum meetings: How do story releases work and which team appointments are a must?
On this point, I guess every team has to find a way for itself how it works best. My personal experience shows, it should be a mixture between close working with the team and don’t join all the appointments. The Daily is very important to start the working day together and to be able to address and clarify problems even at short notice. Especially for stories it makes sense to participate in the PBR to clarify all logics and details how the feature should work. And at the same time, of course, to get feedback if there were any technical positives and / or negatives.
What should also not be missing - especially in a time of remote work – having a digital coffee break together or a small teambuilding game.
In general, however, you have to manage your time well, because all the sprint and coordination meetings take up a lot of time. To give yourself breathing space, just ask yourself more often if you absolutely have to be at the meeting and don't be afraid to cancel sometimes.
Basically, the way things are is not always perfect. Processes and deadlines must be regularly scrutinized and adjusted depending on the team constellation and changed circumstances.
Because a process is never perfect, it can always be improved. At the same time, you need to find processes that simply fit you and the team. Not every person is the same. Not every team is the same.
Start to ask yourself what are the deadlines of content and scope? What can be optimized? Does the team have enough time to work despite the sprint deadlines? Do you need to reduce deadlines? Working in an agile environment is subject to constant change, and you need to engage with it yourself.
Sources: