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
  • Adrian Howard
    Hi Jared, On 12 Aug 2011, at 02:16, Jared Spool wrote: [snip] ... Not a problem unique to agile. I m amazed at the number of folk who budget in time for
    Message 1 of 13 , Aug 12, 2011
      Hi Jared,

      On 12 Aug 2011, at 02:16, Jared Spool wrote:
      [snip]
      > However, many of the problems they found were outside the original scope of the project. The UX team members wanted desperately to add many of the problems to the project's backlog, but instantly found resistance from the product owners who didn't want to delay the delivery. The result was a sense from the UX folks that the product owners didn't care about a good user experience.

      Not a problem unique to agile. I'm amazed at the number of folk who budget in time for usability testing, but expect the findings can magically be integrated with no additional work :-)

      > My question is how might you have avoided this problem? I had initially suggested that the team needed more upfront definition of what is and isn't within the project's scope and a way to record outside-of-scope usability issues for future projects.
      [snip]

      I think your initial suggestion is a good one. Before I start doing user testing with a team we try and figure out what is/is not possible implementation wise. This is good for two reasons:

      1) It helps set expectations on both sides of what is going to be done with the results. So I'm not left being annoyed that my sage advice is being ignored, and the team isn't given a set of high level issues that cannot be fixed in the scope of the current release plan.

      2) It allows better targeting of the UX resources. If we know that we're not realistically have time to completely re-implement feature Foo, then we can spend more time looking at feature Bar instead - or more time teaching/facilitating good UX work elsewhere.

      In getting teams to value UX I find it *much* more effective to provide advice that can be acted on immediately so the value of that advice can be quickly seen. Once you start showing value it's much easier to get agreement on addressing larger issues.

      Having that conversation about how the usability testing can effect the end product can lead to some interesting places.

      For example it may highlight situations where the product development team needs to become more agile.

      How fixed is the release plan? Is it fixed for a good reason? Is new feature Foo really more important than fixing feature Bar? Is agreeing a release plan N months in advance helping or hindering building a better product?

      The conversation about how usability testing results fit in can rapidly become a much larger discussion about the process as a whole, the definition of done, and how features are prioritised.

      This larger conversation is useful and good - but can sometimes get in the way of addressing the short term issues that can feasibly be addressed in the context of the next couple of iterations. Especially, like your client, where you're facing a huge usability debt.

      Addressing the small issues first. Show that they help. Use that evidence as the fuel to drive addressing larger scale issues.

      Cheers,

      Adrian
      --
      http://quietstars.com adrianh@... twitter.com/adrianh
      t. +44 (0)7752 419080 skype adrianjohnhoward del.icio.us/adrianh
    • Adrian Howard
      On 12 Aug 2011, at 03:05, Austin Govella wrote: [snip] ... [snip] This is really good advice - and is often one that is easy for developers to understand since
      Message 2 of 13 , Aug 12, 2011
        On 12 Aug 2011, at 03:05, Austin Govella wrote:
        [snip]
        > 3. The Shelf. Stick the fixes "on the shelf". Next time you're developing in that area of the product, pull them down and roll the changes into adjacent work. (A lot of changes are absolutely negligible if a developer is already in that neighborhood of the code.)
        [snip]

        This is really good advice - and is often one that is easy for developers to understand since it's the same approach many teams take when addressing technical debt issues.

        Cheers,

        Adrian
        --
        http://quietstars.com adrianh@... twitter.com/adrianh
        t. +44 (0)7752 419080 skype adrianjohnhoward del.icio.us/adrianh
      • Adrian Howard
        ... 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
        Message 3 of 13 , Aug 12, 2011
          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
        • 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 4 of 13 , Aug 12, 2011
            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 5 of 13 , Aug 12, 2011
              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.