47772Re: [scrumdevelopment] UX role in Scrum teams
- Jul 28 5:26 AMI like the specification workshop idea. In my experience, it can take a while for the UX team to "get with the program" and align their work with the backlog. Starting out, our UX department would produce detailed mock-ups of different parts of the system without much regard to what the teams would actually be implementing in the coming sprints. Lots of wasted work was done, because a lot of the features for which analysis and mock-ups were made didn't even end up in the product.
It really is vital to get the UX people tightly involved, to make sure that they focus on what is most important: fleshing out the highest-priority stories for upcoming sprints and supporting the team in the current one (designs might have to change due to technical issues etc).
Johannes StaffansOn Wed, Jul 28, 2010 at 11:39 AM, JC Grosjean <jcgrosjean@...> wrote:
Hi Demetrius,Communication, coordination and collaboration are the keys to integrate UX activites in Scrum teams.Actually I don't care if it is acceptable or not, as an agile coach one of my goals is to make the "process" effective and valuable in context and to avoid wastes : working ahead is necessary most of the time .Agile is an interesting challenge for a UX specialist, a challenge both related to PO and Team activities. During a sprint, he has to design the content of next sprints (n+1, n+2) (needs analysis, storyboarding, wireframing...), collaborate with developers on the current sprint and usually evaluate results of the previous sprint (n-1) (with users/ stakeholders).Here is how I proceed as a coach and UX specialist.A good starting point is to link UX activities with the user story readiness (and lifecycle). I ask the PO to to have the user stories he wants to include in a sprint, "80 % READY" for the sprint planning (Scrum ceremonial the first day of the sprint).To do that: just enough UX & BA activities must be done (needs analysis, storyboarding, wireframing, business rules ...), and the MOST IMPORTANT I ask the PO and Team (with UX and testers) to have a specification workshop related to these specific stories, friday afternoon or monday morning (as they like) just before sprint planning. This collaborative workshop focused on examples, storyboarding and wireframing on the whiteboard to define together conditions of satisfaction of the user stories is crucial and usually well appreciated by people.Of course, it doesn't replace the collocation and the collaboration (Conversation) between PO, UX and Team during the sprint, mainly for adjustments and feedback. It is the remaining 20 % of the user story.I hope this helpsJean ClaudeJean Claude GROSJEANAgile Coach I UX SpecialistValtech Pariswww.agile-ux.com (in english)www.qualitystreet.fr (in french only)2010/7/28 Peter Stevens (cal) <peterstev@...>
I had a similar situation. Three teams: UX, UI and java. The UX and UI guys were filling a pipeline
with screen shots which the java guys were supposed to implement.
The UI team started doing Scrum first. Eventually they were so productive, that the customer/PO had
to stop the team for 6 months until the Java people caught up. They never really did either, until
they started doing Scrum too. So, first question: Are you producing an inventory of features waiting
to be implemented? In this case, when the UI work resumed, many months later, they decided the
implement in the next sprint. By keeping the two teams in lockstep, it worked. (There were geography
and language issues, which discouraged a collaboration directly in the sprint).
I had another similar situation: One team developing a new UI to an existing application. We defined
the application as User Stories, but needed to come up with an information architecture (IA). The
stories defined what, and the IA described how (from the users point of view). The Product Owner was
very interested in the IA. We went through multiple iterations with our best people working on the
design, only to have the P-O redesign it once he saw it. (It reminded me of the letter writing
example in Parkinson's Law: http://tinyurl.com/2vel7sb ). In this case, it was as much about control
as about method.
Perhaps the P-O thinks he is saving time and/or money by evaluating mock-ups rather than actual
running systems. Maybe some experimentation with alternative approaches would be convincing.
In general, I would suggest keeping your presentation layer as thin as possible and as decoupled
from the application as possible so it is easy to change. A usability test with real users late in
the project can really make a mess of your beautiful UI concept ...and your schedule ;-). I would
look for signs of inventory accumulating, shortages of work, or excessive redesign. These indicate
your process is wasteful. And I would try to find out why your P-O wants to work the way he does,
then show him a better way to accomplish his goals...
Hope this helps,
PeterLean Agile Scrum Konferenz in Zürich mit Mary Poppendieck und Henrik Kniberg.
On 28.07.10 00:44, Demetrius Nunes wrote:
> Hi there,
> Our customer is used to discuss, validate and accept user story definitions
> based on high fidelity screens and prototypes, which demands the UX people
> to work ahead of the developers, showing these prototypes to the customer.
> Only after that, the Product Owner feels comfortable to commit the story to
> the backlog.
> Is it acceptable for UX people to work ahead of the developers to prepare
> and design the user interfaces and interactions of user stories before the
> actual sprint where these stories will be built, or, ideally, UX should
> always be working together with the developers on the same stories in the
> same sprint?
> The Product Owner feels comfortable working this way, as long as the
> developers participate thru the whole process and the UX people support the
> developers during the sprints, but I fear this might be a sub-optimization
> of the process, although is hard to see it being done any other way,
> specially because our customer is very attached to the UX quality of the
> user interfaces.
> The PO likes to make an analogy with the auto industry, in the sense that
> there is a product concept, design and prototyping phase of a car (in which
> manufacturing engineers are also involved), before the actual manufacturing
> phase, where engineers will then do most of the work figuring out how to
> build the assembly line for that car. Is this a good analogy?
> Best regards,
Schlagen Sie die Brücke von Scrum Team bis zum schlanken Unternehmen!
Peter Stevens, CSM, CSPO, CSP
Independent Scrum Trainer and Coach
Sierra-Charlie Consulting | Zurich | Switzerland
Member of DasScrumTeam.de
tel: +41 44 586 6450
cell: +41 79 422 6722
- << Previous post in topic Next post in topic >>