Re: Scrum and UCD

 > Given that, the UCD member of the team is just another flavor of
 > business analyst and all of the analysts would collaborate on
 > just-in-time analysis tasks including user research and usability
 > testing. Programmers also pair up with analysts as needed to have
 > conversations, investigate technical issues, or research the business
 > problem.

Ok, I understand that. I'm not in complete agreement, but I think we
may be using words differently. For example, I think UI people need
skills and experience that are about human factors and design rather than
business, but you may mean "business" is some more general way. Also,
I'm not quite sure about "just in time": I would imagine some user
research might be done up front, rather than in the context of
specific story.

 > * are the UI designers and programmers within the same team but do
 >   different kinds of tasks, or do they do both?
 >
 > my answer: UI designers and programmers are just another flavor of
 > business analyst or programmer and they would collaborate with the

Ok, similar to above: I think I understand this, though I'm not sure I
agree with it.

 > * what are the UI stories (or backlog items) like, especially for user
 >   research?
 >
 > my answer: Like the term "methodology" we have to be careful with the
 > term "story".  "Story" is a thing that developers implement.

When you say "developer", are you meaning to exclude UI designer?

 "Tasks"

 > High-level tasks might be treated "as if" they were stories so it is
 > easy for the entire team to be aware of overall progress and
 > activities for the week.

Ah, this is the kind of thing I was wondering about. So you have
different kinds of backlog items, some are "stories", which (I think
you are saying) require full functional implemention. Is that right?
And others are different, such as user research, usability testing,
and UI design. Is that right?

* do the UI stories count as "done", even when no software has been
 written?  

 > More hairsplitting!  

Oh? I'm not sure why.

 > The purpose of saying a story is Done, is to have
 > a means of measuring the team's velocity -- how much implementation
 > gets done on average per iteration/ sprint.  Thus, in theory, you only
 > really care about Done if the story is a coding story.

Hmm. I'm not quite understanding this, and it seems different to what
you said above. It seems to me if a task is big enough to be managed
as a story, then they should be some similar equivalent to "done".

I suppose the key thing is that when a story is implemented, there is
nothing more to do, and hence we use the term "done". But this seems a
very programmer-centric perspective. For example, if the software was
beging developed in the context of some broader business product,
there may be more work to do once the software is fully implemented.
So I suspect this is becoming tautological: that the software is done
when the software is done.

 > It is important to see the status of those higher-level analysis
 > tasks, which includes the big UI tasks that precede the coding
 > stories. If UI work was substantial enough to make visible as a
 > "story" then you have to be able to say if it is not started,
 > in-progress, or done, and have target expected completion dates so the
 > team can get some kind of assurance about how and when the backlog may
 > grow or shrink.

Ok, so this is what I was wondering.

 >...
 > But, saying that these UI stories are Done, does not count in the
 > velocity equation.

Hmm, ok, but again this is programming-centric. If, for example, the
programming work was minor compared to UI work or more general
business product work, then we should be careful.

Anyway, thanks so much for writing this up. I have not actually seen a
team working in this way, and will now be on the lookout.

Cheers
Robert