I totally, 100% agree that quick feedback is important, and delivering the smallest amount of user value quickly is important. However, ‘usability’, like quality in general, is not a gloss that you paint on to a solution when you’ve finished – usability, and quality, must be built in to the design from day one. This is true, I think, even when you deliver only a small portion of functionality. It’s a bit like bugs in software: what is more efficient? Painting on quality at the end by throwing hundreds of testers at code that is fundamentally poor? Or building quality into the cycle early? It’s the same with usability.

Also, ‘usability’ doesn’t always mean beautiful, animated, graphics, colours etc… it means clean, smooth user flows, optimised for the major use case and designed with the user in mind. (In fact, quite often beautiful, animated and graphics gets in the way of smooth, clean flows). The “with the user in mind” part is where the “As a User…” user story comes from…

cheers
will.

For me, the user should ideally get the simplest possible thing that will allow the business to get value. That might be something spoinky and beautiful, or it might be cheap and ugly. Maybe it only *starts off* cheap and ugly. Doing more than is useful is as wasteful as doing too little. The only way to know is to get feedback – and often usability isn’t the most useful thing to get feedback *on*.

While I accept that there are often cases where you need to build something that the user might not necessarily want or like, like a captcha in a registration process, I would argue that for everything you add and every line of code you write, you understand how that will impact the user. If there is not a positive impact, then why are you doing it? Sure, Fred the marketing guy wants to hype the game release by sending an email, but why did the user give his permission to receive it? If the email is full of Fred’s marketing wishes but gives the user no value, did Fred really get what he wants? Fred gets what he wants when the user gets what they want. If the user gets value, then Fred wins. So focus on what the user wants out of the email. Yes, Fred’s requirements are important – but he only gets what he wants when the user gets value. Understanding what that value is should be at the heart of user story creation.

Here’s the link to my article that I mentioned:
http://blog.williamgill.de/2011/08/25/scrum-user-stories-as-a-user-not-as-a-manager

Cheers,
Will.

I have found it illuminating to use FiveWhys to get to the root cause of who benefits from certain metrics or behaviours that come up in story definition.

In a current project the ‘man with the money’ at our customer’s company took one look at the “In order to” clauses and instantly knew they were the start of his cost-benefit case. These things really smooth the project along.