RE: [scrumdevelopment] Re: Scrum // Respect
We got into this discussion because you were saying the PO can
or should dictate the sequence in which sprint backlog items
get done. If there R S T W X Z, and W is in the "must haves", the
PO can or should say to implement them in order W X Z T R S.
I'm busy disagreeing with that.
I’ve looked back at my replies and I don’t think I said exactly that. I do think the PO should give an idea of what stories are most important and should be done first, just in case should things go awry,. I’ve agreed that MoSCoW prioritisation would be enough, for instance.
Mostly, I’ve been arguing it is reasonable to assume up front that the team MAY not meet their commitment, and it is reasonable to organise things in advance to cater for this possibility, rather than wait until the team have recognised that things aren’t going to plan
But when you say, "Wouldn't you like it completed as the first
thing done?", I hear you disagreeing with me and I disagree back -
No, I really don't care if it's the first thing done or not,
so long as it's done in time.
In other words, for me, there is an enormous difference between
those two phrasings - they aren't close synonyms to my eyes, they
are dramatically opposed.
But I didn’t say the second. I said “Wouldn't you like to have completed it first?”, meaning beforehand. I understand that you reasonably enough interpreted as the second, but it really isn’t what I meant.
When I ask the kids if they’d like to eat first before going the cinema, I don’t mean that do they want to eat as the first thing they do next, just asking about the order of the two things.
Bearing that in mind, what is it you would like to assert?
Either we'll find that we really disagree, or we'll find we
agree but have been running into a word clash.
So, I think we’re probably running into a word clash. My (apparently poorly expressed) point for the last few rounds has been the one above – it is reasonable for the PO to assume the team MAY not meet their commitment, and say what they’d like to be done should things go wrong, and that this has to happen before things do go wrong.
One reason I’m slightly surprised by the idea that it’s somehow unfair/unreasonable/counterproductive to allow for the possibility that the team won’t mean their commitment is that to me, one of the reasons why Agile methods work as well as they do is they do consciously deal with the fact that in software development, plans often do go wrong – we don’t know now how to plan the development because the customer doesn’t know what we want, any plans we do have will change because the customer’s ideas of what they want will change, when we give them something their ideas will change again. When we’re estimating, we’ll find our estimates wrong.
I see nothing especially different about assuming that the team’s commitments may also turn out not to be deliverable in practice. Given that, an Agile method should deal with the fallout of that – one way is to reduce the sprint length (so the opportunity to revise and correct direction is as soon as possible), but another seems to me to be to say something about the relative importance of the stories in a sprint, up front.
- 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 email@example.com
> <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.