How to incorporate UX/UI in sprint correctly when mockups are required to estimate a story?

Question

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?

Answer 1

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.

Answer 2

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.

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

Answer 4

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.

Answer 5

You could go "fully Agile" using something called A "Design Sprint". the thing is, the whole team won't be able to work on design and development at the same time. The User Centered Design Process always needs an ahead-approach to the technical team. Also the UX process must consider the technical expertise of the team, the technologies used and frameworks.

There's a lot of information on the web on Design Sprints and Agile/Scrum, but to summarize, you should handle Design Sprints and development Sprints in a parallel way; in my experience, they don't last the same amount of time. Usually, Design Sprints are longer, because you should consider Lean research and user testing.

Answer 6

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