Comments on: It starts with a story…

By: Paul Littlebury

Paul Littlebury — Sun, 24 May 2015 01:34:00 +0000

I should add that in the recent projects I have been working on, we derive a Feature (one of many) from a User Story, then break that down into Scenarios (i.e. Capabilities). The Features/Scenarios are written in DSL, and executable as accurate acceptance tests. Just trying to tie out two worlds together. BDD/Kanban has warped/moulded my perceptions somewhat 😉

By: Paul Littlebury

Paul Littlebury — Sun, 24 May 2015 01:25:00 +0000

The issue you highlight, of people thinking of user stories as “what the user will have”, is a very pertinent one. This no doubt leads to vague user stories we have all seen. Like reading an answer, before you know the question. Or the uncomfortable shoe-horning, of the sometimes chaotic human thought process, into the standard user story template. This is a reason I am such an advocate of Behaviour-driven development, as the focus is on capabilities (to borrow your term) or scenarios (I believe these are in similar area). Whereas techies tend to look for path(s) and caveats, by default in user stories, clients tend to go straight for the destination, loaded with assumptions. That long-acknowledged, but narrowing gap in translation of requirements to code was improved by evolution of Agile, but the skill of writing user stories is still very underestimated! On projects, I think it is very important for people to push back on user stories, if clarity isn’t there. Surprisingly how little this happens – perhaps it’s a confidence things, and fear of a user story review, coming across as criticism. But I guess that is another discussion 🙂

By: Tueksta

Tueksta — Thu, 29 May 2014 20:27:00 +0000

There’s an easy test for your user story: Will it make sense if the “user” is blind and quadruplegic?
Or another test: Will it make sense in a technology-free fantasy-book?

If yes, than the user story probably describes actions and interactions of agents.
Otherwise you describe features of some software behaviour within a certain technological device.

By: Antony Marcano

Antony Marcano — Wed, 21 May 2014 07:16:00 +0000

Thanks for your comment Coyote. Indeed. Mike also pointed this out in his book, “User Stories Applied”, in the chapter “What Stories Are Not”. He summarises this again at the end of the chapter: “It is more important to think about users’ goals than to list the attributes of a solution.”

I suspect that many people who make the mistake of feature-orientation haven’t read Mike’s book, certainly not properly. So, I thought I’d try to provide a shorter explanation that gets the point across in a different way.

I think that part of the problem is that many people look at the apparent simplicity of user stories and just do what they’ve always done except with a superficial application of the Connextra template (As a…I want…So that…). They may read literature on the web and find plenty of examples (written by people with the same assimilation bias) that support their assumptions and association with their past experiences of ‘requirements’.

This focus on features is natural. I’m pretty sure there was a time where I also thought of stories in this way. This is explained quite well by a quote from Udi Dahan:
‘Users ultimately dictate solutions to us, as a delta from the previous set of solutions we’ve delivered them. That’s just human psychology – writer’s block when looking at a blank page, as compared to the ease with which we provide “constructive criticism” on somebody else’s work.’ -http://www.udidahan.com/2010/05/07/cqrs-isnt-the-answer-its-just-one-of-the-questions/
Quote Highlighted: https://diigo.com/01uzg5

It’s not just users, it’s also those who may represent the users such as Product Owners and Business Analysts. So, I thought I’d try to help people see the impact of feature-oriented stories rather than goal-oriented stories on their agility (as in the dictionary definition of the term). I hope people see this article and see the opportunities for increased flexibility and speed-to-market as an incentive to better understand the subtleties of user stories.

Thanks for reading.

By: Coyote Agile

Coyote Agile — Tue, 20 May 2014 16:32:00 +0000

Spot on! A friend of mine just sent me a link to this post because it’s one of my biggest pet peeves in Agile. I think it’s Mike Cohn that has a recording of a class on user stories where he points out that the difference between Waterfall specs and Agile stories is that the specs describe attributes of a system. The stories explain how the user’s experience will be enriched.