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

Re: [agile-usability] Interaction designer Scrum Team and planning poker

Expand Messages
  • William Pietri
    ... For the purposes of my point above, I don t think it matters. I wrote it that way because some project teams I work with really have one person that does
    Message 1 of 6 , Jul 4, 2008
    • 0 Attachment
      Nick Gassman wrote:
      On Fri, 04 Jul 2008 09:08:23 -0700, William Pietri wrote:
      
        
      http://www.jjg.net/elements/pdf/elements.pdf
      
      
      [...]
      
      In situations were you've got somebody that really can handle the whole 
      stack, from thinking about the user needs and the guiding philosophy of 
      the project down to writing the CSS, then they're fully involved in both 
      sets of activities. If they're more inclined to specialize, then you'll 
      see them end up more on one side than the other.
          
      William, I work across the whole stack, but I don't do CSS. I might
      specify/approve/advise on any element there - in detail -  but don't
      actually produce the materials. I see the model as one that talks
      about user requirements and design, and not about how they get
      produced. Are you suggesting differently?
        

      For the purposes of my point above, I don't think it matters. I wrote it that way because some project teams I work with really have one person that does all that, including the CSS.

      More broadly, and comparing with my experience producing physical things, I believe that all "production" of software should be automated. The human role is pure design. I see Jesse James Garrett's model as about finer and finer expressions of a design. For many of the designers I work with, the CSS is just the most detailed expression of their design intentions. Production happens when a browser takes their HTML and CSS design specs and produces a screen for the user to interact with.

      But practically, not everybody works that way, and for the purposes of Jean Claude's question, I think it my answer would be the same.

      Agile approaches normally involve a just-in-time resolution of detail. To the extent that a given designer sees their role as involving the abstract end of things, they will be involved in what in my world we generally call product management. When they work at the concrete end, then they will be closely involved in the minute-to-minute activity of the team, and also involved in providing estimates. Some do both, and are involved in both.

      William
    • Matt Anderson
      My assessment is the same -- the best fit for an Interaction Designer is as part of a SCRUM s Product Owner role. In that role the designer is better able to
      Message 2 of 6 , Jul 7, 2008
      • 0 Attachment
        My assessment is the same -- the best fit for an
        Interaction Designer is as part of a SCRUM's Product Owner role. In
        that role the designer is better able to direct the project's vision,
        both from a business perspective and a user experience perspective.
        This also has the advantage of moving much of the designer's work
        outside of sprint tasks. Estimating a design's completion can be
        quite difficult if testing and validation are to be part of that
        design's "done" criteria.

        Matt Anderson
        Senior UX Designer
        Citrix Online


        --- In agile-usability@yahoogroups.com, "jcgrosjean" <jcgrosjean@...>
        wrote:
        >
        > Hello,
        >
        > According to you, what is the best place for the Interaction designer /
        > user experience specialist in SCRUM projects?:
        > - belonging to the Product Owner team (as Jeff Patton suggests it in a
        > recent article :
        > http://agileproductdesign.com/blog/emerging_best_agile_ux_practice.html)
        > - belonging to the Team (as developpers, testers ...)
        >
        > I tried the firt and the second solution : advantages and drawbacks in
        > both cases. It also impacts the way we do estimation and planning, the
        > velocity of the team... A simple example, if he belongs to the team, he
        > intervenes and is playing the planning poker; if you consider him as a
        > Product owner, he doesn't have to give an estimation during
        > the "planning poker" (but provides the team with useful information to
        > estimate the UI design).
        >
        > Finally are wireframing and storyboarding activities estimated as tasks
        > for the team ? and user testing ?
        >
        > I tend to believe that the most confortable place for him is with the
        > Product Owner.
        > If the team clearly adopts agile principles and values, there is no
        > problem.
        >
        > And you, how do you organize it in your projects ?
        >
        > Jean Claude
        > www.qualitystreet.fr
        >
      • thomas lissajoux
        ... vision, ... I agree with that... to the extent that the designer just doesn t stay in its ivory tower and keeps a close contact with the ones doing the
        Message 3 of 6 , Jul 22, 2008
        • 0 Attachment
          > My assessment is the same -- the best fit for an
          > Interaction Designer is as part of a SCRUM's Product Owner role. In
          > that role the designer is better able to direct the project's
          vision,
          > both from a business perspective and a user experience perspective.
          > This also has the advantage of moving much of the designer's work
          > outside of sprint tasks. Estimating a design's completion can be
          > quite difficult if testing and validation are to be part of that
          > design's "done" criteria.
          I agree with that... to the extent that the designer just doesn't
          stay in its ivory tower and keeps a close contact with the ones doing
          the dirty coding. This all sounds natural on this group, but surely
          needs to be stressed again to lots of Interaction Design folks...

          Hence he should really focus on hi-level lo-fi prototypes (to ensure
          a balance between design and technical capability and avoid potential
          rework).

          One more pro for the designer being part of the PO team is that he
          then is at the core of the value/priorisation process and can focus
          on questions such as : What are essential features ? How can we
          incrementally build this one feature ? What is the relative
          importance of these features ? And most importantly : how does that
          translate across Garrett's planes ?

          Thomas
        Your message has been successfully submitted and would be delivered to recipients shortly.