Re: [agile-usability] Re: How to write user stories for usability at release and sprint level
- Beth wrote:
>>So, with regard to the features that really need some usabilitywork*, my response was to have one of the Done criteria be that user
evaluation has been performed, but not that specific usability
criteria had to be met for that iteration to be Done. If we find
issues in user evaluation that require significant reworking, we can
craft a user story around the specific problem that we found in
testing for the next iteration.>>
I agree with your solution and would suggest that those with usability testing experience on the team would be in a position to estimate story points for testing. The level of effort required to determine if specific usability criteria have been met is fairly easy to estimate.
Our developers take much the same approach when estimating their code testing efforts. They cannot know what bugs they will find, so they estimate the test, and sometimes pad that number to provide room for a quick fix. Show stoppers can upset the estimation apple cart, but agile is designed for those unforeseen events, anyway.
- 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.