4207Re: [agile-usability] Agile UCD Velocity Points
- May 8, 2008
Interesting question, Leina!
How does your organization measure business value for the other stories in the queue?
leina elgohari wrote:
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
Date: Thursday, May 8, 2008, 4:41 PM
> 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
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.
- << Previous post in topic Next post in topic >>