WHO IS THIS “USER” THAT SCRUM KEEPS TALKING ABOUT?

When you see an example of a user story it always stars with: “As a USER…” But what hides behind this “user”? Who is s/he? Or what? And does it actually give me any value to start every story with a user?

The “user” is way to generic. Instead, you should be specific. Who, or what, makes the request? By identifying the stakeholders up front, you stand a much higher chance of making a system that actually works. So, what is a stakeholder, then?

The problem with Scrum, according to Tom Gilb

A co-worker woke my interest in what Tom Gilb has to say, a while ago. We were sitting and talking about Scrum, and what is not so good with it, and he mentioned that Mr Gilb has a lot to say about it. He talks a lot about agile is missing the engineering aspects of product development, and that this is the reason why so many projects fail. He thinks there is too much focus on the coding and too little on what to code, or in some cases what not to code. It is about defining the problem we’re trying to solve.

Stakeholders

It all starts with knowing who we are trying to solve a problem for. When we start a new project, we don’t know who the stakeholders are. Well actually, we don’t know much about the project at all. So, we start interviewing the customer, and write user stories. And as you know, a user story starts with: “As a User…”

A lot of us only write stories with the “user” in Scrum. This is a very generic persona that includes every person that uses the system. And even though Scrum wants us to specify the different kinds of users there are, many teams never use anything but the User. I mean, one third of the user story is actually dedicated to describing who the user is (the other two are what the problem and the solution is). Now, there are a few problems with the “user”.

User is too generic

First, if we don’t specify who the user is, we won’t get any help in finding out what problems they have, that we are going to solve. A user can be anything from a new customer that never used the system, a customer that shops a lot, to the system administrator. All three have different expectations of the system. But if we don’t bother to find, and specify, all users of the system, how can we think that we will find all requirements that they have?

There is another problem with the “user”. As generic and inclusive that s/he is, we’re is still missing a large part of the stakeholders. There are a lot of people that aren’t “users” of the system but still has a stake in it. And on top of that, what about all the non-person stakeholders that exist?

Here are a few examples: The Law, economy, hackers, climate change, developers, maintenance (both people and systems), sales, CEO and so on. Just by scratching the surface, you will find a lot of them. And if the system doesn’t solve their problems, it will not be the success that you were expecting.

Would you buy a car that for sure drives really well and is really comfortable, but takes a month to service? And what if it is really easy to steal? And on top of that what if it pollutes the world like nothing else? Come-on, give me a break! That is not a successful system… er… car. But I can bet, no one ever said: “As a environmentally aware…” when they wrote their stories for a new system.

Too many stakeholders?

The definition that Tom Gilb gives us of a stakeholder is:

“Any person, group or System, that have, or we want to have an interest in our project.”

Any person… That even doesn’t know she wants to use the system…

The list will grow long very fast. But Gilb has realised that we just can’t solve every problem there is at once, so he suggests that we, as the next step, identify who are the critical stakeholders.

It is good to find them all to begin with, because if you don’t, how can you be certain that you have found all the critical ones? You have to start with finding out who they are. Only then can you prioritize them.

As we read on in the definition:

The critical Stakeholders are the ones that can determine success or failure of your project.

This is usually a list of five to ten stakeholders, he says. So start with them. I mean, some stakeholders has a greater stake in the project than others, so focusing on them will get you closer to the goal faster.

More information

The obvious, google them. Tom Gilb and his son Kai Gilb talk a lot about this. So you will find a lot of material on line.

He has written a few books. I am currently reading Competitive Engineering. Not a book for the faint hearted. It is a heavy technical documentation-style of a book. But has a lot of useful information. And you can actually download it for free at:
www.gilb.com/competitive-engineering.

Why not listen to both Tom and Kai when they are interviewed by Jussi Mäkelä at the Scraping Toasts podcast?
www.scrapingtoasts.com

— Cheers!