9

Apologies if the question has already been asked, I couldn't really find the answer when looking around.

I'm struggling to figure out a way to handle UX/UI in an agile way. I'd like to be "fully" agile and having design being part of the sprint for the user stories where it is needed but everytime I tried to do this it causes either of these two problems (sometimes both):

  1. The devs need at least some wireframes/sketches to understand the requirements and be able to estimate accurately
  2. It takes so long for the designer to deliver the designs for the story that the devs don't have time to implement the story in the sprint anymore. Sometimes, the designs might even be longer than our 2-weeks sprint iterations.

I've thought about getting at the very least the wireframes before the story can be put in the sprint backlog, sort of like a Definition of Ready, but I feel like this is more a waterfall than an agile approach. Even more so if designs need to be done beforehand for the story to be estimated accurately.

In the case of keeping the designs elements done prior sprint, how do you manage this in SCRUM? I.e: how do you plan the work that needs to happen ahead of the sprint/plan your designers capacity? I was thinking of having separate design tasks that link to the stories, that way we could add them to the sprint backlog so that the designer can work on the tasks for the stories that will be in the next sprint backlog while the developers work on current sprint tasks.

The reason why I was thinking of separate tasks linked to stories is because the stories themselves can't be put in the sprint since the devs wouldn't be able to deliver their side of the story. Thoughts?

3
  • 3
    This whole thing is a process smell. You're treating design as "upstream" from development and testing, when all three disciplines should be working together to create a collaborative test-first mindset. – Todd A. Jacobs May 20 at 19:33
  • @ToddA.Jacobs As I mentioned, I'd love to be able to, I tried to get them to work together but it has created blockers, which is the mean reason for that post. How would you propose to solve the solution and get the disciplines to work together without designs blocking development? – Paz May 21 at 8:27
  • There is no magic bullet. Leadership, influence, coaching, education, organization structure, or management intervention are all options. Find the problem, fix the problem. If you lack the influence or authority to do these things, escalate to senior management. – Todd A. Jacobs May 21 at 15:47
11

I'd like to be "fully" agile and having design being part of the sprint [...]

I think there is a misunderstanding here, which is that in Agile there isn't any "upfront anything" and that the current iteration is the only place that things must happen. If this misunderstanding exists, people try to plan and do work only for the current sprint, which isn't always the best approach for all situations, as you've noticed.

If the designs are complex and take time to be built and it's essential for the developers to know how they look like to know how to estimate and what work is involved, then obviously you need the designs before you plan your current sprint. That means that the designer should work ahead of the developers to agree with the PO what is needed from an UX/UI point of view and prepare the designs ahead of time.

The only things you need to pay attention to are:

  • that the designer doesn't become a bottleneck and a blocker in your team's work. You say that "Sometimes, the designs might even be longer than our 2-weeks sprint iterations." This is a red flag. Why do they take so long? Are the designs very complex? Is the designer a perfectionist and they have a tendency to goldplate things? Is the PO the issue because they constantly change their mind about how the design should look like? Are you doing refinement wrong and not splitting the work in smaller pieces and you have to work with some huge story instead of a few smaller ones? Is one designer not enough for the size of the team. Do you need to hire more designers? What is going on? Figure out the root causes of the problem so you find a solution that actually fixes the problems not the symptoms.
  • try to avoid waste. If the designer works ahead of the team, then they might be missing some insight that the team can offer. This means that you risk the designer creating some designs that then, during a planning meeting, are discovered to be inadequate in some way and need to be redone. This causes waste. And here I come back to the no "upfront anything" I mentioned earlier. You have to pay close attention to how much work the designer does ahead of time. Too much work on a large time horizon can cause a lot of waste. So you needs to do "just enough" of work and planning ahead, to have the designs available to the developers in time, but not to much that the designers ends up working on their own instead of being involved in the "inspect, adapt, experiment, and learn" loop as the rest of the team.
6
  • Hey Bogdan, thanks a lot for your answer. It looks a lot like the approach that I'm thinking of taking by doing some design upfront but aren't we falling back into a waterfall way of working, albeit only for a couple of weeks at a time, by doing designs and THEN handing to devs? Of course devs would be availble to chat to the designer during their work and vice versa for designers during dev work for small tweaks to keep it agile but I'm still wondering if that's really still agile then – Paz May 21 at 8:34
  • Maybe i'm overcomplicating how I "envision" agile/scrum and try to be a stickler to the rule. Realistically we are still able to "adapt to change" because we're only designing a sprint ahead, not the whole app UX/UI at once so there shouldnt be too much "waste" or communication issues that way. – Paz May 21 at 8:41
  • 1
    @Paz: Ideally you should have all the activities in the same sprint. Unfortunately, we don't live in an ideal world. And in the real world trade-offs apply. There is indeed a risk of falling back to a Waterfall style approach, but if you are practicing Agile then you will experiment and then you will inspect and adapt. This will help you to find the right balance. – Bogdan May 21 at 9:50
  • 1
    What if you had a meeting between dev, design, etc. where the mockups were roughed out and agreed upon. Then design has a story in this sprint to polish/finalize the mockups and devs can start working on implementing the design based on the rough mockups? – JeffC May 21 at 21:00
  • @JeffC i actually thought of doing this. It could potentially work if we manage to keep stories small and this can be planned before the sprint planning occurs, like during PBI refinement activities. We still run the risk of the story failing if designs subtasks are not completed in time during the sprint then. But worth a try :) – Paz May 24 at 0:30
5

You already understand that UX/BA activities should be done before the Sprint starts, as developers need stories for planning. Your real question is how do you justify this approach from Scrum perspective (it's always the question with Scrum).

I can see couple of ways of justifying it:

  1. UX/BA tasks are part of the sprint. But their job isn't to deliver a working software, but it's still about delivering value. Which is all we need from Scrum perspective.
  2. Treat UX/BA as Product Owners. PO has to be prepare stories for planning.

As for managing tasks: personally I would return those tasks back to TODO and give them to developers. Just to decrease the number of extra noise in the task tracker. You can say that the job of UX is to prepare (describe) those tasks for developers.

PS: you seem to mix Agile and Scrum a lot. These are 2 very different concepts. Agile is very important as it's basically a synonym to Effective, while Scrum.. it's just one of many methodologies. Not the best one, probably not the worst.

PPS: don't try to be "fully Agile". When you say this - it means you're trying to follow some abstract ideas "to the letter". But the main idea of Agile is to be flexible and make decisions which make sense in your particular situation. So Agile is always different.

3

In Scrum, you have a Definition of Done. Equally important is your Definition of Ready — that is, what work is ready for sprint planning.

Now, since a level of “Done” may be applied to each station in a workflow, it is reasonable to surmise that this includes the transitioning of work into the Sprint Backlog itself. In other words, before work can be planned into a Sprint, the relevant items on the Product Backlog must be “Done” in terms of being sufficiently well described and understood. The Development Team must grasp enough of its scope to be able to plan it into a Sprint, and to frame some kind of commitment regarding its implementation so a Sprint Goal can be met.

Walking Through a Definition of Ready (Scrum.org)

It is a misconception that a story should be fully designed, developed and tested in a single sprint. It puts the team in precisely the same predicament you describe. The "design" of a story could include many artifacts outside of code. The larger the story, the more prep work needs to be completed before the team can estimate the effort and design the technical solution. Indeed, a mock-up or visual of some sort is essential. You are also correct in identifying that this design work can take more than one sprint.

Remember the main goal of agile, and Scrum, frankly: adapt to change. Eliminating Big Design Up Front does not mean no design up front. Design enough so developers and testers have confidence that they can start and complete the work in a single sprint.

Rather than adapting the workflow of gathering requirements to fit a sprint, work with the developers and testers on defining what is "ready" for sprint planning. Let the team tell you what information and design artifacts they need. This could be done informally as conversations or during a backlog grooming session. This does mean that UX and the BA need to work ahead of the team. Just don't get too far ahead that UX and the BA cannot adapt to change.

1
  • Thanks @Greg I think I resonate well with your answer and makes me think I'm on the right track. I am indeed trying to "minimize" how much design work is done upfront to remain "agile" in that sense. Just enough to get the stories in a "ready" state. I've got a kanban for my designer to take the stories through their own flow and then mark them as "ready for development" which is when they can be put in the sprint backlog that is run as SCRUM. Too early to say if it will work but the team seems to like the approach. – Paz May 21 at 8:38
2

I see two possible solutions:

  1. Consider the UX/UI designer as part of the SCRUM team. Whatever he/she does is a story, like all other stories. Now you have reduced the problem to the usual challenge of breaking down a task spanning more than one sprint, or more than one required participants, into pieces small enough not to have those issues. He will be there in the daily standups, can frequently get feedback from devs as to what he needs to do to make it possible to create "coding work", and so on. I personally would prefer this solution if you can make it work in your organization.

  2. Consider the UX/UI designer as external to the SCRUM team. Then the output from that design process is the input for the SCRUM user story, which means that at the time the story is taken into an active sprint, it must be such that the requirements are clear - effort can be estimated, and there is a good chance for it to be completed by the end of the sprint.

Clearly, you are thinking in terms of "2" already. Stories are brought into the required state in refinement sessions. These can easily be decoupled from the other sprint artifacts; for example if you have 2- or 3-week sprints, nothing keeps you from dedicating 2 hours per week for regularly planned refinement sessions. In these sessions, the UX/UI designer is like any other stakeholder and can present the state of his work.

At this point, it is a good time for the devs to ask questions about parts of the design that actually have a measurable influence on effort. For example; if a form is to be designed, it probably won't matter too much whether there are 5 or 6 attributes to be presented to the user. It will matter though if it is more a "wizard" style dialog and the question is whether there will be 2 or 10 steps. Together with the product owner, the devs and the designer, try to refine as much as needed so that the devs can at least begin with the functional parts of the implementation. This is also a good time for the devs to create an understanding on the side of the designer as to which of his choices influence effort, or not.

If the implementation of the design is larger and takes more than one sprint, still do break it down into smaller pieces, and implement them piecewise - making sure the designer understands which parts are hard to change later.

At the end of the day, as usual, it's the product owner's decision when to ask the team to actually start working on it during sprint planning; and it is the dev team's responsibility to decide whether they understand the requirements enough to do that, and ask questions as long as it takes.

2
  • 1
    I'd consider this (option 1.) the best answer. There will always be dependencies. Why not incorporate the/a the designer(s) into the scrum team and let them work ahead. Then the input for the estimation should be ready latest at the start of the next sprint. Or do some estimation in a meeting mid-sprint and groom the backlog if that's necessary. – Bim May 21 at 14:16
  • So do I, @Bim. I've added a small sentence to make that clearer. – AnoE May 25 at 6:51
0

In this situation I would make "UI design" part of the overall Sprint-based process.

1
  • Not sure what you mean by this. Can you provide further info/clarification? – Sarov May 21 at 14:12

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

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