Loading ...
Sorry, an error occurred while loading the content.

Re: [agile-usability] Re: How to write user stories for usability at release and sprint level

Expand Messages
  • Jim Ungar
    ... work*, 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
    Message 1 of 83 , May 8, 2008
    • 0 Attachment
      Beth wrote:
      >>So, with regard to the features that really need some usability
      work*, 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.


      Jim
    • carl myhill
      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
      Message 83 of 83 , Jun 2, 2008
      • 0 Attachment
        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
        iterative.

        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.

        Carl
      Your message has been successfully submitted and would be delivered to recipients shortly.