Many teams use user stories to communicate with the customer. They are a very nice way to handle customer requirements without writing large formal requirement documents. However, user stories are not the full solution. They capture intent, but mostly fail to initiate feedback about one of the most important aspects for the user: the user interface.

Sprint planning

The team invited the product owner for the sprint planning. The product owner was a teacher at a large university. The teams assignment was to build a system to keep track of students’ grades.

Progress in the previous sprints was very good. The product owner says to the team:

“We are happy with the software, but I miss something. As a teacher, I want to see the grades of all my students. Can you build that for us in the next sprint?”.

The team also thinks this is a great feature, so they create a user story and add it to the sprint backlog. The user story states: “As a teacher, I want to see the grades of all my students”.

The product owner agrees with this user story, it exactly describes what he wants. He left the building with a confident feeling.

Sprint and sprint review

After the sprint planning, the team starts working on the new features. They work very hard and finish in time. They invite the product owner again to attend the next sprint review.

A team member proudly demo’s the new functionality. After a few minutes, the product owner says: “But this is not what I wanted! I expected that it was possible to order by grade or student name. It also must be possible to print the overview.”

The team is really surprised, because they built exactly what the product owner asked. Why didn’t he say earlier on what he really wanted? How did that happen?

What went wrong?

In this case, the user story clearly did not communicate well enough. The team did not communicate well enough with the product owner during sprint planning and during the sprint itself. There was no complete picture of what the product owner really wanted. This happens sometimes on many levels.

The majority of the user stories are too abstract. Words on paper do not show a living picture of the system. Customers do not really ‘see’ these stories in the product in the same way the programmers do. The imagination of the customer is different from the imagination of the team.

The product owner could just have said that he needed to order by grade or student name, and that he wanted to print the overview. But he did not know that, until he saw the sprint result!

Conclusion

The customer does not know what he wants before he sees something that is wrong.

The solution is to get more feedback. Show something that will probably be wrong. My experience is that you have to show something to get the feedback you want.

Show something, create mockups!

One way of visualizing software is creating mockups. With a small and simple sketch of a screen or series of screens, the customer instantly sees what they have after a sprint is finished.

When the customers see what the team will build, you instantly get the feedback you want.

Tweet This Post

Subscribe Did you like this post? Subscribe for more! Subscribe via RSS (What is RSS?)

No related posts.