Comments on: Prioritizing Tasks Within a Sprint http://blog.mountaingoatsoftware.com/prioritizing-tasks-within-a-sprint Succeeding With Agile® Fri, 10 Feb 2012 03:51:54 +0000 hourly 1 http://wordpress.org/?v=3.3.1 By: Mike Cohn http://blog.mountaingoatsoftware.com/prioritizing-tasks-within-a-sprint/comment-page-1#comment-7872 Mike Cohn Mon, 07 Apr 2008 23:19:15 +0000 http://blog.mountaingoatsoftware.com/?p=21#comment-7872 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. 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.

]]> By: Zacharias J. Beckman http://blog.mountaingoatsoftware.com/prioritizing-tasks-within-a-sprint/comment-page-1#comment-7860 Zacharias J. Beckman Mon, 07 Apr 2008 19:44:31 +0000 http://blog.mountaingoatsoftware.com/?p=21#comment-7860 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. 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.

]]> By: Dave McLean http://blog.mountaingoatsoftware.com/prioritizing-tasks-within-a-sprint/comment-page-1#comment-7685 Dave McLean Fri, 04 Apr 2008 22:31:31 +0000 http://blog.mountaingoatsoftware.com/?p=21#comment-7685 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,

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?

]]> By: Mike Cohn http://blog.mountaingoatsoftware.com/prioritizing-tasks-within-a-sprint/comment-page-1#comment-7176 Mike Cohn Mon, 24 Mar 2008 20:43:57 +0000 http://blog.mountaingoatsoftware.com/?p=21#comment-7176 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. 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.

]]> By: Adam Cohen-Rose http://blog.mountaingoatsoftware.com/prioritizing-tasks-within-a-sprint/comment-page-1#comment-7166 Adam Cohen-Rose Mon, 24 Mar 2008 14:58:51 +0000 http://blog.mountaingoatsoftware.com/?p=21#comment-7166 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. 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.

]]> By: Kimota94 aka Matt http://blog.mountaingoatsoftware.com/prioritizing-tasks-within-a-sprint/comment-page-1#comment-7162 Kimota94 aka Matt Mon, 24 Mar 2008 13:49:38 +0000 http://blog.mountaingoatsoftware.com/?p=21#comment-7162 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." 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.”

]]>