This might lead to scenarios where there are multiple goals, even conflicting sometimes, but where the team is facing a real problem (how can we increase the buzz without being perceived as a nuisance) that could lead to creative solutions.

Another interesting outcome is that digging into the real complexity and the real goals might lead to interesting twists at the business goal level. For example a story like: “As a traveller, I want to buy a train ticket, So that I can take a train” started to look somewhat fake, the real one was more like “As a traveller, I want to take a train, So that I can go home” while the ticket looked more like a necessary step for the railway company in order to get paid. Buying the ticket on the train wasn’t a visible option in the first case, while it stood out in the second one.

Not all user stories deserve this “multiple point of views” approach, but it’s definitely worthwhile knowing it!
Thanks.

Cheers

Alberto

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.