UX designers and Scum ceremonies

Scrum Guide: Development Teams are cross-functional, with all the skills as a team necessary to create a product Increment;

Option 4: Why wouldn't the UX Designers be treated differently and why not become members of a cross-functional Development Team, just like people who are skilled in testing are? And how might their knowledge help others on the Development Team learn to pick up some of these UX skills when the UX Designer is not available during a portion of the Sprint, while limiting handoffs?

One thing that strikes me about the article and what you've said is it seems focused on taking UX people and inserting them into an existing team with an existing way of working. I would not do it that way.

Yes, the UX team can probably learn a lot from a team that is already using Scrum, but the Scrum Team also need to learn from the UX team about what works for them.

If people join or leave a team, it's essentially a new team, with new dynamics, skill sets, expectations, needs, and (in this case) responsibilities.

So I'd forget the existing processes, and build one that would work for this new team.

Re: what you call Scrum ceremonies, I suggest you refer to them as Events. That's the language that's used by the Scrum Guide, but my main reason for suggesting this change is that ceremonies just seem like something you observe without necessarily needing to understand why.

Events are moments to inspect and adapt. You can forget the existing ways of running those events if they're no longer helpful, and can consider whether those existing discussions still need to be done in the same way, and whether they should involve the entire team or not. Perhaps some technical decisions can be deferred to a dedicated meeting involving the right people. Actually, the impact of these discussions is so important, I'm going to add a little note about it at the end of this post*.

Making a Scrum Team that is responsible for UX is very different to one that isn't. There will inevitably be more of a focus on outcomes, as this brings development closer to the user and customer. It brings opportunities, but also brings complexity within the team (as opposed to having complexity that is either addressed or avoided during a handoff between two teams).

There's a lot to cover about a Scrum Team that's responsible for UX, and I'd recommend the PSU course by Scrum.org, as that is 2 days dedicated to exploring this topic.

I'm just going to explain a vision of how I see a Scrum Team that is responsible for UX. It's not something I've been fully able to explore, just because of the role of the UX specialists in the companies I've worked for, and the configuration of the teams. But I've helped teams put elements of it into practice.

Vision

A Scrum Team containing a mix of engineering and UX specialists, of which some might be cross-skilled, but all are willing to be at least somewhat flexible in the work they do in order to help the team achieve its goals. Perhaps there are other specialists, such as testers, but the same principles of cross-skilling and everyone being willing to contribute towards a common goal apply.

The Product Owner has been actively maintaining the Product Backlog, and the entire Scrum Team have had refinements to understand priorities, the reasons behind those priorities, and have general alignment on what the right goal could be for the Sprint, as well as longer term objectives for the product.

Sprint Planning

The entire Scrum Team attend, and they discuss what they hope to achieve. They agree on a Sprint Goal that is not focused on what they will do, but instead on what measurable outcome they will achieve.

For example: Instead of Replace the old landing page with the new design, perhaps have Increase the percentage of users who will sign up after visiting our landing page from 5% to 15%.

The team will produce a Sprint Backlog for what is already known. This could be a combination of user stories, A-B tests, prototypes, user interviews, etc.

Team members will raise considerations that they feel are relevant to the entire team. If a follow-up is needed with certain individuals, they will find the appropriate moment to do so. So if there's a heavily technical conversation that's needed, engineers could tell the whole team what they're concerned about and whether it has the potential to affect the Sprint Goal or plan for achieving it, but they would perhaps choose to have a separate conversation later, involving just some or all engineers.

Daily Scrum

With a clear and shared Sprint Goal, the entire Development Team (i.e. including UX specialists) inspect and adapt the team's progress. An engineer might explain when they can release what they're working on, or what help is needed to do so. A UX specialist might share the results of a user interview that validate or invalidate previous assumptions. Anyone might ask for help, or share opportunities for teammates to benefit from what they're doing. For example, an engineer might ask to join a user interview, or could propose building something that will help during an interview.

There will be a lot of collaboration, and the team are disciplined to ensure they keep it within 15 minutes, but there are plenty of follow-up discussions, as team members see opportunities to help each other.

Refinement

Sometimes the entire team will sit together in a meeting to refine the Product Backlog. This could be a simple discussion, or a more structured workshop to build alignment, and to share in the entire process of understanding the perceived problem, who the team are solving it for, what success would look like, and what risks and opportunities they see to learn along the way.

Refinement could involve customer or user interviews. Perhaps engineers will join UX specialists in this part.

Perhaps there are aspects that involve just one or a few team members.

There are no fixed rules on how they do this, but the team are respectful enough to include each other at the right time, and to choose the techniques they believe will be most effective. They keep learning what works best, and continuously improve.

Sprint Review

The Scrum Team will share what has been done, and what was learned. There should be an abundance of data (perhaps largely qualitative) that will be relevant to the decisions already made, and perhaps the ones that will be made next. Feedback will be centred around something already exposed to end users, so it should be possible to make certain objective assertions.

The Sprint Goal was outcome focused (Increase the percentage of users who will sign up after visiting our landing page from 5% to 15%), and beyond the binary announcement of whether it was achieved or not, the Scrum Team should be able to share whether the percentage increased and by how much. It was probably higher or lower than 15%, and the team will probably still have ongoing experiments to measure the longer term impact.

Everyone should be in a position to determine whether it makes sense to invest the next sprint in continuing this initiative, or to move on either temporarily or permanently.

Sprint Retrospective

Essentially this has the same objectives as the existing Sprint Retrospective. The difference is that there will be a lot more collaboration, and empathy for each other's struggles. Because there are various specialisms, it might be that the team feel it's more effective to focus on multiple improvements. Or if the team can already predict that the proportion of work in the next sprint would be higher or lower for a particular type of specialist, this might affect the type of improvement they choose to implement.

* It's common for specialists to question whether they should be involved in discussions that don't relate to their area of expertise. Whenever people make decisions to excuse themselves (or others) from a conversation, they should consider the alignment benefits.

Even if that person won't speak during the discussion, it can take a lot longer to bring them up to speed on the full context of what they missed, than it would be to have that person in the room, observing the decision making process.

Effective communication relies on respectful behaviour and a focus on what is being achieved by being in a conversation, rather than whether it is of immediate interest.

UI UX designers are an important part of the Product team. They should be treated as Development Team members and should participate in all Scrum events. If the Scrum Team is too big, can you split them into two? My preference is for no more than four development team members per Scrum Team. 

I really enjoyed this post Simon. Today I started down what I think is the learning path for PSU1 by opening the Lean UX book. So far it's been a quite enjoyable read.

So shall we:

1. Include all the UX designers in all the Scrum ceremonies no matter what?
2. Include only representatives of the UX team in all the ceremonies?
3. Include the UX team only if we "feel" they should be there?

What other options do we have and what could prove most efficient?

Let's put your ceremonial observances to one side, and focus on value generation.

Are UX skills needed to create a "Done" increment of release quality each and every Sprint?

• If yes, how is the present Development Team able to meet the Definition of Done without them?
• If no, why consider UX skills at all?