I lead a UX design team that is currently engaging with our devs in a waterfall-esque manner. I'm looking to integrate design with engineering within a Scrum process. I've read dozens of articles, a few books, done some online training, etc. None of it addresses how to integrate design considerations.

@jessehouwing They grok a bit differently to me. The related question is about UX testing, not UX design. There is certainly some overlap, though.
– Todd A. Jacobs♦Jan 6 '14 at 16:11

The edit to my original question fundamentally changed the question. I am looking for training resources, not a full answer within the confines of this forum. I think a full answer to this question is book length, not a paragraph or two.
– Lost in AgilelandJan 6 '14 at 17:15

Search questions, list questions, and requests for off-site resources will always be closed as off-topic. Please see the help center for details. I was trying to help you avoid having your question downvoted and closed, but you're certainly free to edit it further or roll back changes you don't like.
– Todd A. Jacobs♦Jan 6 '14 at 20:42

I agree with @jessehouwing, it other sites in the network say that it is often the answers that determine if the question is a duplicate. In this case, the answers to the previous question are still appropriate. In addition, looking for lists of resources are off topic because they quickly become out-dated.
– Dave HillierJan 6 '14 at 23:06

4 Answers
4

I've done Agile UX (UX within an agile SCRUM team) some years ago and doing it in-team and within the sprint isn't feasible. It's just "naive", because Agile is a developer workflow, not a design workflow.

I struggled a while until I recognized the many problems, that occur with that working style and looked around for help - and it is a quite common problem UX teams will encounter doing agile.

If you work within a sprint you will loose any big picture, if you had one before, because you are just working on small, detail leveled tasks.

There isn't time for doing usability tests and put the learnings back into prototype/specs.

However Agile UX is great, fast and compelling - you must to loose paperwork and talk and work with protoypes as specs. I love that way of working.

Best Agile UX practise is to:

Work in parallel tracks. One design track and one developer track.

Do your User Research, Big Picture concept, UX Strategy one or two sprints ahead in order to be prepared for the running later on.

Split your UX team in two teams: One is preparing the concept, prototype and tests the specs for the next sprint (n+1) and will join the dev team in this sprint (n+1) side by side. The other team is working with devs at the current sprint (n) and prepares the next sprint later (n+1).

Thanks for the reply. Your response echos what many UX people feel. What you're describing sounds like Dual Track Scrum. When you did this, did you have different backlogs for UX and Dev, or a single backlog that everyone worked from? Currently, my org has separate backlogs, and I don't think it makes any sense to do it that way.
– Lost in AgilelandJan 7 '14 at 20:44

@Lost in Agileland Different backlogs, because you usually work a sprint ahead in design phase. If your team moves to dev phase (n+1) you are more or less in a consultant position reacting on dev questions. Here you move along the dev sprint backlog. But if you feel it doesn't make sense - do agile your way! It's supposed to be customised ;)
– FrankLJan 8 '14 at 18:39

It could be that the implementation of scrum was naïve. It seems like it because of "loosing the big picture" and "no time for prototypes and feedback". These characteristics don't mesh well with the product owner collaborating with team on vision, goals, and roadmap continually. Also, I have done " spikes" for prototypes in sprints before and I see no issue with developing towards A/B testing or user interviews as a story. Me thinks your major issue wasn't scrum.
– ChapMar 26 '15 at 13:14

@chap No it was a scrum issue. For sure in an ideal world, with ideal scrum implementation it is supposed to work properly, but it didnt. In retrospective: one designer and six developer cant work in a team, because no time for "design research", just design implementation. No product owner with software competence. And if one builds a new software from scratch - agile isnt the best way for design. Or you give design two sprints buffer ahead for concept validation and problem-solution-fit via prototypes. But still its a development way of working, bad for design iterations.
– FrankLMar 28 '15 at 11:58

@FrankL everything you have listed here is about an experience with an implementation of "scrum" at your company. In fact, your interpretation of scrum in this post makes me think that you were calling what you were doing scrum but it wasn't really scrum. Scrum means iterations for everything! One thing you haven't mentioned yet is your ScrumMaster. Where is she in all of this? This is the person to back you up on UX. Just like testing, UX should be the priority of everyone on the team. Also, maybe your PO didn't see the ROI in the UX of a particular feature, which could be foolish or smart.
– ChapMar 29 '15 at 20:42

TL;DR

Scrum uses just-in-time analysis and design in its iterative development model. This certainly includes UX.

It is up to your self-organizing team to coordinate with one another to ensure that prerequisites like analysis and design are performed in a timely way, and that task and story dependencies are handled as efficiently as possible within the team and within each sprint. The Scrum process treats UX as an equal partner with development, testing, and documentation, so your team should too.

Just-in-Time Analysis and Design

The Scrum framework promotes just-in-time design, where the requirements, analysis, and design for each feature are performed within the same sprint as the development and testing of the feature. The iterative development model certainly creates some rework or refactoring, but that's the accepted trade-off to avoid "big up-front design."

Cross-Functional Teams / Full-Stack Stories

The key to integrating your UX design in Scrum is to ensure that UX designers are fully integrated into your Scrum team. They should be full team members, and should work alongside the developers and testers within each sprint.

User stories that include UX components should be included on the Product Backlog, and estimated and accepted into each sprint just like any other user story. For stories where it doesn't make sense to have separate UX design stories, you will want to include UX design within your Definition of Done and make sure that your Sprint Backlog includes the necessary tasks for the current sprint.

This was my thinking as well. I've read many articles that suggest having silo'd teams of developers and then ux. I believe the main issue with this thinking is that they are missing an important point about scrum, the cross functional team.
– ChapMar 26 '15 at 13:05

@chap But you miss a important point for design: design isnt implementation only. It is idea generation, research, sketching, testing, refine, testing, refine,... And the iterations doesnt always match one scrum sprint. There are a lot of delays as well, like stakeholder buy-in or commitment of C.D.-team. This way of working isnt handled well within scrum. My agile choice for design is Kanban, which is better suited for design workflows.
– FrankLMar 28 '15 at 12:10

@FrankL I'm not sure I follow your logic of how you came to the conclusion that I am missing a point of design. Where does anyone suggest that an entire feature must be done within one sprint? Also, I use kanban with scrum, it's not mutually exclusive.
– ChapMar 29 '15 at 15:48

There a couple of ways to approach the challenge, but (like some others have said) trying to force it into a framework that is meant for execution and measurement will just frustrate you.

Instead I recommend looking at models that are meant to complement the execution of known features. Some have described it as a "dual track" model, where you have some focused on discovering the next feature and other focused on the sprint execution of features already discovered. You can learn a little more about it via CoMakers (Jeff Patton) here. http://comakewith.us/dual-track-scrum-brief/

The problem with the term and drawing unfortunately though are that it lets people believe they can still tie it up in a nice pretty process box, but discovery and figuring out what to do next can get messy. That is why Scrum STARTS with a backlog at the beginning. Product Discovery and UX help you get a better backlog.

Here is my version that I use to explain the concept, but it is in now way meant to represent "the way".

The main points is that you have a team that has to play different roles and work that is in different stages, but the basic idea is that ideas go through a discovery, experiment and validation process and IF validated get added to a backlog that a team can pick up in a sprint and then those feature, once delivered, should be measured or looked at for new ideas to start again. One other think to note is that the "discovery loops" are not meant to show any time or size or velocity, but they should fast, continuous and valuable.

This is hard stuff and requires a lot of dedicated people and trust, since you aren't scheduling discovery.

What's the cycle shown within the Opportunity Backlog elements? The text is too small to read it clearly.
– Todd A. Jacobs♦Jan 9 '14 at 18:14

1

1. Assumption (Identify an assumption you have about your product and who the user might use it) 2. Experiment (Design a fast experiment that you can learn about your assumption) 3. Validate (Decide if your experiment validated your assumption or invalidated it or gave you a new assumption or experiment)
– Erin BeierwaltesJan 10 '14 at 3:09

+1 for an excellent infographic. While I don't personally agree with the dual-track approach when it leads to invisible or untracked work, I think you did a great job of explaining it as a viable alternative.
– Todd A. Jacobs♦Jan 11 '14 at 15:01

Thanks! Also, We often still use kanban like boards, but we don't use kanban metrics :) Visibility is still vital :)
– Erin BeierwaltesJan 12 '14 at 15:49

Altough I realize this is an old question I believe it is still relevant. I am currently in the same situation. That is, trying to figure out how to best implement the UX perspective into a scrum process.

We do not have the resources to allocate a UX-designer per se in the scrum team but we do have different people responsible for areas such as navigation, design and accessibility - all of the essential components of the user experience.

Our current solution to this (which granted could very well change during the course of the proejct) is to let design manuals, accessibility checklists and navigation principles guide the developers in their efforts to solve the user stories/tasks at hand.

We also realised early on that there could be user stories where the answer could not be found in those guidelines or where it could become a matter of interpretation. Therefore we've opted for a "UX-group" made up of the three people responsible for design, navigation and accessibility, together with a external consultant (for an outside-perspective). This group will look at the prioritised user stories and have the mandate to add UX-relevant acceptance criteria to them, to further guide the developers and promote a holistic approach to the user experience.