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.
Tags: product owner, sprint planning, sprints
Great post, Mike! We’ve definitely been struggling with much the same issues as Brian lays out, including Product Owners who sometimes want to micromanage the creation and prioritization of Iteration tasks. We’ve gone from 1-month Iterations down to 1/2-month ones, and some teams have even opted for 1-week Iterations, all because change is happening too rapidly to allow coherent cycles, otherwise. We’ve been working hard lately to really push the idea that the PO determines “the what” and the team figures out “the how.” Naturally, anything associated with tasks should fall into “the how.”
We’ve had similar issues with prioritisation changing in the middle of a sprint (partly caused by us having to deal with multiple projects at once) — our solution was to have weekly iterations, but to plan work at a slightly higher level on a monthly basis.
This way we get to change prioritisation on a weekly basis if something changes, but the business and development teams have a rough idea of where we’re aiming to be in a month’s time.
Matt and Adam–Indeed. One of the most common reasons I’ve seen for using very short, 1-week sprints is because the business simply cannot go longer without changing its mind. Sometimes this is the nature of the business. More often, the business has become accustomed to that degree of change and isn’t aware of its adverse affect on productivity. So, agile teams go to one-week sprints to try to train the business into perhaps getting to the point where they can go two weeks without changing their mind.
Adam, you are absolutely right to be doing the four-week planning around your one-week sprints. I’d consider that a form of release planning and all teams benefit from slightly longer horizon planning than just the upcoming sprint/iteration. Release planning can be more about putting a stake in the ground and saying “In 1 [or 3 or 6] months we want to be there” than about specific, precise “we commit to such-and-such” plans.
Mike,
When you say _the team is expected to do its best to complete the work they select_ does this make room for separating out _must have’s_ and _nice to have’s_? I guess it’s still prioritising but is this a worthy compromise that may give the business some comfort? Or would you recommend avoiding this too?
Mike, great information here. I usually take a different approach on the last point (re: what if the PO wants to change or manage priorities within the sprint), though. I tend to be very protective of the sprint timeline, and shudder at the idea of one-week sprints. I’ll usually discuss highly volatile tasks with the PO, explaining the high cost of context switching, changing sprint goals, etc. My goal is to push the PO to hold off on tasks that are not yet stable. Really, if a business can’t tell whether a given feature is important on a 30 day horizon, I question whether it should be the target of immediate development. Hopefully, with adequate education and discussion on the costs, we can select other, more stable goals and the PO can work on stabilizing the work for the next sprint. I’ve been quite successful in crafting a message that the cost of “flailing” in development carries throughout the organization and is usually not justifiable.
Hi Zacharias-
I’m not a fan of one-week sprints. I think they are just too short to be sustainable for the team, too short for complex work, and have other problems as well. However, they can be good training. If a team is having trouble getting things done in longer sprints I will recommend they try some one-week sprints. I think of these in the same way a running coach may have a runner do some short 220m-intervals while preparing for a 10k run. The team learns how to work in very short sprints and then returns to a more suitable 2-4 week pace.
I agree with you that a business should be able to tell if a feature is important on a 30-day horizon. The challenge is that most business people haven’t had to do that. It’s been too easy to redirect a team so they’ve not been accustomed to thinking ahead. One way to learn how to think 30-days ahead if it’s a challenge, is to do so incrementally.
By the way, with a 30-day sprint the product owner must really think 59 days ahead. If you need something in the next 59 days you better ask for it now. Fifty-nine days seems awfully far to require someone to think ahead.