I’ve been studying both UX Design and agile methodologies such as Scrum and eXtreme Programming in the past two years. And I always noticed some similarities between both processes of an agile approach to working on a project and UX Design user-centered design approach, for example both UX Design and Scrum use User Stories and US Mapping. But I never figured out how to actually incorporate a UX Designer in Scrum for example? Should a UX Designer do his/her job before acquiring the product backlog? During each sprint? Can anyone help me understand how can it be done?
We use an Agile approach to our work at UXMastery. We create stories for each UX task and incorporate them in the sprint in the same way you do with other tasks. i.e. they don’t do their work first or outside of the Sprint.
Does that make sense?
Sort of, seems doable in certain projects. But shouldn’t the UX process be done with before beginning the scrum process sometimes? Or at least before you start sprint 0 or 1, since the backlog at that point contains stories and not tasks, once it’s chopped to tasks I believe it becomes harder to sync the UX process with the scrum process.
I’d say no – it should be done before certain parts of the scrum process. i.e. there are some UX stories as part of a sprint. You don’t have to complete an entire epic across one sprint.
So the UX aspects of Epic1 might be part of Sprint 1. Then the resulting work could be part of Sprint2.
I would love to see a fake simple project, in list/bulleted form - kind of a step by step process for UX/Agile/Scrum. I think it would help a lot of beginners to see the “flow” - or at least, what should be the flow.
I second that. I don’t have much experience in Agile UX, would love to see what it looks like.
Here we’re using Agile with some of the team and we expect to expand this methodology to the whole company soon. And (I have no definitive answer here) today we don’t consider the UX deliverables inside the sprint (and I tried) because we don’t have enough time to think about the solution, consider every user scenarios, talk to the developers, test hypotheses, talk to the stakeholders, define the business rules related to the project, make adjustments and release the structure, prototype and interfaces in a two week sprint. The devs would spend most of the time waiting for us. So, by now, we finish all the UX before we start the correspondent sprint. Actually, the POs uses our deliverables to write the stories because we studied the user journey and probably all the scenarios. That’s how we’re working here today perhaps because we’re not structured as multidisciplinary squads yet or perhaps because we wouldn’t be able to work another way even if we had the perfect squad formation. Suggestions are welcome.
This is such great insight. I never thought about how the ux deliverables are not on the same time frame as sprints. So what stage of UX would be suitable for Agile? Post design - iteration stage only?
@fabricio_kassick, a couple of things…
- Check out the book User Story Mapping by Jeff Patton
- Check out the book Lean vs. Agile vs. Design Thinking by Jeff Gothelf
- Check out the book Lean UX by Jeff Gothelf
These books will give a lot of “how it should be.” (The 2nd one is really short, maybe 50 pages.)
When doing Agile and UX together, you want to start a sprint or two ahead (more if you can) to do discovery research and get an idea of the overall problem. (This is called Sprint 0.)You do not want to worry about the overall solution at this point. Your deliverables can fit in with the sprints by chunking them really small. For example, research on one target audience group for 2 weeks with a presentation of just that section of research on demo day. Or competitive analysis would be one 2 week sprint. A sitemap would be one sprint with maybe a few other small things thrown in there. Also, remember to keep iterating on your research.
When I was on a squad doing Agile, I did usability testing every week for 4 hours with whatever I had available. You need more support, such as people helping you with the logistics of user research. Also, one to two designers per squad, depending upon the product is a good way to structure it.
If you are starting to fall behind what the developers need, do a sprint spike. This is a one or two-week space for UX to catch up and developers can do a lot of other things, such as optimizing code, in-depth code reviews, reviewing architecture decisions, etc. Development isn’t just about writing code.
Hope that helps!
@david01 Julia covers it off pretty well in her post above. Does that clear things up or would an example project still be useful?
Very good information. I’m open to an actual example - but that reading is a good place to start.
That’s great @jdebari,
this is a very structured way to integrate our work with the Agile teams. I’ll share with people here. Best
@david01 How do you want to see a project example?
For example, I was working on designing an application platform. I was on 5 individual scrum teams (a lot of meetings). I was the only full-time designer. I set my schedule around what the engineers were working on. The different scrum teams focused on different parts of the application. Some Scrum teams were just engineers because it was technical architecture or something that needed no user interface. But if there was any user interaction then I had a part of the scrum team.
Hope that helps.
Thanks! Yes, I am in scrum meetings every morning with my team. The one assignment I had so far was to research the best tool we could use for design & prototyping in our environment. I completed this, and now need to give a presentation on how I think the UX/UI process will work in our environment…the process…tools used…so I’m hoping my presentation goes well
Thanks for this thread. My new employer thinks I’m going to implement Scrum, when I’ve never had the good fortune of working in that environment. I’ve done exhaustive research for him on Scrum and Kanban, as we’re a design agency and contract out development. I really don’t think it will work, but thank you for the examples of the UX sprints needing to happen before the dev sprints. I was not getting that specific information elsewhere, but I suspected that’s how it should go.
Now, a question. Are there ever UX problems discovered after the stories go into the dev sprint? Do you pull designers into the sprint in progress to correct or just push through and then design problem-solve next sprint?
Hi @ref_design - I’m a newbie at this but I would guess that it would depend on several things -
-How big of a design change it is, and how many hours will be required
-How far into the dev sprint they are
-How the team wants to handle these kind of changes - create a process
We are still using sticky notes on a board with 4 “swim lanes” - but we have plans on moving to a digital board at some point by years end. We keep our scrums to 15 minutes and identify:
-What was complete since last scrum
-How many hours did it take for each
-What will be focused on until the next scrum
-Add any new tasks from the “parking lot/backlog” and assign them
At first, admittedly, this all seemed a little much to me - and at times still does - but I’m starting to see the value in keeping everyone on the same page, tracking hours for budget needs, etc. In my previous development life, it was more waterfall, and I wasn’t too involved with the details to this extent. But I think it’s valuable to learn and know, and allows you to contribute to the overall goals.
@ref_design, Honestly, Scrum and Kanban are more for development. If you are a design agency that does not do development, I don’t see fully implementing either process that helpful. I assume you do all the design work and then hand it off to a development agency?
I would take a step back a bit and try to find out why your boss wants to implement Agile processes. There are pieces of them that may be useful, such as the daily scrum meeting, but worrying about story points, velocity, and sprint demos might not be useful.
Perhaps have a look at the book User Story Mapping by Jeff Patton.
UX problems are frequently found after stories go into a dev sprint. Depending upon the size of the issue the designer steps in or if it is too much, then waits for a later sprint.
The important thing to take away from Agile is that it does work in small chunks and is very iterative. UX can work with Agile, but be very judicial about what parts of the process you implement and iterate on your process as well.