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

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

Expand Messages
  • Adrian Howard
    Aug 12, 2011
    • 0 Attachment
      Hi Jared,

      On 12 Aug 2011, at 02:16, Jared Spool wrote:
      > 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.

      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.


      http://quietstars.com adrianh@... twitter.com/adrianh
      t. +44 (0)7752 419080 skype adrianjohnhoward del.icio.us/adrianh
    • Show all 13 messages in this topic