Based on our own experiences, we came up with a list of 10 rules at Usability LAB and RST Software Masters. 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, optimisations, 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.