Re: [scrumdevelopment] Re: Prioritization
- Friday, October 31, 2008, 12:34:34 AM, Gerald Williams wrote:
> Well, anyone can attend a stand-up - the real question isWell, here is where I greatly from classic Scrum philosophy. I
> whether they are allowed to talk or not. I would say no -
> but that they should be there as observers. Would I get
> up-set if they were talking at a stand-up. No I would not -
> I would just think whether common sense says its ok given
> team size etc etc.
believe the product owner is not just an animal who
contributes to the success of the breakfast being made my the
team, but is definitely a wholly committed animal. Someone
else on another (this?) thread recently said, "the product
owner is the one wringable neck". I don't agree with the
statement, but if considered true, no-one is more "committed"
than the PO. It is also possible that my "whole team" attitude
simply shows that I started growing up in the extreme
programming world two or three years before I spent much time
learning about Scrum.
> One of the reasons for them acting asOf course the PO will follow the same rules as the other team
> observers at the stand-up from my exerience is that this
> allows the meeting to be quick (all the developers can
> interact with the PO daily in any case as they are
> co-located (ideally) and for the PO to pick up on what
> further action s/he needs to get involved with post the
members in the meeting. Why then would the PO speaking cause
the meeting to be long. Of course the PO will speak with the
appropriate team members after the meeting to get in-depth and
remove impediments. But, just like all the other team members,
the PO has tasks s/he is working on to make the project
successful. S/he might be working with the documentation
writers or trainers, s/he might be working on a sales or
marketing plan, etc. S/he will report on the progress of these
tasks and any impediments s/he has encountered. The PO may
find some of her tasks impeded because of things the
developers haven't finished, just as the developers may be
impeded by things the PO is responsible for.
In my opinion, not allowing the PO to speak in the daily
meeting can contribute to a parochial attitude by the
developers that the software is all that matters. It's not.
It's vitally important, but not solely important.
The project will not be considered a success by upper
management unless all the elements come to a successful
> A co-located PO has a very good idea of what isAbsolutely, impediments should be visible and addressed
> happening in the team for obvious reasons! The visible
> display of project status - (to be done, in progress, done
> etc) helps the PO to also understand progress. I like also
> to see constraints and issues shown (and the date they were
> raised) - as this adds pressure to eliminate them quickly
> (why has this been there for 3 days, who's dealing etc)- and
> the PO and anyone else can see it. So why should the PO ever
> be 'in the dark' in a solid environment set-up?
outside the meeting. Absolutely, project status and progress
should be visible to everyone.
I don't advocate the PO speaks in the daily meeting to "keep
the PO out of the dark". I advocate it because it helps keep
the developers out of the dark, and the "whole project" on the
- Wednesday, November 19, 2008, 3:05:08 PM, Dillon Weyer wrote:
> In this case how is XP different to Kanban then?XP differs from kanban in many of the same ways as Scrum. It
is batch pull, not continuous pull. Instead of a sprint, XP
calls it an iteration. In XP, like scrum, but not kanban, each
story has a high level estimate attached to it during release
planning, which is similar, but somewhat different from
backlog grooming in scrum.
> aacockburn wrote
> --- In firstname.lastname@example.org
> <mailto:scrumdevelopment%40yahoogroups.com> , Graeme Matthew <scrum@...>
>> Whats the difference between a product backlog and kanban they both
>> as signaling system to trigger action?
> The kanban is continuous pull, the backlog is batch pull.
> With the backlogs, each month you *promise* how much you'll do, and
> pull a *batch* of items from the product to the sprint backlog.
> You're now locked.
> With kanban, you pull directly from the product backlog to the
> work list, one at a time. There is no work estimate attached to the
> item - you just work on it till you're done, then pull the next.
> Some teams put size limits on the work list, so you can't work on
> more than e.g. 5 items at a time.
> That's quite a difference.