- --->In a message dated 4/7/2006 3:57:34 P.M. Mountain Daylight Time, firstname.lastname@example.org writes:
Incidentally, last year big task models built for user stories was my
"killer technique" for pulling some coherence into agile projects, this year
I've been working on projects that are so huge, with so many users and so
many stories, this big models don't serve me so well. So, user scenarios
are my "killer technique" for 2006. I'd like to get a little more studied
on them - or at least clean up my references when I cite them.Hmmm, I almost hate to beat on the same old drum, but have you rejected use cases as a mechanism for some reason? We had 240 of them on one 70 work-year project, and I have heard of projects with more. Assuming 10 or 20 user stories per use case, you would be able to handle a project with several thousand user stories this way. And with the altitude-based goal-level linking, there's always a "top" story to start reading and traversing from.Maybe you could do the next use case experiment - Replace the dry use case text with a concrete scenario, but keep the extension conditions intact. Then you could have a readable story and also the branching. Been wanting to try this experiment for some time. This could be the chance!
Humans and Technology
801.582.3162 1814 Ft Douglas Cir, Salt Lake City, UT 84103
http://alistair.cockburn.us/ | acockburn@...
"La perfection est atteinte non quand il ne reste rien a ajouter,
mais quand il ne reste rien a enlever." (Saint-Exupery)
"The first thing to build is trust." -- Brad Appleton
- --- In email@example.com, acockburn@... wrote:
> Hmmm, I almost hate to beat on the same old drum, but have yourejected use
> cases as a mechanism for some reason?No, I'm not sure I've rejected use cases... maybe a bit more
background on the problem would help.
Alistair - you and I have gone over this before, but I see the user
tasks I work with as sub-function - fish level use cases. I often
assemble them into a task workflow model that for me ends up feeling
like a use case writing excerise arranging task cards left to right
rather than numbered steps top to bottom. In my head it still feels
a bit like a use case, and I may stil express them vertically with
numbered steps later, and consider extenstions for each step.
In the agile projects I'm ending up in lately, user stories have been
written already, and they're a bit vague. Some describe the work
people do and could be expressed in use cases, some describe the tool
people use to do their work - like "data table with quick column
filtering." I can write a sub-functionish use-case that describes
the a user quick-filtering a data table... but what's missing here is
the motivation - the context. How quick is quick? Why would I as a
user need to filter? Is there a better way than filtering a bit
table to reach my goal?
Given an already existing backlog with hundreds of these stories in
it [painfully agreed to and prioritzed by stakeholders], a team
asking for some idea of the user interface, and little time to back
up and model this stuff as tasks or use cases, my response has been
to say: "tell me a story about how someone would typically use this
system - one that shows me how lots of these user stories connect
together." The result has been a user scenario - at least what I'm
calling a scenario - and looking at Writing Effective Use Cases what
I think you'd call a usage narrative - except I number the number the
steps so they're easier to find parts in during a discussion.
The goal with this activity is to illustrate a typical usage path,
with color commentary enough for me to sense why people are doing
what they're doing. I'd like to see the scenario run through as many
of these user stories as is reasonable so I can see why these stories
have been prioritized high. This often means the the scenario
wanders a little in goal level to pull in some details, and
isn't "happy path" - shows the user encountering some difficulties
and overcoming them.
Given a couple of these scenarios crossing through the system, I can
then build some simple storyboards to start to see how the
application might look. I can begin to idenity interaction contexts
And importantly for us on the projects I'm on right now, I can help
validate the backlog has what it needs in it: if no one can tell me a
story - a scenario - where a user needs the thing in the backlog -
let's get it out. If no one can tell a story without including
things that aren't yet in the backlog, let's get those in.
Yes, I suspect using use cases would have helped, but I sense it
would take more time to get what I need with them. And I think task
modeling would help - but again it might take more time than we
have. With an hour to write a scenario, and a couple hours to
prototype, everyone can start to visualize the system in a half day.
The longer I do this stuff, the more tools/techniques I use -
including use cases. But, often it depends on the team I'm working
with, what I could most easily teach/facillitate them into getting
results from. Today it's user scenarios - this time next year it may
be something else. Depends on my mood and the context. The main
goal for me is that I understand the human activities - the usage -
before suggesting user interface. The form tht understanding is
documented in is less important.
- --- In firstname.lastname@example.org, "Jeff Patton" <jpatton@...>
> In the agile projects I'm ending up in lately, user stories have
> written already, and they're a bit vague.Ah, that's VERY different from the way I interpreted the previous
> ... but what's missing here is
> the motivation - the context.
> Given an already existing backlog with hundreds of these stories
> In a message dated 4/7/2006 3:57:34 P.M. Mountain Daylight Time,and so
> email@example.com writes:
> I've been working on projects that are so huge, with so many users
> many stories, this big models don't serve me so well. So, userscenarios
> are my "killer technique" for 2006.The question I read this time is more: How do I make sense of
zillions of fish-level story card?
> The goal with this activity is to illustrate a typical usage path,I'll come back to your "color commentary" - to me that's important.
> with color commentary enough for me to sense why people are doing
> what they're doing. I'd like to see the scenario run through asmany
> of these user stories as is reasonable so I can see why thesestories
> have been prioritized high. This often means the the scenario...
> wanders a little in goal level to pull in some details, and
> isn't "happy path" - shows the user encountering some difficulties
> and overcoming them.
> Yes, I suspect using use cases would have helped, but I sense itIndeed, it seems that was never part of the options available. I like
> would take more time to get what I need with them.
your 'wandering scenario' approach. It's at least as good as anything
else for providing context after the fact.
Back to "color commentary". This is something that I have been
missing for a long time. And as mentioned in the previous note to
Fredrick, it is very sensitive to the medium used to contain it.
I am hungry for it, and generally at a loss as to how to provide
easy, natural, low-energy ways to capture, view and change it.
All ideas welcome.