UX designers working one Sprint ahead

Our UX designers usually have a story in Sprint X that the developers will implement in Sprint X+1 (The UX designers and the devs/testers are on one team). I think this makes sense because if you don’t have screen mockups and clear specifications you can’t really estimate the work during Sprint Planning.

However in Scrum you are only supposed to have user stories that provide value to the user. In our case the UX design stories don’t provide such value (they are more like a backlog grooming activity). Also usually Scrum coaches don’t recommend having complete specifications before the start of the Sprint, a recommendation which I find hard to understand.

So do you see any disadvantages in our approach? It seems to work for us, but it goes somewhat against Scrum principles.

However in Scrum you are only supposed to have user stories that
provide value to the user.

Value isn’t measured only in lines of shippable code.

You seem to be implying that having a well designed UI doesn’t provide any value. Of course it does. Obviously there’s value to the end user, but there is also value to your development team, which is a perfectly valid stakeholder. If you don’t have the tools and materials to do your job, you can’t deliver value to the end user.

Don’t get hung up on scrum dogma. Scrum is there to make you more efficient. If doing a UX story one sprint before you implement the UI helps you deliver better software, do it.

The main disadvantages are these:

You are pipe-lining: if your designers are late, your developers are left without work; if your developers are late, your designer will eventually work more than one iteration in advance. It’s not a stable situation – it is not sustainable.
Your designers are working in advance, you are paying costs for stories that may or may not be developed. Even if it happens rarely, you are still throwing away money.
Your UX designers are making decisions in advance without involving the developers. You are missing useful insights and increasing the risk that the designs are flatly wrong or unrealistic. This is quite common because UX design is not an “abstract” exercise – it must be crafted out of the characteristics of the application (including what is feasible/advisable to do or not technically)
Excluding or disempowering your developers is not a sustainable way to run a project.
Designers are not delivering value: this means that it’s hard, if not impossible, to prioritize their work correctly. Usually, developer work is prioritized using different concerns, value, feasibility in the next sprint, amount of effort. A lot of time stories are negotiated and changed in order to make them “fit” or because of useful discussion: if any of this changes the UI (and you can assume it does if it’s not a mere implementation detail), what do you do with the story? You can’t play it anymore.
You are assuming that a story that can fit in one iteration for the designers fits in one iteration for the developers: how can you split the stories so this assumption is correct?

I like it, for two reasons:

it seems to work for you; it’s hard to argue with success!
the UX team takes the story and starts the conversation early – and
conversations are kind of the point of stories

A basic requirement of Scrum is that the scrum team has all the skills needed to create a potentially releasable product. In the situation you describe, this is not happening.

The UX team is not producing potentially releasable product and the scrum team are not capable of producing vertical slices of functionality as they do not have all the required skills. These are dysfunctions.

Sklivvz has written an excellent post on the problems that the above dysfunctions could lead to. In summary, I don’t think you are practicing Scrum.

But there’s absolutely nothing wrong with that. If you have discovered a way of working that delivers value for you all, and you’re all happy with it, keep doing it. My only advice would be to inspect and adapt frequently.

Note, however, that if your aim is to deliver software using Scrum, you’ll need to address the dysfunctions identified.

There are two issues here, one about user centered design and the other about sprint alignment.

First: User stories should be aligned with user needs, not just backlog. The UX stories need to have clear value to users. This does not require complete specification, and a short statement such as,

“Users will have easier access to account activity on a single page rather than divided between multiple pages”

is amenable and adaptable to various implementations and yet still clear about the value to the user (easier access to account activity).

Second: Sprint alignment. UX designs features in sprint X that developers implement in spring X+1. In practice, this happens in many shops and sometimes it may be more like implementation in sprint X+2 or X+3. With a tight nit and experienced team this setup can work. It becomes challenging if you have a new team or new members who are not familiar with the skill sets, preferences, habits, work styles, and tendencies of other members of the team. If you’ve been working together for less than 6 months this is likely to be an issue.

Take a step back, and reassess. On the positive side you have the UX designers and developers working side by side, which is a boon. Start by making sure that your stories have clear value to users.

One of the possible problems I see is that in Scrum the scope for sprint N+1 is normally determined right before it starts. So how can you do UX for sprint N+1 stories in sprint N for before you know which stories will be in scope. If you decide to fix the scope for sprint N+1 at the start of sprint N you lose some flexibility.

However in Scrum you are only supposed to have user stories that
provide value to the user. In our case the UX design stories don’t
provide such value (they are more like a backlog grooming activity).

The way I see it, they are providing lots of value to their user. The thing is: their user is not the company’s final user, their user is the development team that will implement the feature at sprint X+1.

You’re getting stuck in the religion of the process and along the way I see scrum/agile getting misused and users mislabeled. Scrum is not a universal tool, it is a means to an end.

I think that your group has mislabeled who your users are and are planning for the wrong audience.

The UX group is using scrum in the classical way, user value and agile adaptation to inputs from some magical end users. They are the one with users. Your group is misusing scrum because you’re merely filling in mechanics to make an existing design work, there is nothing agile required and scrum is filling the role of management tracking.

That is why this feels wrong to you, you don’t actually need or benefit from scrum in any way because you are in a service group and your work flows forward from the UX people who have already done the agile/scrum parts.

Nothing really bad there, just a different process is in place than what you were told.

Filed under: softwareengineering - @ 09:16

Thẻ: scrum, user-experience

Thiết kế website giá rẻ

Danh mục

UX designers working one Sprint ahead