WHEN IS THE USER STORY “MAKE IT BETTER” FINISHED?

We’ve all been told to do the system safer, better looking, faster, or any other vague requirements. So we do what we think solves the problem. But it wasn’t really what the stakeholder wanted. Can we avoid this by quantifying what better means, by putting numbers on it and measure when we are done?

The users probably don’t know what they want. Don’t be satisfied with that. Ask questions and clarify the intent. Then make it measurable so you know when you are finished. And yes, you can quantify everything.

Why are requirements vague?

We don’t know when we arrive if we don’t know where we’re going. A vague requirement is like asking how long a string is. Not useful. Fuzziness is what we have learned to expect when we talk to stakeholders. And it’s actually not hard to understand why if you think of it.

By the way, I often talk about the stakeholder instead of the user. If you want to know more about who the stakeholder is, read about it in this article. Back to the subject…

The users have a problem. They want to solve it, and they have a general idea of how. The more they know of the domain, the more they can contribute to the solution. I mean, ask an accountant how to keep books and you will get a pretty accurate answer.

But ask Joe Average about how to make a system hard to penetrate for hackers, and the answer will most likely be uneducated. He has been told to look out for hackers, but he has absolutely no clue on what a hacker does or how to protect himself.

And yet, we demand of our stakeholders that they will give us the perfect description of their problems…

A helping hand

This is where we have to help them. We have to ask the questions that reveal what they actually want. For instance, if the stakeholder says that the system should be faster, what does she mean by that? Obviously, she has had to wait for it in one way or another. But is it just a general feeling that the system is sluggish, or is it a particular operation that is painful?

The stakeholders probably don’t know what we expect of them to finish our job. I mean, how could they know anything about what we do and what we need? Isn’t that why we spent years educating us in software development, while they spent their time learning bookkeeping and economics? And isn’t that why they tell us how the system should calculate interests? To develop a system is a partnership, we both contribute with our part of the knowledge.

We have to ask the questions that give us the answers we need. We have to guide them to understanding the problem and to help them find the solution. And as far as fuzzy requirements, we have to help them quantify their needs.

Measuring success

Take the example of making a system safer. The stakeholder has learned that a system has to be safe. So, they give us that requirement. But what do they mean by safe? Is it up-time? Hacker proof? High privacy? Or does it just not harm the user physically?

And if we actually managed to say that it should be harder to break into than the previous system, what does that mean? When is the system safer?

I mean, if the requirement is stated like that, we will have it done it just by making sure that the password has to be one character more than the old system. Obviously doesn’t do much, but still, it is safer. And I can’t imagine that this will satisfy the customers need.

On the other hand, I could rewrite the entire system and make it harder to hack than NSA or CIA. But the time it would take to finish it, and the cost of doing it would probably be way too high.

In fact, if we don’t define the goals of the requirements, I’m not sure we’re even talking the same language as the customer…

We have to be specific about what we want, and we have to be able to measure when we reach the goal. That is step one.

Step two is to define how much safer the system should be compared to the previous. We have to know when we are done. We have to be able to agree on the levels we’re shooting for.

Conclusion

Software development is an engineering practice. Engineering is about defining what we want done, quantifying it. Just saying “better” only shows that we don’t know what we want and that is why we never know when we arrive. It is bad communication. Each person has their own view of what “better” means. And if we can’t agree on what should be done, someone will be disappointed in the end.

More information

The obvious: Tom Gilb and his son Kai Gilb talk a lot about this. Google them…

If you want to read about it, he has written a few books on the topic. 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!