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

Re: [agile-usability] How do you avoid scope creep when integrating user research into the scrums?

Expand Messages
  • Jeff Wall
    Adrian, That is a good point about the Definition of Done At the beginning of our project we wrote down our teams Definition of Done and posted it on the
    Message 1 of 13 , Aug 12, 2011
    • 0 Attachment
      Adrian,

      That is a good point about the "Definition of Done"

      At the beginning of our project we wrote down our teams Definition of Done and posted it on the wall where we do our stand-ups so we could see it every day.

      It has about 10 items on it.  Some for developers (i.e. full unit test coverage), some for QA, and UI/UX.

      It is amazing how difficult it is to complete an iteration successfully, with a high degree of quality and usability when you have a documented set of items that define "Done."

      I highly recommend this practice.

      Jeff
       

      On Fri, Aug 12, 2011 at 6:05 AM, Adrian Howard <adrianh@...> wrote:
       


      On 12 Aug 2011, at 03:53, Yaniv Nord wrote:

      > It's virtually impossible to do usability testing in the context of a sprint.
      >
      > By the time your story is pointed, commitment line set, and sprint has
      > started, you should have your ux work 95% stable.
      >
      > That means your work (research, design, testing, iteration, etc) needs
      > to happen up front, running at least one sprint ahead, preferably two
      > or three. I have yet to talk to anyone doing ux in an serious agile
      > environment that's able to iterate design in any meaningful way during
      > a sprint.

      I think that depends on the kind of usability testing that you're doing, and the issues that your product development process is leaving for you to discover mid-sprint.

      There are people successfully doing in-sprint usability testing - even multiple sets of usability tests during a single sprint (see http://is.gd/h2YpDq for example).

      The key difference I see with teams that have that approach are:

      * they've got a product development process that's leaving them with few, if any, large usability issues to discover at that late stage

      * they have a very clear definition of "done" that the whole team values so they can quickly decide whether an issue needs to be addressed immediately or postponed to a later iteration




      --
      Jeffrey M. Wall
      Sr. Business Systems Analyst
      919.355.8312
      jmwall67@...
    • Michael James
      Yeah, I m also not buying that it s virtually impossible to do usability testing during the Sprint, since I ve seen people doing it. It requires different
      Message 2 of 13 , Aug 12, 2011
      • 0 Attachment
        Yeah, I'm also not buying that it's virtually impossible to do usability testing during the Sprint, since I've seen people doing it.  It requires different habits that will initially feel inefficient, and drives us toward different technologies. But we already knew that was part of the Agile pathway. 

        Users are becoming less tolerant of usability problems, so we need to discover these early, like all other defects. 

        On Aug 12, 2011, at 3:05 AM, Adrian Howard <adrianh@...> wrote:

         


        On 12 Aug 2011, at 03:53, Yaniv Nord wrote:

        > It's virtually impossible to do usability testing in the context of a sprint.
        >
        > By the time your story is pointed, commitment line set, and sprint has
        > started, you should have your ux work 95% stable.
        >
        > That means your work (research, design, testing, iteration, etc) needs
        > to happen up front, running at least one sprint ahead, preferably two
        > or three. I have yet to talk to anyone doing ux in an serious agile
        > environment that's able to iterate design in any meaningful way during
        > a sprint.

        I think that depends on the kind of usability testing that you're doing, and the issues that your product development process is leaving for you to discover mid-sprint.

        There are people successfully doing in-sprint usability testing - even multiple sets of usability tests during a single sprint (see http://is.gd/h2YpDq for example).

        The key difference I see with teams that have that approach are:

        * they've got a product development process that's leaving them with few, if any, large usability issues to discover at that late stage

        * they have a very clear definition of "done" that the whole team values so they can quickly decide whether an issue needs to be addressed immediately or postponed to a later iteration

        Cheers,

        Adrian
        --
        http://quietstars.com adrianh@... twitter.com/adrianh
        t. +44 (0)7752 419080 skype adrianjohnhoward del.icio.us/adrianh

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