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

Re: How to write user stories for usability at release and sprint level

Expand Messages
  • imaginethepoet
    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
    Message 1 of 83 , May 8, 2008
      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 agile-usability@yahoogroups.com, William Pietri <william@...>
      > Desilets, Alain wrote:
      > > Not sure it makes sense to have usability as being separate from
      > > user story.
      > >
      > 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 early
      stories 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 "done
      > for polish." When a story is declared done by the team, it should
      > 100% done.
      > If you are working in a context where usability matters, then that
      > done should include making it well designed and meeting or
      > your usability goals. And for stories where usability is important,
      > people who understand usability should be part of the conversation
      > the beginning and all the way through.
      > That doesn't mean that you can't schedule future stories whose
      > goal is improving the user experience. Sometimes you figure out
      > ways only after a story has been in production a while. Sometimes
      > intentionally defer usability improvements so that you can release
      > and get feedback. Sometimes you want to ship out a relatively bare-
      > product for early adopters before you come back and make it more
      > approachable for other target audiences.
      > Even then, though, it is important that be a conscious decision,
      > usability experts participating fully.
      > William
    • 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
        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.

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