UX Research and Scrum

A little while ago, I was wondering how Scrum and UX research work together. And after thinking it about for a while, plus asking friends and professionals, I have reached the following conclusions.

First a disclaimer, “I have reached the conclusions”. I am not claiming to be original or proposing anything new. This is just an exercise for me, a former academic, to keep writing and reacting to what I am reading and experiencing. I don’t have the time to do deep research anymore, but I don’t want to lose my writing “bug”.

Definitions

Let’s make sure we are talking about the same things:

• Scrum is an Agile process and follows an iterative approach. That means: if we are working on feature, then we don’t do one thing and then the next thing, and then the next one, and so on until it has the shape of a waterfall (get it?). At the end of the sprint we need to deliver something of value and releasable.
• Scrum is a framework for working in teams, to reduce costs and maximise value. Jeff Sutherland gives an example in his book of how he used scrum to get his house remodelled on time and under budget. So, scrum can be used for more things than digital products, as long as we follow the framework. Obviously.
• Scrum only recognises 3 roles: Scrum Master, Product Owner & Member of the Development Team. There are no UX Researchers in Scrum, but the Development Team is cross functional, so as a team, it should be able to do UX Research. One or more team members may be more “UX Researcher” than others, but the whole team does UX Research, it is not the job of X or Y to do UX Research.
• All Sprints are created equal. All Sprints start with a planning session, continue with Daily Stand-ups and daily work, and finish with Review and Retrospective. All sprints aim at producing a releasable feature.

My conclusion

• If the product is a digital product, then UX Research is done as part of the sprint. That simple. The team will receive a Product Backlog Item, may be a user story, but it will not say “how” to do it, it tells “what” and “why”. So, if the team thinks that they need UX research to get the item done, then it should be pursued.
• The grooming process done by the Product Owner and the Development Team may include some UX Research, so the Product Owner can use UX research tools to give a better insight on what it needs to be done, to help in the prioritisation, or to evaluate the value of the done items.
• The product could be a UX Insight. Imagine you are a UX consulting team, and you are hired to give UX insight into a product or service. Imagine that you also work using Scrum. Then your deliverable is not a digital product, but insights into the product or service; this insights may take the form of a report.

Obviously you can do things differently, you may have a Sprint Zero using the GV Sprint. You may have a UX team supporting the product. The Agile manifesto and principles let’s you do it, but it is not Scrum. There is nothing that stops you from creating your own methodology or framework, but you lose all the shared knowledge that helped created a common framework; and pretty much, you have to suffer alone all the failures that may sprung from that.

So, those were my conclusions. What do you think?

P.D.

I asked a colleague of mine, Victor Gonzalez from ITAM University in Mexico City, and his insight gave me a good food for thought. If you know Spanish, please check it here: https://medium.com/@victormgonzalez/agile-ux-por-qu%C3%A9-el-sprint-cero-es-una-aberraci%C3%B3n-a7e92828248