Based on our own experiences, we came up with a list of 10 rules at Usability LAB and RST Software. These rules will help you introduce a UX designer into your scrum process and team of developers. Let’s continue where we left off. Here’s the second part of our list.You can read the first part here: What to keep in mind when introducing a UX designer into your scrum team – part 1
6. Sprints must be planned with the UX work in mind.
A scrum team works to ensure that stories about a sprint are detailed, have well-defined approval conditions, don’t cause blockages or unnecessary dependence, are not overly long, and can be realised within the planned sprint.You should apply the same approach when planning UX work. However, during my very first scrum project, I noticed that my tasks were added to the same sprint as two separate stories: “Workflow and mock-up of mobile app” and “Workflow and mock-up of web app.” That’s all well and good – if you want your sprints to last at least 2 months each. :)
7. The UX designer should help with backlog creation and then deliver the agreed-upon MVP.
This rule is a direct continuation of the previous one – in order for a backlog to be properly prepared, the UX designer must actively participate in its creation.After all, they know best what work they will have to do and how many stories it should be split into. By having the UX designer work with the PO, you minimise the risk of overlooking or marginalising crucial tasks.
The UX designer’s participation in creating the backlog and determining the MVP also improves their self-discipline. Let’s face it – UX designers have a tendency to insist on making perfect, polished, optimal solutions (I do this myself). They often add a whole range of additional functions and put cherries on the top.It’s important to focus on the things that must be done here and now, not in the 7.0 release. A UX designer is a bit like a child let loose in a candy shop – someone needs to keep an eye on them. A well-structured backlog and a PO monitoring what must be delivered next should do the job.
8. The UX designer needs developer feedback.
Your UX designer doesn’t know all the technical stuff about development, and they don’t have to. Keep this in mind. That’s why it’s crucial to discuss their proposed solutions (e.g. during refinement) before they’re implemented. If you don’t do that, the ideas presented on mock-ups may turn out to be technically impracticable or very expensive to implement. What’s more, the UX designer, not having the same knowledge that developers have, may attempt to reinvent the wheel or kill a mosquito with a cannon, figuratively speaking.
9. Changes are normal, but they need to be accepted and planned together.
UX design is a process realised in iterations. Corrections, optimizations, or changes in requirements are unavoidable and this must be accepted, especially when a UX designer is to provide solutions from one sprint to another without creating an A-to-Z mock-up prior to the development process.The development team has to be aware of that and embrace that, while the UX specialist must remember that changes won’t happen on their own – first, they need to be communicated and talked-over with the team and the PO. A good practice for our team was “freezing” the mock-up to be deployed during the next sprint.
It turned out that views accepted at the refinement stage, and then implemented into the history while planning the sprint, should not be changed during the same sprint, especially when the developers have already begun working on them. Obviously, this does not apply to situations where something needs to be changed during work. However, if you come up with an idea to optimise, change, enhance, or improve certain things, you need to openly communicate with your team and agree on whether such a change can be implemented in the current sprint, or whether it should rather be included in the next one, or maybe it should wait until the next product development stage.
10. The UX designer can test and accept work.
The development team is usually quite surprised when the UX designer asks them for a link to preview their work, and then sends a list of remarks or proposed changes or corrections. How come? They already have a tester in their team to do that. However, you need to remember that the UX designer supervises the implementation in terms of consistency with the mock-ups (and often also with graphic layouts) and verifies that particular functionalities work as intended – in other words, checks the product in development in terms of user experience. Ideally, there is the time to conduct user tests.
Then the UX designer provides comprehensive feedback from the most reliable source. Instead of viewing this as a burdensome inconvenience, treat this extra pair of hands and eyes willing to test the things to be presented to a customer and end-users as an additional advantage of your team over other teams that do not cooperate with UX designersDo the above tips exhaust the topic of including a UX designer into the scrum team? Probably not. It is highly possible that the next projects I will take part in will bring new knowledge and ideas of good practices.
However, I do firmly believe that remembering the above will facilitate the organization of work within teams including a UX designer, and it will give you a chance to learn from others’ mistakes. :) You can read the first part here: What to keep in mind when introducing a UX designer into your scrum team – part 1
