Can UX Designer be part of the scrum team ?

If you view UX work as a specialization to be done "asynchronously" from Scrum teams, then perhaps you may not want to have UX within the Development Team.   I have seen organizations where skills and specialization like architects, UX, etc. are involved in refinement activities for multiple teams, but are not involved in the actual sprint work of any Development Team.

Please note that I said you "may"want to choose that option.   That approach however may not adhere to Scrum.   The Scrum Guide explicitly states that Development Teams must be equipped with all of the necessary skills and capabilities needed to deliver a potentially releasable increment of "Done" work each sprint, and that there are no roles based on specialization or skill set  within a Development Team (no exceptions!).

Is the work of the UX designer needed for the Development Team to create a "Done" increment of release quality by the end of a Sprint?

I would not say that it is against the rules of Scrum to have the UX/Designer outside of the development team. According to the Scrum Guide It's the Product Owner's responsibility to ensure that the Development Team understands items in the Product Backlog to the level needed. There is no definition of how this should be done, so I'd say that it can very well also include UX concepts, which then are further refined together with the development team, estimated and finally implemented by the development team during a sprint.

Other opinions to discuss on this very welcome.

he Scrum Guide explicitly states that Development Teams must be equipped with all of the necessary skills and capabilities needed to deliver a potentially releasable increment of "Done" work each sprint, and that there are no roles based on specialization or skill set  within a Development Team (no exceptions!).

 

Thanks Thimoty, so i guess from your answer that if i want to respect Scrum Guide, Ux designer should be part of scrum ?

Ian : Yes I need the UX designer work to create a done increment.



Steven : So for you,  it's necessary to have the ux designer inside the scrum team but he could work very close to scrum as a provider ? 



For me, I feel UX designer should be part of scrum. But i'm not sure it will respect scrum guide ;)

 

If the UX designer is needed for the actual development effort during the Sprint, in order to create a Done increment, would the Development Team be adequately cross-functional if it did not include that person?

Hi Renaud - The challenge I have always had with UX Designers is that they were never needed 100% of the time on one team.  More often than not, they had enough capacity to assist 2 or 3 teams.  I have tried three options:

1. Have a UX person grow their T shaped skills by picking up coding skills beyond design, html and css - this is a challenge for many UX folks, but some can pick up javascript.  If you have a person that can do both, then this is your best option.
2. Having the Development team learn UX skills - much harder than option 1.  
3. I have seen teams have the UX Designer be one or two sprints ahead in his or her designs, but this is not preferred.  Yes it feels like a version of waterfall.  I don't like handoffs either, and it adds complexity to planning.
4. The third option and most challenging is sharing the designer with another team.  Not recommended.  This will put stress on both team's Sprint Goals, and stress out your UX person.

While there isn't one best answer, option 1 for 2 is what could work best in Scrum because it give the development team the cross functional skills and capabilities to deliver a 'done' increment within the sprint.  

@Ian

If the UX designer is needed for the actual development effort during the Sprint, in order to create a Done increment, would the Development Team be adequately cross-functional if it did not include that person?

No, it would not be cross-functional. But while the work of the UX designer might be needed to create a Done increment, the UX designer himself might not be needed. The work of the UX designer can very well be part of the requirements. It depends on where and how you draw the line between requirements and actual implementation of the requirement.

@Renaud

Steven : So for you, it's necessary to have the ux designer inside the scrum team but he could work very close to scrum as a provider ? 

It depends.



In some situations you have UX designers, who are working very close together with the development team, maybe even sharing work. A user story is pulled into sprint, some of the work is design, some is pure coding, some something in between, but all can be done in one sprint by some of the team members working together and nailing it down. For sure this kind of designer should be part of the development team, as they work together on a daily basis and all the work can be done in one sprint.



In other cases, there is the kind of UX designer who's not touching code at all, but working very close together with PO and stakeholders by analyzing user behavior, doing wireframe testing etc to come up with interaction designs and helping the PO to define what a feature should look and work like to best fit the stakeholder's needs. In this case, UX is more like part of the requirement and therefore more behaving like a stakeholder, not directly participating in Scrum, but of course being available for questions if there should be any.



From my point of view, it all depends on how tight the people are tied together when it comes to the actual implementation of the product.

No, it would not be cross-functional. But while the work of the UX designer might be needed to create a Done increment, the UX designer himself might not be needed. The work of the UX designer can very well be part of the requirements. It depends on where and how you draw the line between requirements and actual implementation of the requirement.

Can you elaborate on that?

I understand that the PO may use a UX designer to feed into PBIs, but surely that's making the assumption that such work will be used.  Isn't that 'pre-work' potentially waste and part of what we're trying to avoid? 

I would also be concerned that the development during the Sprint might feel restricted because of UX 'pre-work'. "It's already been designed this way, so let's just go with it."

No, it would not be cross-functional. But while the work of the UX designer might be needed to create a Done increment, the UX designer himself might not be needed. The work of the UX designer can very well be part of the requirements. It depends on where and how you draw the line between requirements and actual implementation of the requirement.

Yes, I believe that's the critical point. If the UX designer is needed for the actual development effort during the Sprint, then he or she might need to be in the Development Team. It would then be sufficiently cross-functional.

If the UX designer is needed to assist in the formulation of Product Backlog Items - but not during a Sprint to create the Done increment - then that person may instead be seen as a stakeholder whose input ought to be managed by the Product Owner.

@Alex

I understand that the PO may use a UX designer to feed into PBIs, but surely that's making the assumption that such work will be used.  Isn't that 'pre-work' potentially waste and part of what we're trying to avoid? 

I would also be concerned that the development during the Sprint might feel restricted because of UX 'pre-work'. "It's already been designed this way, so let's just go with it."

There might be waste generated, but not more than with other work done upfront to define what has to be done. Like anything else when it comes to getting stories ready for implementation, also the UX as part of the requirement shall be refined by the Development Team even in discussion with the UX designer, as well as its implementation be inspected at Review to decide what needs to be done next to improve further. So it's not about disconnection and building silos.

@Ian

Yes, I believe that's the critical point. If the UX designer is needed for the actual development effort during the Sprint, then he or she might need to be in the Development Team. It would then be sufficiently cross-functional.

If the UX designer is needed to assist in the formulation of Product Backlog Items - but not during a Sprint to create the Done increment - then that person may instead be seen as a stakeholder whose input ought to be managed by the Product Owner.

Great we could clarify that. I think this is an important perspective, as many teams struggle with the problem that they kind of need the ux/design as part of the requirement to even start the actual implementation, but think they would completely go against Scrum when doing so. But there are such kind of situations, especially when there are multiple teams.

Thanks for all your comments ! It gives me a lot to think about. It's really a hard topic, how to make a fluid process between design and development ?



I think for the moment we will keep he UX designer out from the scrum team and make him a vip stakeholder.

Maybe it could be great to redefine how to make interface and development in same time during a sprint. 

That means we should have t shaped dev how can deal with front and back. Big revolution here :)



Have you experience something like this ? For example, UX designer is only called to create the big picture and create some "template" and "graphic component" that dev could use to create easily page and make the daily job.

@ian @timothy @steven @chris @alex : I want to really thank you for your answers and cant wait to have feedbacks on your experience. 

The team should limit work in progress as far as possible, so features are completed earlier and more frequently during the Sprint. This will create multiple opportunities throughout the time-box for stakeholder collaboration in getting to Done, although a Development Team should avoid having any critical dependencies upon them.

Where a stakeholder is not a Development Team member, the PO will need to manage this, since he or she must be accountable for all stakeholder interests being properly represented.

@ian : fully agree

I did a search on this topic because I am writing an article on UX strategy. There are a number of problems with UX design and how it fits in to SCRUM. The first is the misconception that UX Design is strictly interface design. Where I work, UX Design is defined as research, design and usability testing. Research is considered understanding the user. This research can take any number of approaches, user interviews, contextual inquiry, surveys, analyzing user behavior via website analytics. Design is defined as the process by which the user experience is being crafted. It includes not only user interface design, but also interaction design. Usability testing is defined by the testing of a design, this allows the organization to understand where improvements need to be with not only the interface, but how the user will interact with the system.

As a UX Designer, I have supported multiple SCRUM teams at one time. I have worked ahead of the team and validated the design approach. I've also stayed close to the teams as they are working stories. Handing off design to developers without being present to provide feedback and direction can be hazardous. Developers are generally not focused on the user aspect as much as they are focused on writing clean code, getting their stories done, and making sure integration from other systems works properly. I'm not saying developers don't care about user facing concerns, it seems though that this is not top of the list when it comes to sprinting. When the designer that researched and validated the design is excluded from team discussions, funky interactions start showing up in development.

While I was not officially a part of the team, I was certainly present at stand ups, refinement meetings (after all, those are called user stories), and team demos.

To say that a UX Designer is merely a stakeholder detracts from the value of having the voice of the user in the room- someone that has done the foot work to research, design and validate the desired design approach. It also means that the designer is not accountable for the design if it gets developed along a different path than what was researched and validated.

I often have problems with the term "stakeholder". Doesn't everyone involved ultimately have a stake in the ground on whether a digital product is successful or not? Labeling someone a stakeholder gives the impression that they will be detached from the development process and that at some point the development team will display what they have completed. Ideally the UX Designer is involved at a level with the team where they are painting the vision prior to development, and providing iterative feedback during development about the most optimal design approaches. I'm also unclear on what a "VIP Stakeholder" is. What would make that person VIP over other stakeholders?

In the above comments it was stated "Maybe it could be great to redefine how to make interface and development in same time during a sprint." UX Design is more than just interface. There are also risks in combining a Front End Developer and a UX Designer into one person. The activities of research, usability testing and product validation go on the back burner, because ultimately the "UX/UI Designer" is faced with getting story work done in a fixed amount of time. Unless UX stories are baked into the sprint, time is not allotted to focus on these things. Ultimately organizations want to see things in production. The quality and the solution may suffer without having an intentional approach to design and how the user will interact with the system.

I would argue that one of the main problems is that SCRUM has not effectively defined how UX Design should fit into the process of development, so it is left as an afterthought about how teams approach and execute design.

Before I make a decision such as this, I found it is helpful to ask myself these questions:

1. Would this role/ person add value to the product/process? 

2. Would this person bring innovative ideas (that are easy to understand and implement)? 

3. Can she/he translate the user needs into clear user stories? 

I personally think if someone who has a deep understanding of user experience, and someone who is a great team player and often generate innovative ideas, that person can be a great asset to the Agile team regardless of the official tittle. In the end, the frameworks and methodologies are there to guide us, and we have the flexibility, intuition and EQ to make decisions with the goals to create values to the business and customers. Including the right people often and early in the process  can make a huge difference to the outcome and vise versa. 

+1 David.

I totally understand what you mean, and I am happy to be a member of an organization that defines UX input is a very similar manner to what you described. In our set-up however UX is even an equal member of the Scrum Team, participating in all our activities, sometimes more actively, sometimes less. The one thing we struggle with is when they have to support more than 1 team at a time...

I worked with some companies where UX designer was a member of a Scrum team and other companies where he/she was an "external resource", it depends on your specific situation. If UX designer's work is part of the team's Definition of Done then he/she should be a member of the team (full time or part time). If the UX designer's work does not have to be "synchronized" with the team's work within sprints then he/she may be an "external resource".

+1 David.

totally agree on your perspectives. I also like the point which in summary says "UX Design" is not "UI Design" ;-) 

how often did I hear: dear UI person, please make it beautiful! there is definitly much more than just good looking UI to make products successful.





personally I made this experience:

• no spec/prototype is 100% clear, there are always some little details to clarify when implementing stuff -> it's easier when UI person is close to the team
• the closer the UI person is to the team, the less detailed specification is needed for implementation. (because of empathy & information flow within team)
• the provided user experience of a delivered product is a summary of what the team has created at the end. some UX skills within the team do help everyone drive it in a positive direction.
• if you are a UX guy, make sure to stay close to the team - always!

and a.f.a.i.k. "the (SCRUM) Dev Team has the responsibility to deliver the best possible product", so why not put anyone in that team who can help to be successful? 

and last but not least: please give the UX and UI guys a chance to welcome them in your teams, they sometimes talk a strange language and feeling poorly alone at beginning, but the sooner you start collaborating the sooner you will have effective M-shaped teams ;-)

There are different UXers, some have their background and focus on graphic design + UX, others have a more technical background and could as well handle system / information architecture challenges, and they could both do user tests (quantitative / qualitative).



If you're at the very start of a new project, you'll need both types of UXers, to come to an MVP.

During that 'startup phase', it's hard to follow a two-week sprint regime, with demos and an upscaled team of developers.

When the MVP design is finished, you come to a point where development can start and UX/UI needs to deliver the specification documents to build on. Small iterations can still be tested and adjusted (agile), but it's mainly working towards a working MVP.

When that's done, it's time to start iterating, with a more static team. Depending of the size of your development team, I would suggest 0.5fte UX, 0.5fte UI should be more then enough. For UX it's also good to have a broader image of the other services and products, outside of the Dev team. 



Just my 2 cents... 

Thank you all for your valuable comments. I know I'm a bit late here to continue this discussion ;)

There a few points here where I'm still not sure about them: 

1- If UX/UI is getting done outside and ahead of the Sprint then are we really doing Agile? it sounds kinda waterfall! And how are we estimating the whole project? How do you calculate the cost of the UX activities?

2- What's the point of getting the UX / UI done before the development? shouldn't be reviewed and approved by the user?

3- Nothing is wrong if UX be somehow part of stakeholders / PO activities if we can explain pint #1. what do you think?

4- If UX is part of the Sprint then should the developers wait for the UX person to get some parts done and then start the coding? Aren't we waiting the developers time here? (however this sounds a bit theoretical situation and developers could be busy with bug fixing in the real world situations)

Appreciate your feedback.  

Before responding to Aref, I'd like to point a couple of things out. Firstly, since the rest of the discussion had taken place, Scrum.org has launched its Professional Scrum with UX course and exam. I believe the existence of this course is already changing views on UX within Scrum.

Secondly, upon reading this thread, I was struck by how often people have talked about UX as a person or role who may or may not be in the team.

Instead, shouldn't we be considering the reasons why a team should or shouldn't be responsible for some or all aspects of UX design, before we get into which people should be on the team?

@Aref, in response to what you've said:

If UX/UI is getting done outside and ahead of the Sprint then are we really doing Agile? it sounds kinda waterfall! And how are we estimating the whole project? How do you calculate the cost of the UX activities?

It's hard for me to add much here, as I think we can generally do better by having Development Teams responsible for UX; but it is still possible to be agile, while having UX specialists separate from the Scrum Team. There are plenty of sensible ways they can collaborate, either at refinement or during development.

What's the point of getting the UX / UI done before the development? shouldn't be reviewed and approved by the user?

A large part of UX work is research and discovery. This can be a lot cheaper, and provide much faster feedback loops than producing a releasable increment; particularly as there are often a lot of assumptions which we will need to disprove. The "Truth Curve" by Giff Constable illustrates that it can be an unnecessary risk to move on to more expensive ways of getting feedback (e.g. releasing, scaling, etc) before you have gathered enough supporting evidence about your assumptions through much cheaper techniques (e.g. customer interviews, prototypes, AB tests, etc). Depending on the users of your product, you might not be able to get useful feedback until an entire feature is complete. That can be a very expensive way to find out you're wrong.

If UX is part of the Sprint then should the developers wait for the UX person to get some parts done and then start the coding? Aren't we waiting the developers time here? (however this sounds a bit theoretical situation and developers could be busy with bug fixing in the real world situations)

Perhaps. This could sometimes just be what we consider refinement.

But who says the UX person isn't someone who can also code? There can be specialists in a Development Team (including UX specialists), but that doesn't mean that significant parts of the UX can't be done by the whole team. If we take customer interviews for instance, it might be better to have coders there, developing an understanding of the problem, than have one specialist draw their own conclusions, and try to recommunicate that to the rest of the team later. Likewise, in terms of declaring assumptions (e.g. about the customer, the problem to be solved, and the best way of doing that), maybe it's smart for the people who are going to implement those solutions to be involved early.

Maybe teams can have a Sprint Goal that isn't just about delivering a specific feature, but instead about achieving an outcome.

Perhaps the Sprint Backlog will be an assortment of traditional items to be coded, along with various UX items, such as talking to users and customers, validating assumptions, even measuring the data from what has been coded and released early in the sprint.

It is possible in such a situation, that the team will choose to code based on whatever UX and refinement that has happened already, and adjust its plans based on its learnings throughout the sprint.

It is possible that the UX work is done by a specialist, by cross-functional team members, or some combination thereof.

It is possible that not everyone will be busy for the whole sprint. As long as the team achieves the best possible outcome, should it matter whether everyone is always busy?

Hey! If it is still interesting:) I sure that UX designer should be a part of the Scrum team. I've written an article about it https://medium.com/softserve-do/design-in-scrum-framework-d9abab28b05b - here I've added two examples (Dual Track and Spikes) of how to include the design process in Scrum Framework. 

@ Chris Belknap 

I Agree

In a much earlier day of thinking in terms of MVP, I seem to recall people doing experiments to validate a hypothesis that, in a lean sense, could lead to innovation and shift a product toward something more useful. I like the quote from The Lean Startup,

the goal of the MVP is to begin the process of learning, not end it.

I fear that many implementations of scrum are quietly sacrificing the goal of learning to the God of "get it in production."



In the Scrum Guide, it says...

An Increment is a concrete stepping stone toward the Product Goal. Each Increment is additive to all prior Increments and thoroughly verified, ensuring that all Increments work together. In order to provide value, the Increment must be usable.

I think the common interpretation of the idea of what "usable" means might be key here, and found in the following paragraph.

The sum of the Increments is presented at the Sprint Review thus supporting empiricism.

Supporting empiricism means "we did something usable in the real world, and we observed the outcome". In this sense, I can see the value of saying, "We don't want our increment to implement a database schema that nothing is connected to and so it's real-world impact cannot be empirically observed." I hope we all agree that would feel like waterfall (where stories are really just tasks dressed up as product backlog items.) Having said that, what about a digital MVP that can simulate an experience that can fully be realized and user interactions can lead to learning and be empirically observed?



I can see individuals on the team with UX skills, "refining" their understanding of persistent user audience personas, performing spikes that answer meaningful questions that quickly lead teams to well aligned approaches to PBIs. I can also see UX-oriented MVP experiments that test a hypothesis about how to effectively achieve some goal for the product. 



I am not sure about this, but I like the idea that UX design should not be "big upfront design" but become integrated into Scrum more and more and even now, while I appreciate the growing interest in providing a Lean UX-oriented certification via Scrum.org, I can only imagine Scrum gets better as it incorporates more lean design practices as a first class citizen to the framework. (As a programmer, it is desperately easy to see one's self in the framework in the full context of agility. As a designer of various kinds, it is far less easy to understand how to adapt long-experienced practiced into the agile team without feeling like a second-class player because you aren't writing code.)

Hello,

I am a UX designer and I don't think a UX Designer should be included within a Scrum team, but associated with. I think that UX Design is in it's own swim lane, and the Agile methodology to me is like the "admin work" part of designing. So that is how I treat it. I think that instead there should be access to the Agile process going on, and training to understand it, to get to know what is being built, and there should be touchpoints. I think if you have to work in the framework, it's good to associate flows to the user stories that build a flow, and to create wireframes and include those as well. I created this idea in DevOps. The flow may not need all the wireframes though, and so working with those who are creating the functionality is important, like developers.



But, I really do think that designers should be a little ahead in Sprints because you can't gain insights and innovative ideas on a dime! I am not saying you can't keep within a decent deadline (Sprint) but, when faced with the build, we find that some things require UX requirements, and those should be part of the requirements and criteria, and other times we don't need to add anything, and other times, we might streamline something to function better. When we are designing, we are testing it with users, so we are doing our own iteration loops before showing you the wireframes. So, it's not waterfall at all! It may seem like that to you, because we hand it off to you, but it's not waterfall. It's just that you are not equally dragged into the product design workflow, because that's not your discipline. It's almost like dragging a brain surgeon into the x-ray room and making them perform x-rays, that's not their discipline, but they do need people to do x-rays and they aren't going to micromanage those people by dragging them into the surgery room to perform the x-rays either, and have them sign off on documents after each step, in tandem with the brain surgeon doing her job. You have different spaces and workflows. But you certainly can have meetings together for discussion.



It's a funny thing to work through, but if collaborating with product owners, we put our heads together, we can come out with requirements together (UX requirements + Business Requirements) and then usually it's the designer that solves it, but it can also be done in a multidisciplinary fashion too. The thing about that though is, if there is just one designer, and many coders and technical people, the UX designers voice for the user might get stream-rolled. Everyone will have an opinion, but the only one that counts is the user, and the business has to accommodate that if they want the benefit of UX design.



One thing a UX designer is NOT is a professional pencil, or "pixel pusher" who just draws the ideas of the business analysts. If that happens, it's not only giving the User Experience designer themself a really painful experience, ironically! It limits the designer to design only according to accessibility standards and their own flare, and that's ignoring users, which we don't want to do! Our whole point and purpose is to empathize and stand up for the users! So it's kind of devaluing.



So anyway, we are connected to the Agile/Scrum team, but we are not in the same discipline, so we do things different, following our own methodology, but the iterations are there, and once we bring it to you, you can further enhance it. We can talk back and forth, and that's ok, but please, don't get us overly involved in the scrums, be selective about it because it really is a distraction more than anything, to get our job done. So let us treat it like "admin work". But not our whole culture like it is to you.

I have to disagree. The UX designer helps to develop the product, and so is a Developer.



Have a look at the PSU learning path. I especially like "Dual Track Development is not Duel Track" article, when talking about the place of UX designers in a Scrum Team. You don't only work ahead of the other developers, you can work alongside and later.



What you do if you are not in the Scrum Team and "working ahead" is introducing a waterfall system.

The UX designer helps to develop the product, and so is a Developer.

I like that approach best and aligns with the spirt of a cross-functional team, as there is also an opportunity to cross train other Developers, share knowledge, collaborate, pair up.

What you do if you are not in the Scrum Team and "working ahead" is introducing a waterfall system.

For some work that is true. Sometimes there is UX work that takes longer than a Sprint. That work can be made transparent on the Product Backlog, and could also be thought of as refinement.

LeanUX is also a great resource.