Tell me more ×
User Experience Stack Exchange is a question and answer site for user experience researchers and experts. It's 100% free, no registration required.
up vote 2 down vote favorite
1

I am a firm believer that design happens in every part of a company. Encouraging participation in Story creation follows that vein.

We have been experimenting with encouraging anyone - programmers, testers, admins - to create Stories, with some positive initial results. We usually need to do more work to clean up, flesh out, investigate, consolidate, or otherwise cull Stories, and there is a wide range of quality, but overall it seems worth it for both the comprehensiveness of the ideas we collect and, perhaps more importantly, keeping everyone engaged in the goal of delighting users.

Have others included non-UX people in Story creation with success? If so, how?

I am starting to think that the concept of User Stories is too UX-domain specific, though - as much as I advocate, some programmers, testers, etc. seem to think that's too touchy-feely and structured. Would we be better off staying more generic and calling them Suggestions?

share|improve this question
1  
What do you consider a user story? – Alex Feinman Nov 4 '11 at 20:09
Basically, an explanation of a user goal or problem in the form of a sentence: "As a <user/role>, I want <something> so I can <objective>." Wikipedia's article is pretty much representative of my view. – peteorpeter Nov 5 '11 at 2:47

3 Answers

up vote 3 down vote

At my previous company (which liked to consider itself an Agile development company) we used user stories to moderate success. I think calling then suggestions would be a great idea if what you're looking for is simply ideas. The problem we had was that we told everyone the proper form for A User Story and they then resisted the idea of entering anything into our story tracker because they didn't want to write the title and the "as a ..., I want to ..." aspects of the story.

Calling them suggestions gives the concept a less rigid structure and, as long as you have people willing to flesh out those stories based on potentially just a title, I think you'll get a lot more buy-in from the the company as a whole. This will, of course, put extra pressure on those who have to flesh out the stories (in my case, it was me and my developers), so you have to balance that out with the potential getting more ideas in the first place.

Bottom line: make it easy for any person in the company to give a 1- or 2-liner suggestion and I think you'll get a lot of great ideas flowing that you can work on prioritizing and expanding.

share|improve this answer
1  
The problem you had with the conventional User Story form sounds very familiar. As I was explaining the structure to the team, I could feel the resistance growing. I like the idea of minimizing the importance of the structure as much as possible. In practice, we don't require any, but if people feel like they might do it wrong they might not contribute at all... – peteorpeter Nov 3 '11 at 20:07
2  
Exactly. Another problem we had fairly regularly was during backlog grooming sessions: our users HATED seeing the full user story they spent so much time on get deleted, in spite of [mostly] agreeing that it wasn't needed any more. They felt like they wasted their time: doing something they really didn't want to do in the first place that eventually got deleted. They complained so much that, eventually, they were told to just send their ideas to me via email for me to add into our system. – Karen Nov 3 '11 at 20:13
Ahh, I could see that happening - too much buy in! We haven't had that issue (yet) - probably because most people in the company have seen the sausage factory that is our scheduling process in action and have low expectations about a given story making it through unscathed! – peteorpeter Nov 4 '11 at 18:47
up vote 1 down vote

Along the lines of what Karen said, I like to do a full team workshop on user scenarios, which are more open ended and high level than user stories. This way, the full team can participate and contribute. A lot of interesting perspectives and ideas come out of this kind of meeting or workshop. Then, one or two members of the team can take the scenarios and refine them into more properly formatted and granular user stories.

share|improve this answer
1  
Huh, I think of scenarios as a more low level description of interactions than stories, as in "the user enters their UID and clicks Login", but I haven't worked in the Use Case / User Scenario world. How would you define a scenario? – peteorpeter Nov 4 '11 at 18:44
Scenarios are usually tied to personas and are part of creating a story about who the user of a particular technology is, what they want, what they know. A scenario is therefore usually written in narrative form, perhaps with pictures and illustrations as well. Scenarios are generally written at the beginning of a project during discovery and requirements gathering phases. They provide human-centered anchors to guide design and development by providing tangible faces, names and stories for how technology will be used. – Nadine Schaeffer Nov 4 '11 at 21:22
1  
I wrote a whole blog post trying to untangle the differences between use case, scenarios and user stories, if you'd like to read more: cloudforestdesign.com/… – Nadine Schaeffer Nov 4 '11 at 21:23
Nice article! Thanks for the link. I'm reading you loud and clear now. I was thinking of the "use case scenarios" I've bumped into in enterprise requirements documents, which are essentially itty-bitty sub-parts of use cases - very different concept! – peteorpeter Nov 5 '11 at 3:05
up vote 0 down vote

Yes, you should build user stories with a cross-functional team.

I don't think you need to include everyone in the company. I'm not even sure you need to represent all the parts of the company. But people who are useful include, in no particular order:

  • Developers and QEs
  • Usability specialists
  • Designers
  • Customer support (!!) and/or trainers if you have any
  • Marketers
  • If possible, actual customers
  • ...
share|improve this answer

Your Answer

 
discard

By posting your answer, you agree to the privacy policy and terms of service.

Not the answer you're looking for? Browse other questions tagged or ask your own question.