Explore

Use UX research to drive the meaning of “done”

“Done” is the moment we say “This thing is ready to share”. Traditionally in Agile it’s measured as workings software. The problem is that this does not include any idea of quality, in the sense that we don’t know whether or not that’s working well for the users. So we have to figure out a way to include UX criteria into the definition of done, what success looks like from a UX perspective

To do that we need to do some research, and we need to have that research ready when we do the estimation to help understand what we’re gonna get done in the sprint. Therefore that research must happen before the sprint, instead of squeezing it into the sprint.

That doesn’t work because it’s really hard to do and because we don’t have estimations based on research. And since the opposite of research is guessing, that means that we end up guessing what the estimate should be. We end up not doing research, so everything else is based on guesses, which makes it more likely to deliver things that don’t meet users’ needs.

Guesses are ok just as long as you can then turn them into hypothesis, research them and learn from that research. If you don’t do that, then the risk is that instead of actually helping people, you’re just imagining that you’re helping people.

How do we get the research done before the sprint?

You must start with user stories.

The traditional format of user stories is fine, but it must not be based on guesses, it must be based on research. To do that, we need research that helps us uncover the current experience.

Improving the user experience - from frustrating to delightful - is the definition of done

⁠

⁠

You need to know the current experience so you know the problems. If you know the problem to solve you can create solutions whose definition of done is expressed as a UX outcome (“if we do a good job a this, whose life are we improving and how?”). We need to get our teams to fall in love with the problems, we need to get everybody really excited about solving a given problem.

Problem focused stories vs. solution focused stories are key.

⁠

You can

derive your product roadmap from your experience vision⁠

UX outcomes work at every level: you can have UX outcomes inside a sprint, or at release level, at roadmap level, and at experience vision level. The larges scale of UX outcome is the experience vision. Experience visions are absolutely essentials in proactive UX.

⁠

Dual track research

dual track⁠

research there is a development track and a discovery track.

The discovery track includes sprints that happen before the development track. In those sprints we create our understanding of the user experience and get our understanding of what it is we’re going to build for the estimation.

⁠

In practice, we’re always researching, and we’re trying to provide as much research as possible for the development track (we learn how to drip that research into the development track the best possible way), instead of squeezing research into the development track sprints.

This research must be more than usability testing. It has to be effective in terms of increasing the knowledge of the team.

⁠