- Our developers are using agile development for a complex software
I am interested in ensuring that the day-in-the-life narrative stories ares
built in from the beginning rather than waiting for summative usability
testing to catch these issues and then having to beg for rework resources.
Do you have recommendations on how to get context and environment
requirements as inputs into development? Others real world inputs could
include: time pressures, distractions and recovery strategies, error
prevention, work flow efficiency, satisfaction, etc.
I assume that these real world design constraints would be conveyed in
stories, but not sure how to achieve the goal of optimized user workflow
while using stories that fundamentally compartmentalize parts of the system.
I know how I'd do this using a waterfall or spiral method, but not sure how
to address these whole-system issues within the context of agile timeboxing.
View this message in context: http://www.nabble.com/Cross-application-integrity-tf2261158.html#a6273548
Sent from the Agile Usability forum at Nabble.com.
- Suzanne Currie wrote:
> Do you have recommendations on how to get context and environmentHi, Suzanne. Your question is a good one.
> requirements as inputs into development? Others real world inputs could
> include: time pressures, distractions and recovery strategies, error
> prevention, work flow efficiency, satisfaction, etc.
> I assume that these real world design constraints would be conveyed in
> stories, but not sure how to achieve the goal of optimized user workflow
> while using stories that fundamentally compartmentalize parts of the system.
> I know how I'd do this using a waterfall or spiral method, but not sure how
> to address these whole-system issues within the context of agile timeboxing.
For the projects I've seen, that information is transmitted in four
ways. One is that the people on the product side pick stories that
address those concerns. Another is that during construction, the
continuous presence of product managers allows developers to understand
the subtleties and the spirit that drives the stories. A third comes
from a tight feedback loop between product managers and developers: the
developers show their work every few hours, and product managers respond
to it, keeping it on the right path. And the last comes from user
testing and frequent releases: actual use helps both product managers
and developers understand real-world implications.
In other words, the product managers care about the real-world
implications, they demonstrate that care through close interaction with
the developers, and they refresh and deepen that care through frequent
contact with the real world.
Does that help?
> I am interested in ensuring that the day-in-the-lifeI find Scenarios and Personaes very useful for that. I find they provide
> narrative stories ares built in from the beginning rather
> than waiting for summative usability testing to catch these
> issues and then having to beg for rework resources.
> Do you have recommendations on how to get context and
> environment requirements as inputs into development? Others
> real world inputs could
> include: time pressures, distractions and recovery
> strategies, error prevention, work flow efficiency, satisfaction, etc.
> I assume that these real world design constraints would be
> conveyed in stories, but not sure how to achieve the goal of
> optimized user workflow while using stories that
> fundamentally compartmentalize parts of the system.
> I know how I'd do this using a waterfall or spiral method,
> but not sure how to address these whole-system issues within
> the context of agile timeboxing.
more texture and contextual information than say, UserRole, UserTask and
By Scenario, I mean a short story that describes a particular journey
through the system by a particular person. The story could happen in one
day, or over many weeks. I usually reference UserRole and UserTasks in
those Scenarios. Here's an example:
Below is an example of such a scenario at the end of this message. It
was written in the context of designing a multilingual wiki (i.e. a wiki
that allows a community of volunteers to collaboratively maintain wiki
content in multiliple languages). It's a bit on the long side, but you
don't have to make them that long. I wrote it that long because I wanted
to get a feel for what the whole system might feel like to a volunteer
translator who is somewhat pleasure driven, but also wanting to "do the
Note that in writing such scenarios, it's important to stay grounded in
actual user data. In other words, don't make up scenarios or people.
Tell the story of real people and real things that they have experienced
or could have experienced. In this case, Hakan (pseudonym) is a real
person who actually does volunteer translation time on a wiki, and I
have had long conversaions about it with him.
Note how the volunteer-based nature wiki work and its consequences in
terms of how the system needs to support the user, really come alive in
that story. This is the kind of stuff I find harder to convey with more
abstract UserTasks and UseCases.
== Example of scenario
Hakan is a Turkish contributor to the Fluwiki site. His contributions
are mostly at the level of translation. He has a genuine interest in
preventing pandemic flu, and he has some knowlege of the domain (in
particular, he knows the terminology fairly well), but he is by no means
a domain expert. Hakan is somewhat pleasure driven in his Fluwikie
volunteer work. He knows that Fluwikie is fulfilling an important
mission and wants to work in the best interest of the site by
translating the items that are of highest priority. But at the same
time, he finds translating whole pages more fun than translating short
updates to existing pages, and sometimes, he just feels like giving
himself a treat and translate stuff that he finds fun to translate
regardless of site priorities (after all, he is doing this work out of
the goodness of his heart).
One day, Hakan has a few hours available to do some translation work. He
checks to see if there have been any specific requests for content to be
translated into Turkish (LookForRequestsForTranslations ). He sees that
there are 3 such requests.
Hakan looks at the 3 requests and see that the 2nd one asks for a
complete page to be translated (it does not have a translation in
Turkish yet). He doesn't feel like working on small updates at the
moment, so he chooses the 2nd request. He creates a new page on the
site, and types in the translation (CreateNewTranslationOfCurrentPage
and CreateContentOfNewTranslation ). This takes him a full hour (Hakan
takes pride in the quality of his translations), and that's all he had
available so he leaves the system after that.
Two days later, Hakan has more time to put into translation work. He
sees that the first request (translating some minor changes to a page)
is still there. Moreover, he now notices that the requester had written
a note beside his request saying that this change corrected an error
that could lead to life threatening situations. So Hakan now feels
obligated to translate it, eventhough there are other more fun requests
Fortunately for him, the change that needs to be translated was done in
English and Hakan reads English very well. So he brings up a tool for
translating changes from English to Turkish. The tool shows him the
changes that have been done to the English page (in context, i.e. the
changes are embeded and highlighted within the full English text). He
reproduces those changes in the Turkish page (TranslateUpdatesToAPage ),
and saves them, tagging the two versions as being aligned with each
other (SignalEndOfTranslationTask ).
Now, there are no more pending requests for translation into Turkish,
and Hakan still has some time available (but not much). So he looks for
Turkish pages which are out of date with their sister pages in other
languages (FindOutOfDatePagesInLanguageOfInterest ). There are many, but
he chooses some that are visited often, or some that have only minor
changes that need to be translated
EstimateTranslationEffortForAParticularPage ). Hakan does a few of those
(Translate pdatesToAPage and SignalEndOfTranslationTask ) until it's
time for him to go to bed.
Some days later, Hakan comes back again and has several hours ahead of
him. But he again feels like translating whole pages, not just minor
changes. Looking at the list of translation requests, he sees that there
are none that are about translations to complete pages. So he goes
hunting for pages in English that do not have translations in Turkish
yet. There are quite a few, too many for him to do in one session. So he
chooses the one that is most frequently visited, in terms of visit in
any language version of that page (SeeWhichPagesAreMostVisited ). He
translates a few until he runs out of time.
Yet another day, Hakan logs on to the site and sees that someone has
requested for a change to a Spanish page to be translated to Turkish
(RequestForATranslation ). Hakan does not know Spanish, but he has heard
that the system provides tools that can help people translate from a
source language they can't read to a target language they can write.
Hakan has never done this before and he is intrigued. So he translates
the update from Spanish to Turkish
(TranslateUpdateFromForeignLanguageToWriteableLanguage). The system
shows him the Spanish page on the left, translated automatically into
Turkish, and with the changes highlighted in red. The quality of the
automatic translation is horrid, but it is good enough for Hakan to
understand the change that was made and reproduce it in the Turkish page
(GistUpdateToAPageInAForeignLanguage ). He then saves his translation to
the Turkish page (SignalEndOfTranslationTask ).