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

4207Re: [agile-usability] Agile UCD Velocity Points

Expand Messages
  • William Pietri
    May 8, 2008
      Interesting question, Leina!

      How does your organization measure business value for the other stories in the queue?


      leina elgohari wrote:

      Thanks William

      That's a very valid point.

      What if the usability people wanted to dedicate an entire user story to doing usability stuff.

      From where would they get the business value given that its not a straightforward process to be able to quantify the business value where usability is concerned?

      Do you have any advice on working out the maths?



      --- On Thu, 5/8/08, William Pietri <william@...> wrote:

      From: William Pietri <william@...>
      Subject: Re: [agile-usability] Agile UCD Velocity Points
      To: agile-usability@yahoogroups.com
      Date: Thursday, May 8, 2008, 4:41 PM

      Leina wrote:
      > If the usability people are going to build in usability acceptance
      > criteria into the user stories it will no doubt add extra work.
      > Do they need to estimate that work, work out their own velocity and
      > build it into the user story?

      One of the things I see teams struggle with during agile adoption is
      going from a team with formal roles to a more collaborative team.

      In the beginning, when people are role oriented, database work is done
      by the database guys, back-end development is done by the server-side
      specialists, front-end development is done by the web people, and
      usability is done by the human factors expert. I think this is a natural
      place to start, but should be looked at as something to move away from
      over time.

      I think each estimated story should have a single estimate that
      represents the whole team's estimate, including everything it takes to
      get to 100% done. However, when scheduling stories within iterations,
      the team should be sensitive to individual overload and burnout.

      During iterations, teams should be working together in ways that provide
      some cross-training. If not enough of that is happening, explicitly
      schedule it in the course of working on stories. E.g., get together with
      the front-end people, and work out the UI together. It will take a
      while, but eventually your team will pick up some usability skills,
      allowing the basic stuff to be done by a broad range of people. Then the
      team can adjust organically to stories with different workloads, making
      the concept of a team velocity much more real.


    • Show all 13 messages in this topic