Prioritizing Tasks Within a Sprint

In the discussion that ensued from another post here, Brian Bailey asked a great set of questions. The questions were big enough that I've moved them here. I'm going to intersperse Brian's questions and comments with my responses. Brian started with:

If the product owner is onsite and part of the same company, what role should she have in prioritizing tasks within a sprint? To clarify, I assume that a 30-day sprint does not mean that new features that are completed are held until the end of the sprint. If a feature is finished and ready to move to production after the first week, it can be released, correct? If that's the case, should a PO be allowed to prioritize the stories and tasks the team committed to ("Please start with this critical item") or should the team have full control over the order things are worked on?

First, the concept of prioritizing tasks within a sprint is one that doesn't make sense. When a team plans a sprint they make a commitment to complete the user stories they select from the product backlog. It's not a come-hell-or-high-water commitment, but the team is expected to do its best to complete the work they select. And averaging things out over the course of many sprints, the team should generally meet their commitment. The idea of prioritizing items within a commitment doesn't make sense.

Back in 1988 I got married and made a commitment to my wife, Laura. I promised to love, honor, and cherish her. (We mutually agreed to drop "obey.") I didn't promise to love her all the time, honor her if there was more time and then cherish her as a stretch goal.

But what about Brian's statement that, "I assume that a 30-day sprint does not mean that new features that are completed are held until the end of the sprint." Well, yes and no. This depends upon what was agreed to during sprint planning. The default assumption should be that the team has the right to rip the system apart on day one of the sprint and does not have to have it put back together until the last day. (For argument's sake, I'm ignoring that this would be a bad idea for many reasons.)

If the product owner needs an interim deliverable during the sprint, that should be discussed and planned during the sprint planning meeting. There will almost certainly be some overhead in doing this and the team needs to account for that. Even better, though, I'd suggest trying a shorter sprint length if this is common. Back to Brian:

And of course, the dangerous follow-up that almost seems inevitable - could the PO then decide or shift priorities (not adding or replacing tasks, though) throughout the sprint? I'm confident this is a bad idea and could lead to micro-management instead of team-driven development. But I can also see how the PO might have a good reason for something to be moved to the front of the line.

You're correct. This is a bad idea. One of the challenges with 30-day sprints is that it is a long time to make the business go without changing its collective mind. If this questions are legitimate concerns then a shorter sprint length is a likely solution.