13

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.

Improve this question
5
  • 3
    Why would UX design not provide value to the user? Assuming you keep to scrum and continue to use UX designers, I can't see that there is an alternative, and if you don't have an alternative, how can there be disadvantages?
    – Michael Shaw
    Mar 15, 2014 at 15:35
  • Because a screen mockup and a list of UI requirements don't provide direct value to the user. These provide value only after implemented in the story of the next Sprint.
    – Eugene
    Mar 15, 2014 at 15:37
  • Your problem might be that you don't have designers or ideally UX engineers, you have graphic artists. They just use photoshop, right? No CSS JS or XAML or Interface Builder or any front-end technical chops? So you don't have designers. You need real designers. Then you won't have this confusion.
    – RibaldEddie
    Mar 15, 2014 at 16:40
  • No. We have both user interaction designers and graphic designers. Both work one sprint ahead of development
    – Eugene
    Mar 15, 2014 at 16:49
  • 10
    How does interacting with your client base using mockups and prototypes not bring value to the user? Value is not defined as shipping code. Tangibility is very good to have but is not essential for value.
    – BobDalgleish
    Mar 15, 2014 at 17:24

8 Answers 8

Reset to default
15

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.

Improve this answer
7
  • 2
    "Working software is the primary measure of progress.", not UX. UX is worth nothing if it's not working software. You would have a point if you advocated having UX at the same time or later w/r/t the actual feature, but you don't so, so this answer is flatly wrong.
    – Sklivvz
    Mar 16, 2014 at 11:19
  • 3
    @Sklivvz: I guess we have to agree to disagree. While it's true that working software is the primary measure of progress, it's not the only measure. Some amount of design must be done up front before a team can start coding. UX isn't something you can just tack on at the end.
    – Bryan Oakley
    Mar 16, 2014 at 12:21
  • 4
    @BryanOakley I agree that some thought needs to be given to all work up-front, not just ux. However, the value of that work is decided by the stakeholders. If ux work is done one sprint ahead, the feedback loop has just been extended by at least one sprint. I would suggest that this is an unnecessary risk. UX is no different from design, or architecture, or database design, or report format. It CAN all be done in one sprint, with product backlog items that are created as vertical slices of functionality.
    – Derek Davidson PST CST
    Mar 16, 2014 at 14:02
  • It can be done in one Sprint, but without knowing what the user experience will be how can you plan the rest of the work? If you don't know the detailed software design you can still plan the work. But if you don't even know what the screen and functionality will be like, how can you plan anything?
    – Eugene
    Mar 16, 2014 at 18:45
  • 1
    By working incrementally, as is the usual agile way. The developers produce a prototype either in real-time collaboration with a ux designer or based on their own ideas about ux; once a prototype is working a designer reviews it and provides a list of changes. A story doesn't need detailed planning; all it needs is an estimate of size (and some dispute even that).
    – Jules
    Oct 3, 2015 at 18:49
14

The main disadvantages are these:

  1. 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.

  2. 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.

  3. 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)

  4. Excluding or disempowering your developers is not a sustainable way to run a project.

  5. 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.

  6. 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?

Improve this answer
5
  • The comments were largely off topic so have been removed.
    – ChrisF ♦
    Mar 17, 2014 at 10:13
  • 1
    You say "Your UX designers are making decisions... without involving the developers". How do you know? Just because they are working one sprint ahead doesn't imply they aren't working with the developers. Perhaps the developers are their stakeholder. This also goes to point 4 -- you're assuming developers are being excluded but that isn't necessarily the case. As for "Designers are not delivering value", I couldn't disagree more. You see no value in properly designed UX? While I think you raise some discussion-worthy points, you're making a lot of assumptions that might not be true.
    – Bryan Oakley
    Mar 20, 2014 at 19:03
  • @bry either they work on ux or they don't. Surely being involved in the ux process qualifies as "working" on a story. Regarding your assessment of value... They do not add value if they work in advance because they don't produce anything that can be deployed. If something never reaches the customer it has no value to them.
    – Sklivvz
    Mar 20, 2014 at 19:11
  • re: "being involved in the ux process qualifies as "working" on a story." Not necessarily. People come and ask me questions all the time, that doesn't mean I'm working on their stories.
    – Bryan Oakley
    Mar 20, 2014 at 19:15
  • 2
    @BryanOakley surely, but the problems still apply: compare "sending back" a design because it's unrealistic to execute vs. getting it right the first time because it's done while a developer is working on it. Furthermore, there are issues that are only discovered during implementation, and at that stage the designer is doing the next story...
    – Sklivvz
    Mar 21, 2014 at 11:26
6

I like it, for two reasons:

  1. it seems to work for you; it's hard to argue with success!
  2. the UX team takes the story and starts the conversation early - and conversations are kind of the point of stories
Improve this answer
4

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.

Improve this answer
3
  • As I said in my original post: "The UX designers and the devs/testers are on one team"
    – Eugene
    Mar 16, 2014 at 10:47
  • 2
    @Eugene In what sense are they on the same team? I would say that if they're working one sprint ahead, they're not on the same team. Incidentally, Scrum is also clear that it does not recognize "sub-teams" so again, I'd say that your situation doesn't sound like Scrum. Certainly not as I know it.
    – Derek Davidson PST CST
    Mar 16, 2014 at 13:49
  • They work one sprint ahead with the rest of the time. The rest of the team usually at least reviews their work and sometimes helps with the design itself.
    – Eugene
    Mar 16, 2014 at 18:36
4

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.

Improve this answer
2

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.

Improve this answer
1

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.

Improve this answer
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.

Improve this answer

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service and acknowledge that you have read and understand our privacy policy and code of conduct.

Not the answer you're looking for? Browse other questions tagged or ask your own question.