Stefan: You'd probably find this topic more productive on a different
list, but there are some clear precedents for what you seek.

For example, User Interface Engineering (UIE), has done some nice high
profile work across studies to show that longer links tend to perform
better. IIRC, they correlated task success with link length across a
bunch of studies. Read more at
http://www.uie.com/reports/scent_of_information/

In general, you're looking at "between subjects design" and a very
large error component.  You'll need a lot of data.

The UIE example shows how you can apply a method of reducing each
study to a datapoint and then analyzing across studies as an experiment.

hth,
Andy Edmonds
http://surfmind.com

--- In agile-usability@yahoogroups.com, "Stefan Wobben [Concept7]"
<stefan@...> wrote:
...
> I wonder if there is a way that i can gather data on a meta-level so
in the end we are able to perform statitic analyses. The problem
however is we there are different websites, different tasks and
different participants.
...
> I can't believe there isn't any other possibility. Does anybody has
ideas? and/or interested in performing such type of studies?

> On Sun, 14 Sep 2008 12:29:01 -0400, John wrote:

> Agreed. What becomes frustrating is when someone in the business
> believes they know what the right answer is to their business
> need,and objects to being asked 'why do you want that feature?'.

I've been lurking for quite a while and this thread has finally
compelled me to respond.

The product owners and the users frequently ask for functions that
they really don't need. I always ask them what the real issue
is...what are they trying to fix with the solution they're
proposing. If would I ask them why they wanted it, it would
instantly put them on the defensive. By digging into what the
problems are, they feel like they're involved in the better solution.

Here's an example: We have an ordering feature that we handle
through a wizard. If the user leaves the wizard, they lose their
progress. (We have an architecture that makes it difficult to save
progress.) The business came to us and asked us to allow them to
save and leave the wizard. I asked them what operations they needed
to perform when they were needing to save the wizard. They listed
three things that were much easier to integrate into the wizard than
the save function.

As usability practitioners, it's our role to listen to what the
business wants, observe what the users need (not ask them), and then
propose the best design to the stakeholders.

Thank you Andy.
Thank you James.

I've ordered scent of information and statistics in medicine so i can some
research on the
topic.

As the remark 'you need lots of data' well thats what we have :)

I'll keep you updated about my progress.

On Oct 1, 2008, at 4:09 PM, Stefan wrote:

> I've ordered scent of information and statistics in medicine so i
> can some research on the
> topic.

I hope you won't be disappointed with the Scent of Information report.
It doesn't really go into our methodology. That's not why we created it.

What you're trying to do is *really* hard and will take huge amounts
of preparation and some massively impressive statistics horsepower. I
know because we've tried multiple times and only managed to pull it
off some of the time.

There are scaling and ground issues. Ground issues are about
connecting the independent data collection points to a common element,
so you can say that these measures are talking about the same thing.
Scaling issues are about ensuring that Good/Bad in one scale mean the
same as Good/Bad in another scale.

This is very heavy duty science you're trying to do. I'm betting, if
you want to do it well, it will triple-to-quintuple your research costs.

I'm betting that's why you've not found a lot of resources on it. You
need a deep pocket to make it really work.

Jared

Jared M. Spool
User Interface Engineering
510 Turnpike St., Suite 102, North Andover, MA 01845
e: jspool@... p: +1 978 327 5561
http://uie.com  Blog: http://uie.com/brainsparks

Scott,
Lots of user observation before the recommendation and after the
recommendation confirmed that the items we implemented were the
right items. It's a call center application, so user research is
pretty cheap.
Kathy

--- In agile-usability@yahoogroups.com, Scott Preece <sepreece@...>
wrote:
>
> Hi, Kathy,
>
> The notion of always trying to understand the why before
committing to the how is great. I have a little bit of concern about
your example, though. Bending the user experience to make it easier
to implement is a dangerous path; you need to be very sure that
you're not making the user's job harder or more difficult to
understand. It may, of course, be that the specifics of the example
didn't have any issues, but it's a situation where you would
probably want to test the tasks with users to make sure the new
capabilities were clear and didn't make it harder for them to
complete the task the wizard supported.
>
> Also, you wouldn't want to go down this route if the added
capabilities were things you would ever want to do when the wizarded
process wasn't going on. That is, if they're things you might want
to do at arbitrary times, building them into the wizard would
potentially mean you needed to implement all or part of them more
than once to make them available in different places.
>
> [Obviously, I have no idea of the specifics of your applicatio, so
these are general thoughts that may very well not apply here; in any
case, figuring out what the customer needs to accomplish is, as you
said, central to figuring out the best way to do it.]
>
> regards,
> scott
>
>
>
> ----- Original Message ----
> From: Kathy Glur <kaglur@...>
> To: agile-usability@yahoogroups.com
> Sent: Wednesday, October 1, 2008 8:33:35 AM
> Subject: [agile-usability] Re: The user is always right
>
>
> > On Sun, 14 Sep 2008 12:29:01 -0400, John wrote:
>
> > Agreed. What becomes frustrating is when someone in the business
> > believes they know what the right answer is to their business
> > need,and objects to being asked 'why do you want that feature?'.
>
> I've been lurking for quite a while and this thread has finally
> compelled me to respond.
>
> The product owners and the users frequently ask for functions that
> they really don't need. I always ask them what the real issue
> is...what are they trying to fix with the solution they're
> proposing. If would I ask them why they wanted it, it would
> instantly put them on the defensive. By digging into what the
> problems are, they feel like they're involved in the better
solution.
>
> Here's an example: We have an ordering feature that we handle
> through a wizard. If the user leaves the wizard, they lose their
> progress. (We have an architecture that makes it difficult to save
> progress.) The business came to us and asked us to allow them to
> save and leave the wizard. I asked them what operations they
needed
> to perform when they were needing to save the wizard. They listed
> three things that were much easier to integrate into the wizard
than
> the save function.
>
> As usability practitioners, it's our role to listen to what the
> business wants, observe what the users need (not ask them), and
then
> propose the best design to the stakeholders.
>

The Crux of my question:
SCRUM states that the product owner has to represent all stakeholders
and be empowered to make decisions in order to move the team ahead
quickly. How can that person do that on UE issues if they do not have
the appropriate background? For the UE person on a team, when is
external feedback from stakeholders suggestion vs. instruction?

Context:
I am the UE Lead in a company with 6 concurrent teams working on
different projects which may be separate products or parts of the same
product. It is a relatively young start-up with a team of mostly new
people and we are only a few months into our adoption of agile. I am
on no individual team, so qualify as a chicken in agile terms.

I would define one of my responsibilities as keeping design
consistency across the product. Design sensibility is not something
easily captured in requirements, so I find it is hard for the product
owner to represent me in the decision-making process for the team.

There is a UE practitioner on the team and that person solicits
feedback regularly. However, it is not clear whether external feedback
should be taken as suggestion or instruction from certain stakeholders
(myself, marketing, etc.). The product owner is new to agile and new
to UE practice and does not have the experience or confidence to make
definitive decisions on these issues.

How have others dealt with this? Have there been instances of
ownership/signoff that exist outside of the scrum team?

Caveat: I know that user testing would help with this and we are doing
much less than we should and working on doing more.

Your feedback is greatly appreciated.

jer

Hi, Jeremy. Welcome to the group, and thanks for posting such a well
thought out question.


Jeremy K wrote:
> I would define one of my responsibilities as keeping design
> consistency across the product. Design sensibility is not something
> easily captured in requirements, so I find it is hard for the product
> owner to represent me in the decision-making process for the team.
>
> There is a UE practitioner on the team and that person solicits
> feedback regularly. However, it is not clear whether external feedback
> should be taken as suggestion or instruction from certain stakeholders
> (myself, marketing, etc.). The product owner is new to agile and new
> to UE practice and does not have the experience or confidence to make
> definitive decisions on these issues.
>
> How have others dealt with this? Have there been instances of
> ownership/signoff that exist outside of the scrum team?
>

As far as I know, the only way for a product owner to learn to make good
decisions is to make them frequently, get plenty of feedback, and pay
attention to the results. So I'd look to provide a fair bit of support
in helping them understand the big-picture value of the things you're
advocating for, both through pre-decision advice and post-decision data.

The teams that I see working well have people with design sensibilities
frequently or continually present as decisions get made. That includes
the big decisions, like what goes into a  release or an iteration.
There, having a senior designer present is a big help. And it includes
the little ones, where I see visual and/or interface designers
physically near or working directly with developers, and reviewing work
frequently.

As far as coordinating the efforts of multiple teams, I see that happen
mainly casually; designers show each other work in progress frequently,
getting feedback and resolving differences. I also see occasional formal
efforts to keep design consistent, where updating to a new visual style
or interaction approach ends up in the queue for each team. And I also
see good success with style guides, so that developers have a single
place to turn to when they wonder what the right design approach is.

Hoping that helps,

William

> SCRUM states that the product owner has to represent all stakeholders
> and be empowered to make decisions in order to move the team ahead
> quickly. How can that person do that on UE issues if they do not have
> the appropriate background?

Effective Product Owners (POs) should draw on feedback from the
experts in order to make their decisions, and UE leads tend to be
critical sources of input (often the single most influential).  Rarely
will a PO actually possess enough domain expertise to make decisions
from the business level down to the user interaction one, so they use
the experts to A) generate options for them to consider, and B)
present the relative pros/cons of each, so that they can make a
rational choice about where and how to best invest.

For the UE person on a team, when is
> external feedback from stakeholders suggestion vs. instruction?

Feedback from stakeholders is always instruction, from my perspective;
it's input into a decision, variously informing a team what is
important to users, what designs might best address certain problems,
etc.  POs must balance this sort of input across stakeholders,
eventually deciding what to build in a manner that best fulfills their
project's business case (maximizing cost/benefit).

If "design sensibilities" are the key thing you're having trouble
getting addressed properly, your most effective approach is probably
going to be placing yourself in a position to facilitate design work
across teams.  The "Design Studio" approach described here is one idea
for how to approach this: http://submissions.agile2008.org/node/4391

You could also offer to help the customer team (PO and whomever else
helps to write initial requirements) in formulating so-called
Acceptance Criteria for individual requests (User Stories or whatever
else you might be using) that capture usability criteria ("must
provide visual feedback confirming submission," "must respond in <2
seconds," etc).

How are you currently integrated into the process?  Most UEs
essentially straddle the line between the PO side (giving advice on
what features will delight users or stimulate most demand) and the
Team (assisting in implementing these features in the most
efficient/effective/appealing way)...

BTW, I'm a Certified Scrum Trainer, for what it's worth.  Hope this
helps...

Arlen

--- In agile-usability@yahoogroups.com, "Jeremy K" <jer@...> wrote:
>
> The Crux of my question:

>
> Context:
> I am the UE Lead in a company with 6 concurrent teams working on
> different projects which may be separate products or parts of the same
> product. It is a relatively young start-up with a team of mostly new
> people and we are only a few months into our adoption of agile. I am
> on no individual team, so qualify as a chicken in agile terms.
>
> I would define one of my responsibilities as keeping design
> consistency across the product. Design sensibility is not something
> easily captured in requirements, so I find it is hard for the product
> owner to represent me in the decision-making process for the team.
>
> There is a UE practitioner on the team and that person solicits
> feedback regularly. However, it is not clear whether external feedback
> should be taken as suggestion or instruction from certain stakeholders
> (myself, marketing, etc.). The product owner is new to agile and new
> to UE practice and does not have the experience or confidence to make
> definitive decisions on these issues.
>
> How have others dealt with this? Have there been instances of
> ownership/signoff that exist outside of the scrum team?
>
> Caveat: I know that user testing would help with this and we are doing
> much less than we should and working on doing more.
>
> Your feedback is greatly appreciated.
>
> jer
>

Hello All
An example of the Your / My conflict (if there a conflict) can be seen
on Amazon.If you select the "Your Account" link it takes you to a
section sub-headed "Where's My Stuff". However, below it there are
links such as "Change your name", "Forgot your Password?" etc.

Do people think think it that:
(1) If "Your" is used then it should be  consistent across all links?
(2) or it is possible to have "Your" as the parent link and "My" as
child links

Is there a conflict within Amazon or does it make perfect sense?

Thanks, Lee

Whichever you choose... be consistent.

Or, simply remove the "my/your" perspective confusion and leave it as
"Account"

"Settings" instead of "My Settings"
"Account" instead of "My Account"

Regarding amazon... Personal Information:

     * Change Your Name, E-mail Address, or Password
     * Update Your Communication Preferences
     * Forgot Your Password?
     * Manage Your Address Book
     * View or Change Your 1-Click Settings


You could easily drop "Your" in all cases...

I'm guessing the intent was to make it more "personal."

jon


blog: TechnicalDebt.com <http://technicaldebt.com>
      View Jon Kern's profile <http://www.linkedin.com/in/jonkern>


Tim Wright said the following on 10/4/08 5:23 PM:
>
> This is something that's often confused me - the my/your thing.
>
> However, it's confused me because I don't understand why people want
> to have links or features called "my account". It's like going into a
> bank and the teller saying "would you like to see my account?"
>
> If we view the interaction between the computer and the user as a
> conversation, then surely the computer should always say "your" if we
> want to give the impression that the user "owns" the thing.
>
> However, I am also wondering if anyoe has actually done any research
> into the difference of naming a shopping basket "my shopping basket"
> instead of "your shopping basket" (or some other my/your thing).
>
> Tim
>
> On Sun, Oct 5, 2008 at 9:21 AM, Leina <leina_elgohari@...
> <mailto:leina_elgohari@...>> wrote:
>
>     Hello All
>     An example of the Your / My conflict (if there a conflict) can be
>     seen
>     on Amazon.If you select the "Your Account" link it takes you to a
>     section sub-headed "Where's My Stuff". However, below it there are
>     links such as "Change your name", "Forgot your Password?" etc.
>
>     Do people think think it that:
>     (1) If "Your" is used then it should be consistent across all links?
>     (2) or it is possible to have "Your" as the parent link and "My" as
>     child links
>
>     Is there a conflict within Amazon or does it make perfect sense?
>
>     Thanks, Lee
>
>
>
>
> --
> Kei te kōrero tiki au. Kei te kōrero tiki koe. Ka kōrero tiki tāua.
> Kōrero ai tiki tāua.
>

--- In agile-usability@yahoogroups.com, "Leina" <leina_elgohari@...>
wrote:
>
> Hello All
> An example of the Your / My conflict (if there a conflict) can be
seen
> on Amazon.If you select the "Your Account" link it takes you to a
> section sub-headed "Where's My Stuff". However, below it there are
> links such as "Change your name", "Forgot your Password?" etc.
>
> Do people think think it that:
> (1) If "Your" is used then it should be  consistent across all
links?
> (2) or it is possible to have "Your" as the parent link and "My" as
> child links
>
> Is there a conflict within Amazon or does it make perfect sense?
>
> Thanks, Lee
>

Nice question - I hadn't particularly noticed it, all the times
I've used Amazon.

I like the shift, personally --- all the consistent versions
seem stilted to me.

on a book page, "Your account" indicates it's "over there".
Once I'm there, I'm not "over there" any more, I'm "here",
so "Where's my stuff?" is exactly what's on my mind.

Interesting question (again). thanks for raising it.

(p.s. beware of over-consistency:
"Foolish consistency is the hobgoblin of small minds"
Emerson
)

Hi,

As a product owner, do you have advice on illuminating or correcting teams that
have a
tendency to low-ball their overall expected velocity and/or throw bad (high)
estimates at
work they don't want to do?

I am working on a project with all contract developers, some on and some
offshore.  This
team has been working together since the beginning of the year so I feel that I
have come
to understand them very well.  Also I have worked with some individuals on other
projects
over the past couple years and have gotten to know them & their behaviors well.

It has become clear through many conversations that they like to work at a
certain
comfortable velocity and will do anything to maintain it.  A short while ago we
released a
product and have entered a new year long phase of enhancements -  6 week
releases to
further build out the product.  It was decided that the team should reconsider
their
velocity and ended up planning for a much lower velocity going forward.  I agree
with
some of the reasons cited, such as personal and national holidays.  But in
general -  I am
confident that expectaitions are significantly lower that what they should be. 
I would be
fine with as long as if/when they finish work early they continue to pick up
more work.
This is not the case.  Moreover, I believe they intentionally discouraged doing
more work
because they will only estimate sprint stories until they reach their expected
velocity and
we only pick up work that has been estimated?

Further, if there is a known feature that a particular dev does not like he will
first
challenge the heck out of it's value.  In general I am fine with this, kicking
the tires is
good.  However when the value to the user is demonstrated, I am guaranteed in
the
estimation and planning meetings he will continue to throw high numbers, just
change his
argument.  On our team, we always plan with the highest number thrown.  It's
obvious his
are high because on average he is lower than others and usually when he throws a
high
number relative to the others it is notably high.  Typically this has the effect
of
discouraging the sponsor to prioritize this work and/or we are forced to look
for less
optimal experiences that are technically easier to develop.

I feel like this team is steering to product not to deliver value but to
maintain comfort.

Suggestions?
fb

Wow. I am sure it is hard to describe an entire team culture and
experience in an email. But it sure sounds like you have quite a fun
challenge. Gulp.

Developers challenging the value of a business request?
- maybe your requests are too solution-oriented (versus business) and
the developer has a valid point?
- maybe the developer needs to be sat down and told to fly right or get out?
- somewhere in between?

Plan for a lower velocity?
- because you routinely over-chose issues and always have 50% completion
rates?
- because you worked them to the bone, requiring 60 hour weeks for 12
months and they are burnt out?

Why do you think they are "low-balling" their estimates? How do you
measure whether something seems out of whack?

Let's assume you have a dysfunctional team... you could
- raise it in a team setting and have a group discussion to get to the
bottom of the issue
- bring in some new blood that you trust to be exceedingly competent
- bring in an outside observer to go through the various "sides" and
gather intel
   (I always love conducting these sorts of "software therapy" sessions.)
- fire/reassign one or two posers and see if the others snap to attention

Could you be misconstruing their "push back?" Maybe it is justified
because of aspects they have not been able to properly share with you?

Maybe you could try to do more group estimating... so others might
challenge estimation assumptions -- not just you.

All I can say is that what you experience sounds real. I wouldn't put up
with it. I would either figure out if it was me, the business, the
process, or the developers -- and try to resolve the issues. Otherwise,
nobody is having that much fun...

jon


blog: TechnicalDebt.com <http://technicaldebt.com>
      View Jon Kern's profile <http://www.linkedin.com/in/jonkern>


faithbolliger.sanfran said the following on 10/6/08 2:47 PM:
>
> Hi,
>
> As a product owner, do you have advice on illuminating or correcting
> teams that have a
> tendency to low-ball their overall expected velocity and/or throw bad
> (high) estimates at
> work they don't want to do?
>
> I am working on a project with all contract developers, some on and
> some offshore. This
> team has been working together since the beginning of the year so I
> feel that I have come
> to understand them very well. Also I have worked with some individuals
> on other projects
> over the past couple years and have gotten to know them & their
> behaviors well.
>
> It has become clear through many conversations that they like to work
> at a certain
> comfortable velocity and will do anything to maintain it. A short
> while ago we released a
> product and have entered a new year long phase of enhancements - 6
> week releases to
> further build out the product. It was decided that the team should
> reconsider their
> velocity and ended up planning for a much lower velocity going
> forward. I agree with
> some of the reasons cited, such as personal and national holidays. But
> in general - I am
> confident that expectaitions are significantly lower that what they
> should be. I would be
> fine with as long as if/when they finish work early they continue to
> pick up more work.
> This is not the case. Moreover, I believe they intentionally
> discouraged doing more work
> because they will only estimate sprint stories until they reach their
> expected velocity and
> we only pick up work that has been estimated?
>
> Further, if there is a known feature that a particular dev does not
> like he will first
> challenge the heck out of it's value. In general I am fine with this,
> kicking the tires is
> good. However when the value to the user is demonstrated, I am
> guaranteed in the
> estimation and planning meetings he will continue to throw high
> numbers, just change his
> argument. On our team, we always plan with the highest number thrown.
> It's obvious his
> are high because on average he is lower than others and usually when
> he throws a high
> number relative to the others it is notably high. Typically this has
> the effect of
> discouraging the sponsor to prioritize this work and/or we are forced
> to look for less
> optimal experiences that are technically easier to develop.
>
> I feel like this team is steering to product not to deliver value but
> to maintain comfort.
>
> Suggestions?
> fb
>
>

Hi, Faith! Good to hear from you. Let me answer your two questions in
separate posts.

faithbolliger.sanfran wrote:
> Further, if there is a known feature that a particular dev does not like he
will first
> challenge the heck out of it's value.  In general I am fine with this, kicking
the tires is
> good.  However when the value to the user is demonstrated, I am guaranteed in
the
> estimation and planning meetings he will continue to throw high numbers, just
change his
> argument.  On our team, we always plan with the highest number thrown.  It's
obvious his
> are high because on average he is lower than others and usually when he throws
a high
> number relative to the others it is notably high.
>

I think the bad estimates should be pretty easy to fix. There I'd use
one of the Delphi method variants:

     http://en.wikipedia.org/wiki/Delphi_method

The one I normally use is Planning Poker:

     http://www.planningpoker.com/detail.html

In particular, I'd require that the team come to consensus on an
estimate. If after a few rounds they can't, then have them explicitly
identify the core of the disagreement, and give them explicit research
time to resolve the difference. If everybody has to agree, they'll
challenge one another's estimates, and I'm sure you won't be the only
one to catch onto this pattern.


William

faithbolliger.sanfran wrote:
> [...] do you have advice on illuminating or correcting teams that have a
> tendency to low-ball their overall expected velocity [...]



I'm sure there are a lot of approaches to this, but here are the ones
that occur to me. I'm sure there will be plenty of answers here, but I
can think of six actions to take:


The first thing I'd look at is the physical arrangement of the people.
Put the product manager(s) and the developers (at least the local ones)
all in the same physical space. Everybody should be able to see
everybody else, and be able to get attention with little more than a
wave or a slightly raised voice.

Then I'd consider shifting to using relative estimates and Yesterday's
Weather as a technique for deciding how much work to take on. Keep an
estimated backlog of at least two iterations worth of work, and feel
free to ask for more estimates as needed to have a clear plan.

Third, I'd use short iterations. With a six-week release cycle, I'd go
with one- or two-week iterations. Preferably one.

Fourth, I'd look at why they might be sandbagging. That can be an
adaptive behavior in many circumstances. If they are in one of them, you
have to fix that first. And if they just picked the habit up elsewhere,
they may need support in unlearning that.

Fifth, consider whether business-side expectations for the team's
productivity are too high. Maybe 80% of the teams I evaluate have a
business-side fear that developers aren't productive enough, and the
number one response to that is to get people to work more hours. This is
rarely effective, and usually counterproductive, sometimes drastically so.

And lastly, find ways to get developers to share your motivations. If
they're doing work just because somebody tells them to, they won't be
fully engaged. Instead, get them interested in solving the problems you
want to solve. Help them to care about the things you care about. Then
they'll be looking for ways to be more productive on their own, without
external prodding.


Feel free to ask if you'd like more detail on any of these.


William

[Apologies for any duplication]

Greetings,

The User Interface 13 Conference is next week and I wanted you to have
a chance to save $1000 by registering now and avoiding the walk-in
price. If you've thought about signing up, this is the time.

Sessions are filling up and we want you to get the latest insights on
today's design techniques. On-line registration ends tomorrow, October
7. After Tuesday, we can only accept in-person registrations at the
walk-in rate. If you register now, you can still register for $2890
for the full conference or $875 for a single day.

That means you need to register now and save $1000 at http://www.uiconf.com

Don't miss this final opportunity to attend 4 days filled with
insights from the field's greatest design and usability experts. No
where else can you get these in-depth, full-day seminars:

+ Scott Berkun - Implementing Innovation
+ Dana Chisnell - Discount Usability Testing
+ Andrew Crow and Peter Merholz - Product Design Strategies
+ Kim Goodwin - Interaction Design
+ Jeremy Keith - Designing with Ajax
+ Donna (Maurer) Spencer - Information Architecture Foundations
+ Jeff Patton - Merging User Experience with Agile Development
+ Christine Perfetti - Product Usability Survival Techniques
+ Jared Spool (that's me!) - New Perspectives in UX Design
+ Luke Wroblewski - Effective Visual Design

Special Offer: I've arrange for Agile-Usability list readers to
receive a special discount. Use the promotion code UIE when you
register and receive $30 off of each day's price.

Hope to see you at the conference,

Jared M. Spool

p.s. Remember, use the UIE promotion code to get an additional $30 off
of each day's price when you register at http://uiconf.com

Fabulous answers, William --- much better than I could have
come up with!
  - cheers -
Alistair

William Pietri wrote:

[snip]

> Fifth, consider whether business-side expectations for the team's
> productivity are too high. Maybe 80% of the teams I evaluate have a
> business-side fear that developers aren't productive enough, and the
> number one response to that is to get people to work more hours. This is
> rarely effective, and usually counterproductive, sometimes drastically so.
>

At one client, the effect of having the business people co-located with
the developers resulted in a business analyst commenting on just how
much work went into implementing a single story.  She knew there was
work, but when the developers enumerated the tasks required she was
quite surprised at just how much.

Yet another reason to co-locate - TRUST! :)

Dave Rooney
Mayford Technologies
"Helping you become AGILE... to SURVIVE and THRIVE!"
http://www.mayford.ca
http://practicalagility.blogspot.com

Hi William
Thanks for your thoughtfulness.

You said:
> I think the bad estimates should be pretty easy to fix. There I'd use
> one of the Delphi method variants:
>
>     http://en.wikipedia.org/wiki/Delphi_method
>
> The one I normally use is Planning Poker:
>
>     http://www.planningpoker.com/detail.html
>
> In particular, I'd require that the team come to consensus on an
> estimate. If after a few rounds they can't, then have them explicitly
> identify the core of the disagreement, and give them explicit research
> time to resolve the difference. If everybody has to agree, they'll
> challenge one another's estimates, and I'm sure you won't be the only
> one to catch onto this pattern.

We do use planning poker, although the team does not like Fibonacci count and
have
settled on a system of .5, 1, 2, 3, 4, 5

On a side note:  I continuously struggle to understand this in terms of real
time, it's total
felt experience for me.   Particularly towards the end of the release when there
are scraps
of work to be done I feel as if our units of measurement are unhelpful.  My lead
tech will
talk about the need to give each individual story a measurement even if it
doesn't seem
worthy of say .5 because the sponsor needs to know there is a "cost".

This perspective of everything having a cost, feels more like stick than carrot
(value).

Back to issue at hand:  So the dev team collectively throws estimates in our
planning
sessions, but as a rule of thumb we take the highest estimate.  I do see devs
challenge
each other occasionally but not often.  In cases of one specific tech lead, if
this person
doesn't like a story he will continue to throw high numbers.  I have noticed a
pattern that
kills further discussion, the dev will say "well it still think there is
complexity we aren't
seeing and therefore I am not comfortable with anything lower than X pts".

I would like to change this rule of thumb that we go with the highest estimate. 
Do others
have this policy?

fb

William - More great feedback on co-location, sprint cycle, hours, business
expectations
and shared team goals/motivation.

Unfortunately our teams are not co-located, we are in 4 different locations. 
And there is
no actual daily overlap between 2 of those locations, except for sprint
planning.

We are on a 2 week sprint cycle, we used to do 1 week sprints which I liked but
the devs
felt it required too much work to get build stable, too much time required to
prep for the
demo and hence we had loads of hangover.  To some degree we have less hangover. 
And
we have worked hard to get the team to understand the demos need not be so
formal, etc.

The devs are working 40 hours if not less.  We are a team of outsourced and
offshore
partners plus some onshore distributed contractors.  I know the contractors have
other
clients and am confident this is some of the drain on velocity at times.  I have
traveled to
work at our offshore partners location and know they keep 40 hours plus time
during the
day is playful.  I don't think we are overworking them.

Business expectations are probably misaligned.  Although after 9 months now with
this
team, expectations have been significantly lowered.  In my opinion, to the
detriment of the
team.

How do others get outsourced, offshore, distributed teams to motivate?  I could
get better
at motivating!

What is the success rate for a distributed, outsourced team models?

fb

--- In agile-usability@yahoogroups.com, "faithbolliger.sanfran"
<faith.bolliger.ny@...> wrote:
>
>

> On a side note:  I continuously struggle to understand this in
terms of real time, it's total
> felt experience for me.   Particularly towards the end of the
release when there are scraps
> of work to be done I feel as if our units of measurement are
unhelpful.  My lead tech will
> talk about the need to give each individual story a measurement
even if it doesn't seem
> worthy of say .5 because the sponsor needs to know there is
a "cost".
>

Everything that takes time to do, does have a cost.  I'm guessing
these things you call "scraps of work" are tasks necessary to
get "release-ready" but maybe task lines are being drawn too finely
in order to have something that looks like a "story." If so, then
perhaps certain things could be grouped together under traditional
PMO-sounding tags so that they have more weight and visibility.
Without hard examples of these things you call "scraps" I'm not sure.
Maybe even some old-fasioned bug logging and tracking would resolve
it.


> This perspective of everything having a cost, feels more like stick
than carrot (value).
>
> Back to issue at hand:  So the dev team collectively throws
estimates in our planning
> sessions, but as a rule of thumb we take the highest estimate.  I
do see devs challenge
> each other occasionally but not often.  In cases of one specific
tech lead, if this person
> doesn't like a story he will continue to throw high numbers.  I
have noticed a pattern that
> kills further discussion, the dev will say "well it still think
there is complexity we aren't
> seeing and therefore I am not comfortable with anything lower than
X pts".
>
> I would like to change this rule of thumb that we go with the
highest estimate.  Do others have this policy?
>
> fb
>

We don't go with the highest estimate. We go with the consensus or
most frequent estimate. That means we have a discussion about the
extremes. Can your tech lead get more specific, in a general way,
about his/her concerns? That is, can they enumerate aspects of the
card and relate them to previous examples or projects where surprises
happened? Perhps a trained facilitator could help with that.

And is it important that they get more specific?  What I mean is, if
the track record for every card where they've voted high has
generally proven to have hidden complexity, then as a member of the
team, I am going to stop niggling over every card where this happens
and vote with the expert knowing that in time I'll experience what
he/she suspected and be better able to smell the smells and
articulate the concerns myself.

A lot of times, teams that have been together long function this way
because it's just more efficient to stop talking and start working.

Hi William Thanks for your thoughtfulness. You said:

I think the bad estimates should be pretty easy to fix. There I'd use one of the Delphi method variants:
http://en.wikipedia.org/wiki/Delphi_method
The one I normally use is Planning Poker:
http://www.planningpoker.com/detail.html
In particular, I'd require that the team come to consensus on an estimate. If after a few rounds they can't, then have them explicitly identify the core of the disagreement, and give them explicit research time to resolve the difference. If everybody has to agree, they'll challenge one another's estimates, and I'm sure you won't be the only one to catch onto this pattern.

We do use planning poker, although the team does not like Fibonacci count and have settled on a system of .5, 1, 2, 3, 4, 5
On a side note: I continuously struggle to understand this in terms of real time, it's total felt experience for me. Particularly towards the end of the release when there are scraps of work to be done I feel as if our units of measurement are unhelpful. My lead tech will talk about the need to give each individual story a measurement even if it doesn't seem worthy of say .5 because the sponsor needs to know there is a "cost". This perspective of everything having a cost, feels more like stick than carrot (value).
Back to issue at hand: So the dev team collectively throws estimates in our planning sessions, but as a rule of thumb we take the highest estimate. I do see devs challenge each other occasionally but not often. In cases of one specific tech lead, if this person doesn't like a story he will continue to throw high numbers. I have noticed a pattern that kills further discussion, the dev will say "well it still think there is complexity we aren't seeing and therefore I am not comfortable with anything lower than X pts". I would like to change this rule of thumb that we go with the highest estimate. Do others have this policy?
fb
------------------------------------
Yahoo! Groups Links
<*> To visit your group on the web, go to:
http://groups.yahoo.com/group/agile-usability/
<*> Your email settings:
Individual Email | Traditional
<*> To change settings online go to:
http://groups.yahoo.com/group/agile-usability/join
(Yahoo! ID required)
<*> To change settings via email:
mailto:agile-usability-digest@yahoogroups.com mailto:agile-usability-fullfeatured@yahoogroups.com
<*> To unsubscribe from this group, send an email to:
agile-usability-unsubscribe@yahoogroups.com
<*> Your use of Yahoo! Groups is subject to:
http://docs.yahoo.com/info/terms/

Hey Folks,

Can anyone suggest good firms or freelance individuals for doing
usability testing on an application(in San Francisco)? This is not one
of our core competencies and hence we want some pro help to gauge the
success(or not) of a re-design effort which is in the works. Any
references/help would be much appreciated.

Thanks in advance,
-Rahul

Jared,

Have you read 'the usability problem taxonomy'? of Keenan, Hartson, Kafura and
Schulman? What do you think of using this classification scheme for
between-subjects
studies?

Stefan

--- In agile-usability@yahoogroups.com, Jared Spool <jspool@...> wrote:
>
>
> On Oct 1, 2008, at 4:09 PM, Stefan wrote:
>
> > I've ordered scent of information and statistics in medicine so i
> > can some research on the
> > topic.
>
> I hope you won't be disappointed with the Scent of Information report.
> It doesn't really go into our methodology. That's not why we created it.
>
> What you're trying to do is *really* hard and will take huge amounts
> of preparation and some massively impressive statistics horsepower. I
> know because we've tried multiple times and only managed to pull it
> off some of the time.
>
> There are scaling and ground issues. Ground issues are about
> connecting the independent data collection points to a common element,
> so you can say that these measures are talking about the same thing.
> Scaling issues are about ensuring that Good/Bad in one scale mean the
> same as Good/Bad in another scale.
>
> This is very heavy duty science you're trying to do. I'm betting, if
> you want to do it well, it will triple-to-quintuple your research costs.
>
> I'm betting that's why you've not found a lot of resources on it. You
> need a deep pocket to make it really work.
>
> Jared
>
> Jared M. Spool
> User Interface Engineering
> 510 Turnpike St., Suite 102, North Andover, MA 01845
> e: jspool@... p: +1 978 327 5561
> http://uie.com  Blog: http://uie.com/brainsparks
>

Trek recently launched "Project One" where you can personalize your
next bike. Right now, just their high-end road bikes are available.

http://www.trekbikes.com/us/en/projectone/model/madone65/