Re: [agile-usability] Ownership outside of the SCRUM team
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 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.
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/