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

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

Expand Messages
  • Beth Meyer
    Hello, all; Well, I am very new to writing user stories, and my project team is not only new to agile methods in general but especially new to incorporating
    Message 1 of 83 , May 8, 2008
      Hello, all;

      Well, I am very new to writing user stories, and my project team is
      not only new to agile methods in general but especially new to
      incorporating usability. However, I found that when I tried to
      include usability criteria in the definition of Done (with a plan
      in place for getting rapid user input to validate those criteria),
      I got pushback from our resident agile expert because we can't
      estimate in the sprint planning meeting how long it will take us
      to reach the Done criterion. If the results of having users bang
      on the first prototype are, "It's great!", then we're good - but if
      the results are that it needs some significant reworking, then our
      initial estimates for how long it will take to complete the story
      are blown out of the water.

      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.

      Do you see a major issue with that, and if so, how do your teams
      estimate the story points for a user story that specifies usability
      criteria that will be determined by user testing?

      *Note: Our project is a little unique in that we are upgrading an
      existing product that is OK usability-wise except for a few problem
      areas. So we are not doing a wholesale rethinking of the UI.


      --- In agile-usability@yahoogroups.com, "imaginethepoet"
      <imaginethepoet@...> wrote:
      > I think you have look at the "done done" definition or acceptance
      > criteria and make sure your usability is included in the
      > of a stories aditional doneness. Of course, users / customers are
      > using the software throughout the sprint and examining the
      > 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
      > be shown the business value to including the usability as part of
      > 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
      > it tends to go ignored and is seen as unimportant to the overall
      > feature implementation. If you expereince this, the best advice I
      > recommend is: Be loud and state the obvious.
      > "Great our application has a ton of features can anyone use it?
      > 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
      > desmonstrate in your (sprint review) or preferably thruogh the
      > 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@>
      > wrote:
      > >
      > > Desilets, Alain wrote:
      > > > Not sure it makes sense to have usability as being separate
      > the
      > > > user story.
      > > >
      > >
      > > I strongly agree with this.
      > >
      > > Each story is supposed to be a complete, releasable unit of
      > That
      > > 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
      > except
      > > for polish." When a story is declared done by the team, it
      > be
      > > 100% done.
      > >
      > > If you are working in a context where usability matters, then
      > 100%
      > > done should include making it well designed and meeting or
      > exceeding
      > > your usability goals. And for stories where usability is
      > > people who understand usability should be part of the
      > from
      > > the beginning and all the way through.
      > >
      > > That doesn't mean that you can't schedule future stories whose
      > primary
      > > goal is improving the user experience. Sometimes you figure out
      > better
      > > ways only after a story has been in production a while.
      > you
      > > intentionally defer usability improvements so that you can
      > early
      > > and get feedback. Sometimes you want to ship out a relatively
      > bones
      > > 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,
      > with
      > > 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.