I think the confusion here lies in the fact Karl would like to empower the team to do whatever it takes to get the job done, even if that means finishing the least important thing first in a sprint. The PO does not have this power once the team has made their commitment to finish a list of stories for the upcoming sprint.

From this point of view, I don’t think that the argument of Karl’s for delivering value over process still stands since either way the team still delivers the planned work by the end of the iteration. And I definitely agree that Scrum requires education at higher levels of the organization to encourage proper prioritization and understanding when it comes to what work can be completed and when. They may not ask for that shiny feature they just discussed on the back for a bar napkin last night and expect it to be done by “Friday”. It must be brought to the team for proper estimation and planning the following sprint and no earlier. After all, if it was so important, it would have been brought up sooner.

As for the point about limiting work in progress and maintaining an efficient flow, I believe this is a great argument for keeping sprints small, preferably only a week or two. This allows the most flexibility for the business to re order the upcoming work. It also keeps the team focused with a smaller, more manageable goal.

If you do Kanban, all the above is irrelevant.

I think that it is only fair to see that Craig is trying to implement Scrum. Scrum provides a certain model for engagement.

Personally I use prioritisation as a strategy that teams can use to self-organise. It is the teams approach that considers WiP and Flow rather than a mandate from the PO.

I’ve described my own take on this further here: http://www.agiledesign.co.uk/scrum/prioritising-stories-within-a-sprint/

I do certainly agree with you that when the needs of the process trump the needs of the business we have a problem. Any cadence needs to exist for the benefit of the business. In Craig’s example there was no clear reason for a 12 week cadence and it seemed that this took priority over business need.

Regards

Dave.

Saving things for another day is an anti-pattern.

Just kidding. More seriously, though, was there ever a “single Scrum way of doing things?” Seems to me the assumption that there is a single right way to do things presupposes that all situations and all problems are the same. To date, I haven’t seen that in the field. Quite the opposite, actually.

Dave

I don’t know Craig but it seems he is wrong on so many points. You are right. I guess I can see where he is coming from, it fits in with the idea of the “Scrum goal” but I’m not sure how many Scrum teams are using the Scrum goal technique.

In some ways this shows how there is no longer a single Scrum way of doing things. The interpretation of Scrum differs which means it is loosing one of its strengths. Or maybe I’m wrong, in which case a lot of “Scrum” teams aren’t “Scrum teams”.

As to the anti-pattern stuff that is so wrong. He’s borrowing a term to aggrandize his argument. Anyway, there is no such thing as an anti-pattern but we’ll save that for another day.

If batches are too large – in this context, sprints are too long and contain too many stories, hard to prioritize, long lead times between incremental deliveries, etc. – the flow of work becomes irregular and the organization becomes less able to respond to changing priorities or business needs. By gradually driving down the length of the sprints, we can reach a point where the timeboxes become irrelevant – just a form of overhead that can be removed with no ill effects. Then we’re close to another process model with which I believe you are familiar. That’s the point in the organization’s improvement when they’ve outgrown the need for a mechanism to force feedback and frequent delivery; feedback and frequent delivery have become the norm. The leg has healed and the cast can be removed.