what about user stories

20 Aug 2007 - 1:37pm
7 years ago
9 replies
892 reads
npangti
2005

hi,
met with some agile programmers and learned about 'user stories'.
wanted to know what everyone around here thinks about them...

warm regards
navin pangti
------------------
<http://www.dolka.com/> www.dolka.com
<http://www.himalayanvillage.com/> www.himalayanvillage.com
<http://www.pangti.com/> www.pangti.com

Comments

20 Aug 2007 - 1:38pm
npangti
2005

hi,
met with some agile programmers and learned about 'user stories'.
wanted to know what everyone around here thinks about them...

warm regards
navin pangti
------------------
<http://www.dolka.com/> www.dolka.com
<http://www.himalayanvillage.com/> www.himalayanvillage.com
<http://www.pangti.com/> www.pangti.com

20 Aug 2007 - 2:27pm
Morten Hjerde
2007

Hi
I attended a 2-day course in agile ("know thy enemy"). I'm actually a
Certified Scrum Master now :-)
The user stories are requirements written on a role - task - goal form:

As a [type or role of user]
I want to [perform some task]
So that I can [reach some goal]

That does not sound bad, but according to the guy from Danube Technologies
who taught the course we could just drop the role and goal parts. Everybody
who used agile did, according to him.

"I want to" was all the justification you needed in order to decide whether
a feature should be included or not.

- Morten

On 8/20/07, navin pangti <npangti at gmail.com> wrote:
>
> hi,
> met with some agile programmers and learned about 'user stories'.
> wanted to know what everyone around here thinks about them...
>
> warm regards
> navin pangti
> ------------------
> < http://www.dolka.com/> www.dolka.com
> <http://www.himalayanvillage.com/> www.himalayanvillage.com
> <http://www.pangti.com/> www.pangti.com
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://beta.ixda.org/guidelines
> List Help .................. http://beta.ixda.org/help
> Unsubscribe ................ http://beta.ixda.org/unsubscribe
> Questions .................. list at ixda.org
> Home ....................... http://beta.ixda.org
>

--
Morten Hjerde
http://sender11.typepad.com

20 Aug 2007 - 3:52pm
Robert Hoekman, Jr.
2005

> "I want to" was all the justification you needed in order to decide
> whether
> a feature should be included or not.

If I had a dime for every "I want to" feature that should NOT be included in
an app, I'd be on the beach right now.

-r-

20 Aug 2007 - 4:14pm
brennste
2007

This sounds very similar to how I am using use-case scenarios. I work
with users and stakeholders to define their goals. I then create and
map scenarios to these goals. If a scenario doesn't support a goal,
I drop the scenario.

Jim

. . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
Posted from the new ixda.org
http://beta.ixda.org/discuss?post=19520

20 Aug 2007 - 5:16pm
SemanticWill
2007

" guy from Danube Technologies
who taught the course we could just drop the role and goal parts. Everybody
who used agile did, according to him."

If you drop the User's Role (based on well researched personas), and the
goal (goal, intent, behavior, attitude - as in What the user wants to do,
how they want to do it, and how they feel about it), all you are left with
is feature driven development. This is the opposite of user centered design
- and we should call them on it every single time. If there are no roles,
and no goals - you have NADA (as in "not another developer application").

But more insidious is this implication that the developers are writing user
scenario stories as requirements that lack users.

>From Danube Technologies website: " In contrast to traditional approaches,
modern application development calls for the ability to deliver software
that meets user needs even when those needs are rapidly emerging. Rather
than avoid change, we've decided to embrace it."

Interesting - don't you think? How can they claim their solutions meet users
needs if they don't take users into account? And why did they choose needs
instead of goals -- that is not a distinction without a difference. Those
two are very different perspectives.

I have been working on combining Agile with UCD for the last 4 months - and
can tell you I use a variation of the role, action, goal, result format -
and the role/user is based on extensively researched user personas. It is
possible to do the two - but it requires collaboration between people that
know/care/practice agile with a partner that knows/cares/practices user
centered design.

--
~ we

-------------------------------------
n: will evans
t: user experience architect
e: wkevans4 at gmail.com

-------------------------------------

On 8/20/07, Jim Brennsteiner <brennste at ctc.com> wrote:
>
> This sounds very similar to how I am using use-case scenarios. I work
> with users and stakeholders to define their goals. I then create and
> map scenarios to these goals. If a scenario doesn't support a goal,
> I drop the scenario.
>
> Jim
>
>
> . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . .
> Posted from the new ixda.org
> http://beta.ixda.org/discuss?post=19520
>
>
> ________________________________________________________________
> Welcome to the Interaction Design Association (IxDA)!
> To post to this list ....... discuss at ixda.org
> List Guidelines ............ http://beta.ixda.org/guidelines
> List Help .................. http://beta.ixda.org/help
> Unsubscribe ................ http://beta.ixda.org/unsubscribe
> Questions .................. list at ixda.org
> Home ....................... http://beta.ixda.org
>

20 Aug 2007 - 11:20pm
npangti
2005

> This sounds very similar to how I am using use-case scenarios. I work with
users and stakeholders to define their goals. I then create and map
scenarios to these goals. If a scenario doesn't support a goal, I drop the
scenario.
Jim

in the services business, i have always seen 'hands on proj management' i.e.
people/teams do 'whatever it takes' to finish (release) the task (app) in a
stipulated time... even if one has to strip down the features to do so. when
we say agile, or scrum and so on....i wonder if people are creating too many
jargons to create niche and suit their specific needs. i mean if one is
short of time wont a narrative use case become a user story?

regards
navin pangti
------------------
www.dolka.com
www.himalayanvillage.com
www.pangti.com

21 Aug 2007 - 5:43am
Stew Dean
2007

On 20/08/07, navin pangti <npangti at gmail.com> wrote:
> hi,
> met with some agile programmers and learned about 'user stories'.
> wanted to know what everyone around here thinks about them...

They're like a light version of user journeys and a reaction to how
clunky use cases where getting.

The advantage is they can get the workings of a bit of functionality
across quickly, the down side is they can be too fluffy - until
they've had the detail a user journey/flow can add (or a use case
without including all the 'user then presses a button' and 'the system
then accesses the shoe size look up table' type stuff) they can easily
be mis interpetated.

It's what happens to the user stories next that is key. Also building
user stories witout user input is also something that can also happen,
which can restult in skewed stories or stories that are more about
what developers what to build.

So does user centered design (the approach) mesh well with agile (the process?)?

I should do a course in this as well.

Stew Dean

--
Stewart Dean

21 Aug 2007 - 5:46am
Faith Peterson
2007

As a CSM like Morten, I'd have to say that Agile != user stories. User
stories are just one tool used in Agile methodologies. There are other more
significant defining characteristics of Agile methodologies. The major one
is a completely different approach to prioritization and planning. Agile
avoids most of the circumstances that lead to last-minute triage in a
project. When it does have to happen, the way Agile work is prioritized
allows decisions about what to drop to be made according to pre-planned and
expected principles.

In Agile design, user stories would include not just the bare task but might
also include interaction decisions - for example, As a SomeRole I can use a
folder tree to browse for files so that I can use the folder names to help
me decide where to look. The team would estimate not just "I can find a
file" but the whole interaction.

That said, re user stories, I also have had developers try to drop the role
and rationale parts of the stories and focus only on the task. I just refuse
to remove them. I think the rationale (or goal) drives interaction design
decisions as much if not more than the task itself.

To the observation that most Agile practitioners only use the task, that
could be because most Agile practitioners are developers. There's even a
whole wing of the Agile community that believes there's no room for
non-developers on the implementation team. So one would expect that people
who by training and experience don't understand interaction design would try
to drop the non-task parts.

If the design/development process is viewed as a negotiation or dialectic,
dropping the role and goal can be the opening move in a battle you will have
to fight later. At some point in every project I've been on for some feature
the developer wants to cut corners - do it a faster way, do it an easier
way, do it some way s/he already knows how to do - or overtly challenge
whether users really need the feature to work as designed. In general I like
it when developers question the designs. In this type of discussion the role
and goal are essential. However, if you've already agreed that they aren't
important enough to include in the story it's tough to bring them back. And
in any case in Agile you get this stuff worked out ahead of time, so the
developers have already agreed to the interaction at the time they agree to
take the user story on to implement.

The above comments are purely pragmatic - most of the time I work in the
happy meadow where developers and designers collaborate generously. I'm
privileged to work with some really great developers. Even so, when it comes
time for tradeoffs the role and goal are necessary if decisions will be made
on anything beyond technical expediency.

Faith

On 8/21/07, navin pangti <npangti at gmail.com> wrote:
>
> ....i wonder if people are creating too many
> jargons to create niche and suit their specific needs. i mean if one is
> short of time wont a narrative use case become a user story?
>
> regards
> navin pangti
>
--
Faith Peterson
f.a.peterson at gmail.com
Schaumburg, IL
http://www.linkedin.com/in/fpeterson

21 Aug 2007 - 3:29pm
Morten Hjerde
2007

On 8/21/07, Faith Peterson <f.a.peterson at gmail.com> wrote:
>
> - most of the time I work in the
> happy meadow where developers and designers collaborate generously. I'm
> privileged to work with some really great developers.
>

Hey! That is something that is not mentioned as often as it should. Its easy
to focus on the problems, especially in a setting like this. Thanks!

--
Morten Hjerde
http://sender11.typepad.com

Syndicate content Get the feed