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

Re: [agile-usability] Ownership outside of the SCRUM team

Expand Messages
  • Gerard Meszaros
    We ve used this concept of separate backlogs for different subteams on some projects. For example, a software development backlog and a product design backlog.
    Message 1 of 20 , Oct 28, 2008
    • 0 Attachment
      We've used this concept of separate backlogs for different subteams on some projects. For example, a software development backlog and a product design backlog. "Half-baked stories" went into the product design backlog and were turned into "fully baked stories" that ultimately went into the s/w dev't backlog. The PD backlog was worked by the business team, which included the product owner, several other business resources, a BA/UE person and a tester. This seemed to work pretty well as it allowed us to track the velocity of the s/w development team better than when the half-baked stories were in the main backlog. One thing it really helped was reducing the variability in the estimates because the fully baked stories were usually much better understood and much more focused on the high value portions of the half-baked stories. The two subteams were in the same room and collaborated continously so they were still part of the same team, just responsible for different backlogs.

      Gerard
      -- 
      Gerard Meszaros
      Lean/Agile Coach/Mentor/Trainer
      http://www.gerardmeszaros.com 
      
      Author of the Jolt Productivity Award winning book "xUnit Test Patterns - Refactoring Test Code". Learn more at http://xunitpatterns.com/index.html


      William Pietri wrote:

      Hi, Robert. Hope you don't mind me butting in.

      For the teams I work with, the main work queue is about released software. Most of the cards in that queue involve at least some amount of UI design, visual design, front-end coding, and back-end coding. Some engineering research ends up in that queue as well, either when it's large enough to have a schedule impact or has a deliverable. That deliverable is usually an estimate on some other set of cards.

      Other kinds of thinking, research, and effort tend to be driven by that queue, but not kept in it. That includes engineering work, business work, and design work. A lot of people manage the schedule for that other work intuitively, but I also see separate formal queues kept for individuals or functions. E.g., one team is going to try a visible, card-based queue for product management work, so the product manager's workload is more visible, and so that some of the work can be shared.

      William

      Robert Biddle wrote:

      Ok, so my next followup is this:
      
      In the approach you describe,
      * is all work done organized as stories/backlog- items, even those which are
         distant from user interaction (e.g. estimate viable market size for 
      release 1)?
      * are all team members on the project full time from start to finish?
      
      I think it's an interesting idea, if so, but I'm not sure how practical 
      the second
      point (above) would be.
      I've never seen a project run like this, by the way.
      
      Robt
      
      
      Ron Jeffries wrote:
        
      Hello, Robert. On Saturday, October 25, 2008, at 3:30:42 PM, you
      wrote:
      
          
      Just a followup question while I mull this over.
      Are you suggesting the situation you describe
      for Scrum or XP or both?
            
      For me, both.
      
          
      In particular, are you happy with people who
      do no programming or program testing being on
      the team? For example, people such as user researchers
      or market analysts?
            
      Sure. They are part of the customer sub-team I should think.
      
      Ron Jeffries
      www.XProgramming. com
      www.xprogramming. com/blog
      Education is the ability to listen to almost anything without losing
      your temper or your self-confidence. --Robert Frost
      
       
          
      
      ------------ --------- --------- ------
      
      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@yahoogrou ps.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/
      
        


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