11

Our scrum team consists of the usual scrum roles. We do not have a UI/UX designer and the developers work the UI/UX with the product owner. Here lies a problem. Everytime we are about to create the backlog and we do not define the exact UI/UX design before the beginning of the sprint we end up spending too much time during the sprint trying to finalize the UI/UX design.

This is exactly true for the analysis and architecture of the features. Do you think that every possible detail about a feature should be given to the developers before the start of the sprint or should it be a task within the features? We have experienced with this and it results in some undefined features that do not have any criteria.

Improve this question
1
  • 1
    If the exact UI/UX design was not specified in the story then the product owner shouldn't be rejecting what the developers come up with. It sounds like you are spending time because the scope is changing - you are defining the UI/UX after sprint planning, when the story was estimated. If a story is about implementing a UI then the story should probably have at least a wireframe or even a sketch of how it should look. Creating this wireframe or sketch is probably a story in itself that must happen before the implementation story. Commented Oct 5, 2016 at 11:56

9 Answers 9

Reset to default
4

First: have a look at this nice talk, Florian Haas gave at the FROSCON (GER). It is about the practical impossibility of doing scrum at all.

The good news: Since scrum is impossible to implement, you are free to do whatever you want.

The bad news: Don't call that scrum.

That frees you up from the question: »Am I doing scrum right?« (Answer: No you don't) and you could go on to the practical questions of life, that matter.

We do not have a UI/UX designer and the developers work the UI/UX with the product owner

This is a not uncommon situation. But AFAIR scrum is against specialization: everybody should have the same skillset and could work interchangeably.

Everytime we are about to create the backlog and we do not define the exact UI/UX design before the beginning of the spring we end up spending too much time during the sprint trying to finalize the UI/UX design.

Yes, I now that situation all too good. I worked in a team, where we had to deal with very broad backlogitems like »As a user, I want to see information x« and that was it. Then the item landed on the sprint board. One dev took it. Solved it. After implementing it, a first peer review took place, where discussion started about how the UI should look like.

Then the QA-Phase came and discussion started all over again.

After the sprint, we did as scrum demands the review where the design was ripped apart by the PO. Unfortunately our customer didn't make it to the reviews, so he did not see the software at that point.

But then the cycle began all over again until PO was satisfied.

And then came the customer...

From this war story you see, that this (special kind) of process is hellishly ineffective.

What worked for us in the end was throwing scrum over board.

But that's not the solution to your question ;)

Do you think that every possible detail about a feature should be given to the developers before the start of the sprint or should it be a task within the features?

A solution to this dilemma would involve tight feedbackloops between a) the customer itself and the PO, so that the criteria are relatively tight formulated. b) A tight feedbackloop between scrum-team and PO to minimize the chance to drive off the road.

I would break some (more) scrum rules to define one backlogitem: a »working dummy«. Which could be fast reviewed by PO and customer to minimize developertime spent on a simple item.

tl;dr

What should be the input of a scrum team?

Enough information to meet the specs in as little time as possible.

Offtopic:

We don't do scrum anymore. We do not do estimations. We kept the sprint board. We don't do sprints. We develop features / fix bugs and release ASAP. When new features are implemented, they go ASAP to a public server where we could discuss further design with customers as tight as possible.

Improve this answer
2
  • Mr. Haas is quite ignorant about the Scrum framework. It is this type of misunderstanding that is reflected in so many organizations. Commented Oct 19, 2016 at 17:57
  • That story is told over and over again: "if only you were doing scrum right". I never saw a company where scrum worked out. So I have a strong bias against scrum - which even grew after experiencing scrum firsthand in our company. And here the same story: it didn't work (for us). Commented Oct 19, 2016 at 20:37
7

The canonical answer is "do what works for you."

Scrum is one of the agile methodologies. It is explicitly designed to change and adapt to your team and your project. Your focus should be:

Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan (Agile manifesto)

It's not a question of what your team should have to start on a story, It's a question of what input allows your particular team to solve the particular business need.

In my personal experience, it depends on the business goal. Some stories already come with UI/UX research and full designs, and that's OK. Some stories come with vague requirements, because the business just needs a problem solved. That's also OK.

There are other factors too, of course. Like whether your designers are part of the dev team, or marketing, or product development, etc. Penty of factors. Just do what's needed to satisfy the business, be flexible, and make sure you discuss these things during your retrospectives, adjusting process as necessary.

Improve this answer
4

I've had similar push back from developers. The issue from their point of view was that they were wary of how long the UX part might take to implement. If they agree to try and deliver N stories in a sprint but some of the stories take significantly longer than expected due to going back and forth on the UX then they felt it reflected badly on them.

What has worked for us is:

  1. Someone works with the product owner to create mock ups of the screens to be developed. These get reviewed during the usual story refinement process before the story gets pulled into a sprint which gives everyone a chance to have an honest discussion.
  2. Don't try and finalise the design before coding, just get it out there and then have a conversation about what needs changing. The costs of making the change are then clearer which helps the product owner/customer decide if it is worth while.
  3. Trust between the product owner/customers and the developers. In the end everyone is trying to deliver stuff to the customer. The PO isn't allowed to moan about the team not delivery everything from a sprint. The devs can't be deliberately obstructive because they are worried about not delivering.
  4. Practise. We've just got better an estimates story sizes and being able to spot likely problems.

Tl;DR: Don't fully define the UX before coding. Wait until the users see it and play with it.

Improve this answer
4

Do you think that every possible detail about a feature should be given to the developers before the start of the sprint or should it be a task within the features?

Simply put, if the product owner is not able to deliver the ui/ux design before the sprint, the development of the ui/ux should be a story, not a task.

Your sprint deliverables don't always have to be working code, and the team itself can be the "who" in the story. You can have a story such as "As a member of the development team, we need UI mockups in order to be able to implement the UI". You then estimate how long it will take your team to deliver the mockups, and that becomes one of the first stories you work on.

Improve this answer
3

You do not have to spell out the UI, just accept the functional request (story) and score it knowing you have to think about a UI. Having the client specify the UI is asking for trouble.

Now that you know the UI will cost you some time you should be able to plan better, Next time you take on a task that includes UI work you will assign some extra story points to it.

Improve this answer
3

If you're scrum anyone can be a UI/UX designer.

The UI/UX shouldn't be an afterthought. It should be a deliverable. It should be approved by your product owner. It should show up, even if only as a gif, when delivering.

That doesn't mean it can't change. It's something that will change often. It's also something you want feedback on early. Don't let the code drive the UI design. Let the customer drive it. Push back only when the customer is asking for magic. Otherwise just make them aware of the amount of work they're asking for and how much it's going to cost.

The only finalized UI/UX is on dead software.

From your comment:

"It should be approved by your product owner." This is exactly where the problem arises. There is a huge amount of time spent on this approval process and we end up spending days instead of few hours that was initially estimated. - Rashid

Eliminate everything that needlessly slows you down.

You have an idea. Tell the product owner. They should be sitting next to you.

They hate it? Move on. Love it? Do it. Don't understand it? Show them.

Short frequent unscheduled meetings. Talk. Doodle on a whiteboard or paper. Mock up in a paint program using screen shots. Communicate, approve, implement, and review ideas quickly.

If the product owner isn't around grab a convenient human and ask them. Whatever it takes to start iterating. Loop the product owner back in as soon as you can.

Don't spend one second making it pretty. Just get to the point. Keep your ideas small and incremental and you can be done before anyone even asks for an estimate.

Improve this answer
3
  • "It should be approved by your product owner." This is exactly where the problem arises. There is a huge amount of time spent on this approval process and we end up spending days instead of few hours that was initially estimated. Commented Oct 3, 2016 at 13:07
  • @Rashid note update Commented Oct 3, 2016 at 13:51
  • @Rashid If you're estimating time instead of complexity, you're doing it wrong! Commented Oct 3, 2016 at 17:24
2

In my experience:

  • Too little up-front analysis causes inefficient, stop-start development
  • Too much up-front analysis causes analysis paralysis (the Sprint never gets started)

What we do:

  • Define some "Ready for Development" criteria
  • For UX stories, this might be "we have a wireframe that is well understood by the team"

During Sprint planning:

  • Any Stories that aren't Ready for Development are thrown out (they would be too disruptive to the team and go back for more analysis)
  • Any borderline Stories are declared "High Risk" and undertaken right at the beginning of the Sprint
  • Well understood Stories are estimated and permitted into the Sprint

This system allows us to dedicate most of every Sprint to execution i.e. we work much more efficiently.

Improve this answer
2

Any task in your scrum must have an estimate for the total work involved, and a verifiable outcome.

If I put a task into your scrum "implement feature X with a user interface that the product manager is happy with", that has a verifiable outcome, but it's clearly impossible to estimate the amount of work involved. So this task cannot be reasonably put into a scrum.

Now I put a task into your scrum "design a user interface for feature X". That can be estimated, and the outcome is verifiable. That's an Ok task within a scrum. When the task is done, you've done it.

Now once the task is done, your product manager can say that he doesn't like the result. That's Ok. There was a task in the scrum, you've done it, and that's your job done. He can put another task into the next scrum. Maybe with a bit more direction what kind of user interface he would actually like. That's his job. Setting tasks that give useful results. Sometimes it's hard, and work is done that turns out to be useless. That's why they call it "agile"; tasks are done that turn out to be useless, and then you change to a better direction.

In addition, UX design, especially good UX design, is a full time job for someone who has practiced UX design. Many good software developers can do a passable job creating a UX, but they won't do it as good and as cost effective as a good UX designer (if they could, then they would create UX designs and not develop software). So not having a UX designer is ineffective - again a problem for the product owner.

Improve this answer
1

I'm not sure you're following agile principles, but here is how this should be handled.

we do not define the exact UI/UX design before the beginning of the sprint

The goal isn't to be perfect at this point. Get as much input for the requirements so the developers can build something that matches what has been asked as close as possible. Don't make a bunch of tweaks or try to design things that haven't been asked for. You will be wasting your time.

we end up spending too much time during the sprint trying to finalize the UI/UX design.

Work on a way to determine when things are done. I have a feeling, someone is continuing to do a lot of back and forth evaluation of the UI/UX. Too many people have opinions about UX/UI with nothing from the client to support their assumptions. 

Manager: "I think this should be bold." Programmer: "The client didn't ask for this" Manager: "But I think they'll like it."

This kind of thing can go on forever. It's not a Scrum flaw. Someone is meddling with the requirements during the sprint. Get back to deciding what the client wants, determine how long it will take and work with them to prioritize. If they think it will take too long, ask them what to get rid of.

There is a company that designs logos for a flat fee. They limit the number of alteration requests because they know some clients will kill them by death from a thousand cuts with all of their changes. Put a stop to it or charge more. It's called business.

Improve this answer

Start asking to get answers

Find the answer to your question by asking.

Ask question

Explore related questions

See similar questions with these tags.