3.2. Applying Scrum: Working with Customers
In the previous chapters of this course, the word “customer” was frequently used. This isn’t surprising; after all, the Agile Manifesto states that our “highest priority is to satisfy the customer”.
With this in mind, go over the Scrum Guide again and look for the word ‘customer’. Surprised? Yes, that’s right: there is not a single occurrence of the word ‘customer’. How then does a Product Owner work with a customer? How does the Product Owner know what the customer needs? For a framework which places huge importance on the Product Owner delivering and learning from the developed Increments, Scrum offers very little practical advice on how to achieve any of this.
1. Identify the Customer
Before a Product Owner can devise a strategy for interacting with the customer, they must first identify who the customer is. In some cases, this will be straightforward; it will be a single person or organisation who is paying for the product. In many other cases, it won’t be so simple. Some Product Owners may be launching a new product which as yet does not have any paying customers. Others may oversee a product which reaches millions of users where interacting with each is simply not feasible. Irrespective of this, the Product Owner must work with the business stakeholders to identify exactly who the customer is; without knowing this, how can the team possibly hope to meet the customer’s needs?
2. Delivering Increments
Once the customer has been identified, a Product Owner must determine how often the customer would want to receive the Increment. This might sound like a strange concept: wouldn’t customers want updates as soon as possible? Not necessarily. Consider a Product Owner who presides over the development of enterprise software. The organisation who receives the Increment may have to communicate details of the update across the company and provide training to ensure staff can still operate the software. Or how about a team which develops apps? Even if app stores could publish frequent updates to a single app, would customers want to receive updates for each app multiple times a day? The Product Owner must engage with the customer to find out the correct delivery frequency and use this to inform the length of the Sprint and the size of the batches of work they take on.
The actual delivery of the Increment is a process which must also be agreed. How does the customer wish to receive it? Is a deployment to the production environment enough or is there some effort required by the customer to accept the Increment? The Product Owner must understand this intimately to ensure the customer is not inconvenienced by the Increment.
3. Customer Feedback Events
If satisfying the needs of the customer is an Agile team’s highest priority, the second highest must, therefore, be to verify that the need has indeed been satisfied. In order to satisfy both priorities, teams must strive to get feedback from their customers.
Commonly, Product Owners will look at the usage statistics of the product to identify what customers need. How many users signed up for the newsletter? What percentage of visitors to the site checked out with a discount code? How many minutes did users spend in the app? And does any of this tell me what customers need us to do?
To understand the underlying reasons for the customer behaviour, such quantitative data is paired with qualitative data to provide a more complete picture of user behaviour and needs. If the Product Owner has direct access to the customer, scheduling feedback sessions will achieve this fairly easily. Where the product is used by thousands or millions of customers, the Product Owner will need to call upon user research techniques to get the information required.
With the complete picture, the Product Owner is finally able to learn more about the strengths and weaknesses of the product.
To make this clearer, let’s consider an example. A Product Owner may see that a high percentage of would-be customers on mobile devices leave the sign-up process at the payment step. The Product Owner may reasonably hypothesise that entering card payment details on smaller screens is the biggest hurdle that customers face. The team dutifully designs, implements and delivers an Increment which simplifies this process, but still, the Product Owner sees that the rate of signups has not changed significantly. By speaking with the customers, the Product Owner may learn that the real problem is that the payment page loads very slowly over on mobile devices causing many users to simply give up. Through this feedback, the Product Owner can add items to the backlog which optimise the performance of the product for users on cellular networks.
In the next post, we look at the make-up of the Scrum team, focusing on the Scrum Master role, and figuring out if UX designers are part of the Scrum Development Team.
About Agile Bites
Agile Bites is a series of posts written by Mohammed Rizwan which, when put together, intend to serve as a course for individuals and teams. Starting from Agile basics, we’ll move to more challenging topics such as Kanban’s work-in-progress limits and Scrum anti-patterns, whilst attempting to figure out exactly what an MVP is.
