Tag Archives: product owner

Increase Customer Satisfaction with the Kano Model

Posted by on 2012/01/14 No comments

A couple of weeks ago I had a great discussion with one of my colleagues about the Kano model and how we could use it to make better deliveries. The model itself is a classification of features of a product based on customer needs and attributes. It was created by Professor Noriaki Kano (on the right) in the 1980s. Professor Kano defined three different feature categories: basic, performance and excitement, which are represented on the diagram below. The x-axis defines the effort put into the execution/implementation of a feature, and the y-axis defines the customer’s satisfaction after receiving the feature. In the software industry poor execution can result in a faulty or unusable product.

The presence of the features belonging to the basic category which presence has no positive effect on the customer’s satisfaction – bottom right corner -, but they are must have features, so their absence or poor quality causes huge dissatisfaction – bottom left corner. Let’s say we are about to create a web shop. It is a must have feature to make it possible for a customer to sign up to the site. Even if it’s the most sophisticated sign up feature, for the users, it is just a sign up feature, but without it or with a faulty one, they cannot use the site, so they’ll leave.
Satisfaction in the features categorized as performance is proportional to the quality in which the features are implemented/delivered. Let’s say we introduce Facebook as an alternative sign up procedure. It isn’t a must have feature, but it will increase the customers’ satisfaction in the project: the users can use their existing accounts, and we don’t have to store user data unnecessarily. After Facebook we introduce twitter as the next alternative. It has no effect on the existing users but may attract more customers.
The last category is the excitement which is the complete opposite of the basic category: the presence of an excitement feature drastically increases the customers’ satisfaction, but nothing happens when it is not there or doesn’t work as expected. For example, we introduce a feature which allows customers to use our shop without signing up, just using their email address and PayPal. If it’s available, the users will be excited to use this great convenience feature, if it’s not, they won’t miss it

Read more »

VN:F [1.9.17_1161]
Rating: 0.0/10 (0 votes cast)

Listen to Experts but Trust Your Team Members

Posted by on 2012/01/08 No comments

Back when I was working in a project as a team leader, on a cloudy Thursday an expert took me aside to talk about the time reporting of one of my team members. He pointed out that the team member in question spent about 6 hours doing a certain task which he – the expert – could have done in 15 minutes. He insisted that I called her to account for the time spent on this task. It was an awkward situation, because I knew that she had worked hard all day – I sat with the team and I knew that she hadn’t spent more than 5 minutes away from the task -, but still I was unable to explain the huge difference. Practically, that task consisted of two sub-tasks and unfortunately I had no experience with either of them.

Instead of talking to her immediately, I chose a different option: I decided to gain some experience on the matter and see how much time it really took to finish that task. I needed to choose this way, because if I had confronted her with the feedback from the expert, I would have only been able to tell her what he told me, that is that the task should have taken only 15 minutes to complete. Instead, I wanted to understand the situation and be able to help her to be more effective next time – provided that the expert was right and her time had indeed not been well spent in this case. Additionally, I wanted to leave the expert out of the discussion, because he wasn’t part of the team, and I felt that these discussions had to be done face-to-face: no need for a third person, an outsider to be there.

I scheduled our discussion for the next Monday, and I spent the preceding Sunday afternoon with the task at home. I needed 2.5 hours to complete the first sub-task, but I felt that I had already gained the necessary technical experience in order to have a constructive discussion on Monday. I assumed that the second sub-task was an easy one considering her technical level, so I estimated half an hour for it, adding up to a total of 3 hours to complete the whole task. Read more »

VN:F [1.9.17_1161]
Rating: 8.3/10 (3 votes cast)

Make the Customer Try Out Your Product

Posted by on 2011/12/07 No comments

I’ve been participating in demo meetings with customers and product owners for years now, but we seldom talked about interesting things or rarely made significant decisions during these meetings. There can be several explanations to that, but I’m pretty convinced that we were doing these meetings wrong. The chart below depicts the categories help you understand why I think this way. Here are the content of the user stories brought to the meetings:

The figure represents quite a typical progress, nothing is wrong about it at first sight. Let’s add to the picture what has been discussed after each sprint during the mentioned demo meeting. For example, during the demo meeting of sprint 3, we mostly talked about user interface (UI) issues and only a little about functionality:

In most of the cases the team presents a subset of user stories during the meeting, and the customer just sits there – because it is a presentation after all – and has a couple of comments on the user interface of the product. Sometimes, they talk about real functionality, but that is not enough. Everything is just fine until the product is released or delivered for system testing:

This is the point when the customer really “enters” into the “functionality” section and even into the “non-functional requirements” section and starts using the product. What happens now is a disaster, because

  • the delivered software works differently than it is supposed to work
  • nobody really remembers how to use the product
  • it doesn’t meet the performance criteria

I think everybody has been in a similar situation who is doing Scrum. Read more »

VN:F [1.9.17_1161]
Rating: 10.0/10 (2 votes cast)

Introducing the Expectation Line in Scrum

Posted by on 2011/11/12 5 comments

Several weeks ago my colleague Tamás made an interesting point about our planning meetings: we always committed to an iteration backlog – we are doing an interesting combination of Scrum and Kanban, but not Scrumban -, but we never asked our product owner whether she was happy with our commitment. She said that she hadn’t been satisfied, but followed what Scrum said anyway - classic autopilot behavior. This got me thinking and I realized that during the last couple of years every product owner I met had this very same problem: scrum was new and it didn’t help them much, because before Scrum the business dictated the speed of the development, but after introducing Scrum the development slowed down and started to live its own separate life.

In order to understand why, first have a look at this typical iteration backlog lifecycle:

The first sprint is usually more successful than the second one, but after five or six sprints the number of delivered user stories stabilizes – in Scrum terms: the velocity becomes stable. I talked to different Scrum Masters from different organisations and they independently told me that after the teams reach this kind of threshold, no matter what the product owner says or does, they deliver exactly the same amount of user stories. This is the point when the team starts its own life and starts to dictate to business: no matter what the product owner‘s expectation is, she will get the same amount of user stories sprint by sprint. Which is somehow good, makes the development predictable, but the business is never predictable, on the contrary, it changes a lot. Since the outcome of the planning does not follow the expectations of the product owner – which is driven by the business – she starts to ignore Scrum and eventually she gives up and from then on she will just pretend to be a product owner, when in reality she will fall back to classic project management.

Read more »

VN:F [1.9.17_1161]
Rating: 10.0/10 (1 vote cast)