Re: How to write user stories for usability at release and sprint level
- I think you have look at the "done done" definition or acceptance
criteria and make sure your usability is included in the definition
of a stories aditional doneness. Of course, users / customers are
using the software throughout the sprint and examining the problems
with the interactions at that point.
I would not separate out the usability aspect, but sometimes it is
extremely difficulty to get usability as part of the acceptance
criterai. It depends on customer, company, etc... The end user has to
be shown the business value to including the usability as part of the
done criteria. Sometimes this means getting buy-in from the BA /
Executive team. That makes this a very challenging process.
I have found that when usability is "addressed" as a separate story
it tends to go ignored and is seen as unimportant to the overall
feature implementation. If you expereince this, the best advice I can
recommend is: Be loud and state the obvious.
"Great our application has a ton of features can anyone use it? No?
Ok great than what was the point of putting this massive set of
features into the application?
Don't be suprised if even that fails at some point. Next you should
desmonstrate in your (sprint review) or preferably thruogh the course
of the development of each story (especially as it's related to
Usability)the problems and pain points you see as a Interaction
Designer and get those things high on the priorty story back log!
I actually talk a little bit about this in my blog.
--- In firstname.lastname@example.org, William Pietri <william@...>
> Desilets, Alain wrote:
> > Not sure it makes sense to have usability as being separate from
> > user story.That
> I strongly agree with this.
> Each story is supposed to be a complete, releasable unit of work.
> doesn't mean it has every feature under the sun; often earlystories are
> very minimal. But it does mean that it should be 100% done.Not "done
> except for testing." Not "done except for bug fixing." Not "doneexcept
> for polish." When a story is declared done by the team, it shouldbe
> 100% done.100%
> If you are working in a context where usability matters, then that
> done should include making it well designed and meeting orexceeding
> your usability goals. And for stories where usability is important,from
> people who understand usability should be part of the conversation
> the beginning and all the way through.primary
> That doesn't mean that you can't schedule future stories whose
> goal is improving the user experience. Sometimes you figure outbetter
> ways only after a story has been in production a while. Sometimesyou
> intentionally defer usability improvements so that you can releaseearly
> and get feedback. Sometimes you want to ship out a relatively bare-bones
> product for early adopters before you come back and make it morewith
> approachable for other target audiences.
> Even then, though, it is important that be a conscious decision,
> usability experts participating fully.
- I'm a bit new to Agile but don't really see the problem with this
vision thing. I use the Cooper Goal-Directed Design Method.
We interview users to learn their goals and understand their tasks and
we do that up front, perhaps as a sprint rather than anything
We produce personas, from the interview data, and goals. And we
produce high level context scenarios, which start making basic
references to concepts that will exist in the design.
From the context scenarios we can almost underline the parts which
indicate user needs.
Then we take out a whiteboard pen and write a storyboard wireframe
(which Cooper used to call the Design Vision and now call in
Interaction Framework). We elaborate a bit on the design hinted at in
the context scenario and produce a key path scenario, which describes
in more detail how the user will interact with the design. This whole
exercise lets us outline the anatomy of the design and to understand
how to play it.
When we are happy with that Design Vision, we can jump into iterations
and do a bit of 'just in time' detailed design.
The Vision, is the Design Vision. It is justified through
understanding the users typical day and their typical needs. It
probably won't change much since it is quite high level.
I'm not sure where the problem is with a vision like this. perhaps,
the only drawback is that you have to do a bit of work in front of the
iterative cycles to get a good understanding of the users and what
they do to enable you to get this vision pinned down.
i'd be interested in comments on this.