Craig Dickson has published an article on Agile DZone claiming that prioritising Stories with a Sprint is an anti-pattern. He blogged this in December last year, when I noticed it and grumbled on twitter, but no more. Now that its re-appeared on DZone I feel compelled to say something, and that it warrants a blog post of my own rather than a comment.
Craig says that a Scrum team commits to a “set of Stories by the end of the Sprint” (his emphasis), and that prioritising within the Sprint means that the “commitment evaporates”. That sounds to me like committing to, and delivering, a batch of Stories. I’m sure notable Scrum luminaries have assured me that the Sprint is not a batch. Craig even suggests the Scrum diagrams should represent the Sprint Backlog as “one single large block of work”. What about flow? What about limiting work in progress to improve flow? If shorter Sprints are good because it encourages prioritisation and limits work in progress, why not prioritise work and limit work in progress with the Sprint?
Craig goes on to suggest that rather than prioritising a Story within a Sprint so that it can “meet a business need”, the PO should “reach out and educate the necessary stake holders about the Scrum process”. This sounds to me like Craig is recommending that Scrum dictates how the organisation is run, and that this is more important than meeting a business need. I prefer my processes to support and enable organisations to meet their business needs. Scrum should be a means to an end, not an end in itself. My view of Agile is that is about being responsive to business needs, not forcing organisations to wait until a convenient date. A cadence should be useful, but not a restriction.
Similarly, Craig says that prioritising Stories within Sprints is bad if it creates “implementation dependencies between Stories”. I prefer to think that a Product Owner should be able to ask for, and have delivered, increments/iterations in whatever order creates the most value, and not be constrained in this way by process policies about how Stories should be written. Worse still is the suggestion that any dependant Stories should be scheduled into separate Sprints. How is that being responsive to business needs and encouraging flow?
Finally, I think that Craig is missing a trick. In the same way that short Sprints focus a team’s technical and creative capabilities to figure out how to get to DONE in a short time-box, so too will prioritising Stories within a Sprint focus a team to stretch their skills even further. A team that can deliver and release a single Story every day or so is surely in a better position that one which can only deliver a batch of Stories every week or so.
Craig concludes by observing that “There is nothing in the Scrum process that talks about Story priorities within a single Sprint.” Correct. But that doesn’t make it an anti-pattern, in the same way that TDD is not a Scrum anti-pattern because Scrum says nothing about TDD. Rather, I’d say that NOT prioritising stories within Sprints is the anti-pattern.
I agree with you Karl. I think prioritization is always a good thing. Like Scott Berkun puts it: “Be a prioritization machine.” And in real life, it often happens that the team can’t deliver all stories they committed to. In that case it is useful to know which stories should be completed first.
Kanban style pull flow can help with problems presented by the Sprint boundaries. I have seen a couple of teams naturally evolve from basic Scrum to Kanban style development (they developed their own adhoc Kanban board in a Wiki). They still had lightweight planning meetings, regular demos and retros but Sprint timeboxes weren’t that strict.
Well said, Karl. IMHO timeboxed sprints/iterations add value in organizations that lack a culture of frequent feedback and frequent value delivery. As such, it is a mechanism for change. When, instead of continuously improving value delivery, an organization or a team locks their process into a rigid model at some point along the continuum of improvement, they’ve missed the whole point.
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.
[…] Scrum Anti-Pattern: NOT Prioritising Stories Within Sprints (Karl Scotland) […]
Thanks for pointing that out Karl, I’d have missed it otherwise.
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.
Allan,
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
Karl,
great post and agree with you total. Having read the article no one ever seems to mention that in sprint prioritisation is an essential skill for an effective PO if something goes wrong. Story x turns into a horror the burndown flat lined and the sprint target is in trouble, then the PO needs to make a call (based on team advice of course)
Mike
[…] a recent post Karl Scotland drew my attention to this post by Craig Dickson on Agile DZone. Karl and Craig differ on their […]
Karl,
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.
Well, I partially agree with Craig. If you have iterations, it means you have a cadence. As a team you committed to release this set of user stories. And as a team you have full responsibility. But it means the team should have an authority to implement stories in any order, that will speed up the delivery. Dependencies may happen and indeed one user story implemented before another user story may be a good thing for the whole sprint.
If you do Kanban, all the above is irrelevant.
I think there might be some confusion here. I believe Criag’s point of view was to not let the PO change the priority of stories after they are in the current sprint. I completely agree with this because it is the only way to enable the development team to completely self organize in whatever way they see fit in order to meet their commitment. After all, the goal of each sprint is to produce a deliverable and therefor what difference would it make to the PO what order things get completed in when at the end of the iteration, they will have the working software with whatever requested features.
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.
[…] on February 10th, 2010 by David Draper In a recent post Karl Scotland drew my attention to this post by Craig Dickson on Agile DZone. Karl and Craig differ on their […]