I manage a team who develop a Web-based CRM. We are trying to introduce a UX Designer to this project, but I don't know the best approach to do that. I have two proposals, and I'm leaning more towards the 2nd one.

  1. In the first approach we have two product backlogs; the UX team will build all the mockups, studies and docs and deliver to the Dev Backlog. Only stories already mocked-up would be 'developable'. Then the product owner would prioritize the 1st and the 2nd backlogs. Not always the first task delivered by the 1st team would be developed first by the 2nd team.

  2. We had only one backlog and the UX designer would be part of team, I think this approach it's more 'lean' and brings the UX to the vision of the sprint, he becomes more engaged to the goal. But... would create a little waterfall by sprint, where the developers would need to wait him decides the best visual approach would be used to the new feature.


What strategy do you think it's better? Do you have another proposal?

  • 1
    There is no right answer to this. Agile comes in many flavors and how to best integrate UX into it is highly dependent on all sorts of specifics only applicable to your particular scenario. The one advice I'd give is to focus less on mockups, more on 'sketches' and have the UX person be integral to the overall development process. I will say it is a good idea to focus on two goals, though...the immediate details of an iteration as well as long-term big-picture thinking. Often one or the other is lost in the mix.
    – DA01
    Oct 9, 2013 at 0:13
  • 1
    this might be interesting for you: scrumalliance.org/community/articles/2011/march/…
    – Lovis
    Oct 9, 2013 at 8:13

2 Answers 2


I've been involved with both approaches, and the Approach 1 has resulted in better final products with significantly less rework, but with two caveats:

  1. You have to provide comfortable lead-time for UI/UX designers, analysts, and users/product owners to do their part of the work.

  2. Mock-ups should resemble the finished product as much as possible, and there should be at least 60% of it completed before Sprint begins. (though there should be regular team reviews leading up to that point)

The benefits:

  1. It gives designers more time to do analysis, and thus not have to do piece-meal design.
  2. Finished looking mockups mean there's no room for misinterpretation by owners who need to sign off, and developers who need to code.
  3. With larger inventory of finished mockups, development will have much better idea on how to divvy up sprints.
  4. It also reduces time it takes for QA to come up with test plans.
  5. Significantly less written requirements needed by BA.
  6. Clearer division of labor by skill.

One may argue that this isn't true Scrum. Well, when Scrum was developed, there was no UX. There were no off-shore developers. And the software components were less complex. These days, there are significantly more variables. By using Approach 1, you're keeping Scrum process simpler, and purer. And that's a good thing, because Scrum is already complex as is.

True agile method in the Approach 2 will doesn't work well unless you have highly motivated, highly integrated, highly skilled, small team of workers. Most of us don't work in that environment.

  • I completely agree with the last statement. We are using Approach 2, but only because: a) Our team is small and we work very close to each other; and b) Some of our UX is done directly in the code.
    – Yisela
    Oct 9, 2013 at 3:53
  • 1
    While I agree with the last statement, I disagree that you're doing Agile if you don't have that. If you don't have a skilled, integrated small team, you're likely doing some quasi-waterfall method just under a different name. So...my point...if you have a true small, skilled agile team, you want UX to be right in the mix as well and, as such, I'd argue the UX person should be doing a lot more 'sketching' and ideating rather than creating mockups that 'resemble the finished product as much as possible'. All that said, though, again, it's always going to depend on the specifics of the team.
    – DA01
    Oct 9, 2013 at 4:15
  • (I should add that I'm not necessarily a fan of formal Agile methodologies, either, so if there HAS to be a formal process involved, my 'stay loose' advice might not work that well)
    – DA01
    Oct 9, 2013 at 4:16
  • yes I agree, it depends on the situation. My view would reflect a typical in-house corporate IT / design departments with sizable headcounts, which isn't always conducive for a truly agile method with UX. However, you can still do software development that fits the traditional definition of Scrum.
    – Jung Lee
    Oct 9, 2013 at 5:05
  • Yes. It really depends on the team. In fact, we have a lot of projects (a kinda 10) and I don`t know if we would mix tasks for all projects to 2 UXs, or involve each UX in the team for each project. Oct 9, 2013 at 6:23

At enthuse.me, where I am head of product and UX, we ensure all 'UX work' (meaning mockups, photoshop designs, user stories and feature requirements, checking feasibility of requirements with the development team) is done before the start of a sprint, so that in the sprint we just have work that is already defined and ready for developers to code up.

If done correctly that means a UX designer and even the front-end developers should ideally never work on anything that is 'for the current sprint'. They're always working at least one sprint ahead, and ideally 2 or 3 to build up a buffer in case anything goes wrong.

Our sprints are usually just one week, so we're never working on things that are os far ahead in the roadmap that they might change entirely, which is something you need to be careful of if the team gets 'too' efficient, as you're moving away from agile and closer in to long-term waterfall there.

Well done to your team for even bothering to put a UX person on the case before development begins!

Your Answer

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

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