Why Agile teams shouldn’t be speaking to users every week

What are some of the things you do on a weekly basis at work? Attend a weekly planning meeting? 1–2–1 with the boss? Lunch with the team? How about speak to your users? If you’re part of an Agile team this might be something that you’re doing on a weekly basis, or perhaps striving to do.

In an attempt to squeeze user research into an Agile process, there’s been a push in many organisations to focus on small, frequent research, rather than research activities at the beginning of a project. Championed by thought leaders such as Teresa Torres, this approach has become known as continuous discovery:

Continuous discovery is an approach to user research used in agile teams where research is conducted as small, frequent activities throughout the product development lifecycle. This infuses customer feedback into all product decisions instead of focusing on one-time research activity at the beginning of a project.

Interaction design foundation

Rather than upfront research which can potentially slow things down, teams undertake ongoing user research to inform product decisions, usually in the form of weekly research sessions with users. Surely a team continually speaking to your users is a good thing, is it not? Well in theory yes, in practice, I don’t think so.

When teams undertake continuous discovery, they tend to set-up weekly research sessions with users, such as 1 or 2 sessions on say a Wednesday afternoon. However, because planning, recruiting and analysing sessions every week takes significant time and effort, these sessions either consume a lot of a team’s weekly resources, or effort is kept to a minimum, so they invariably turn into unstructured chats with whoever a team can get easily get hold of. Teams tell themselves that they are carrying out important user research, when in reality they’re having fireside chats with random users. This counterproductive behaviour can be amplified when teams are measured by the number of users they speak to. Teams will go through the motions with users simply because they need to hit their target of speaking to X users a week.

Continuously undertaking poorly planned user research not only means that there is less time for a team to do other important work, it can lead to them making poor decisions based on the input from just 1 or 2 users; users who might not even be representative of the wider user base. For most qualitative user research, it’s a good idea to speak to at least 8–10 users (more if there is a very diverse user base) since you’re looking for trends. If a team is speaking to only 2 users a week, then it will take a month to speak to 8 users. If a team is only speaking to 1 user a week it will take 2 months. That doesn’t sound very Agile to me.

Don’t get me wrong, I’m not against the concept of continuous discovery, it’s the X user sessions a week approach that many teams take that I’m against. Rather than ‘Continuous discovery’ I think that teams should be aiming for regular bursts of discovery. In my experience teams are better off carrying out 1–2 days of focused user research a month, rather than 1 or 2 user research sessions a week. This provides more time to plan sessions and to recruit users. It makes it easier to schedule user research activities with teams and reduces the risk of making product decisions based on the feedback from just 1 or 2 users. Of course, user research can be carried out outside of these 1–2 day bursts, but only when it makes sense to do so. Rather than being a slave to continuous discovery teams should find a user research approach and cadence that works for them.

User interview photo by KOBU Agency on Unsplash

--

--

Former techy turned UX Jedi from the UK. Checkout out my blog (UX for the Masses) for more about me.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Neil Turner

Former techy turned UX Jedi from the UK. Checkout out my blog (UX for the Masses) for more about me.