This post is getting some pretty interesting discussion on the blog. It's clearly a topic that people have strong feelings on. I'm interested in the thoughts of people here.
(Bias warning: I know Lane, the author of the post, and think she's scary smart ;-)
This used to be my preferred tool to get everybody to understand the work that UX folk did - but in more recent years I've begun to think that it can get in the way more than it helps. These days I see it more as a transitional tool rather than a long term solution.
The problems that I've seen with separate UX stories are:
* They can become something that gets dropped when pressure situations occur (it's 'only' a design story...)
* They get away from, on agile teams, the idea that all stories deliver direct business value (or Running Tested Features or whatever). I don't like design stories that fail to do this, in the same way I don't like development 'stories' like 'build database layer'.
* They tend to stay the sole job of the UX person and seem to act as a bit of a barrier to getting the whole team to help swarm on stories. They highlight the work - which is great - but they label it 'ux' so it becomes a subset of the teams responsibility rather than the whole team's responsibility.
I'd be interested to see how Lane feels about them in a years time - or as the team grows. (I wonder if these are really Rob/Lane stories rather than dev/design stories... if you see what I mean).
... hmm... should probably put this as a comment on the blog...
2 comments
[ 2.7 ms ] story [ 16.5 ms ] threadThis used to be my preferred tool to get everybody to understand the work that UX folk did - but in more recent years I've begun to think that it can get in the way more than it helps. These days I see it more as a transitional tool rather than a long term solution.
The problems that I've seen with separate UX stories are:
* They can become something that gets dropped when pressure situations occur (it's 'only' a design story...)
* They get away from, on agile teams, the idea that all stories deliver direct business value (or Running Tested Features or whatever). I don't like design stories that fail to do this, in the same way I don't like development 'stories' like 'build database layer'.
* They tend to stay the sole job of the UX person and seem to act as a bit of a barrier to getting the whole team to help swarm on stories. They highlight the work - which is great - but they label it 'ux' so it becomes a subset of the teams responsibility rather than the whole team's responsibility.
I'd be interested to see how Lane feels about them in a years time - or as the team grows. (I wonder if these are really Rob/Lane stories rather than dev/design stories... if you see what I mean).
... hmm... should probably put this as a comment on the blog...