Comments on: Why I don’t use real hours for sprint planning

By: Joe

Joe — Wed, 08 Apr 2009 16:05:15 +0000

Bravo! You need to write the next book on Agile Estimation and Planning. Wholeheartedly agree with everything in this blog post.

By: Ravindar

Ravindar — Thu, 10 Apr 2008 01:17:01 +0000

Oh yeah one more thing, this strategy has helped us even in very difficult times right now. I would not say we are perfect, far from it, but we have become good. Although things have gotten tough over the past couple of months with ever changing direction and much more, the team is still sort of together on this strategy, atleast I think. We did loose a little direction, but I think considering where we are as an organization this has really helped us keep our sanity.

By: Ravindar

Ravindar — Thu, 10 Apr 2008 01:06:30 +0000

So obviously I agree with you Amit. As you know I actually implemented this strategy, with lot of stealth. We used to be a team that used to do sprint planning in which we would discuss till the cows came home about how many hours a task takes, what it should look like etc. etc. Well with gentle persuasion, the team saw the folly of their ways. We realized that maintaining sprint backlogs and all the activities associated with it were causing pain and in-fact slowing us down. So today we maintain a prioritized list of product backlog user stories(broken down to a reasonable size, which is an art in itself that you get better at as you learn and adapt) and the team picks off the top of the stack. So for example, the team is mature enough to know that to get a list of items on the UI, they need a UI pick list, database table etc etc, and don’t feel the need to do this breakdown and estimate it. We do draw a line in the sand, your so called end of sprint. I still have to maintain a sprint backlog but no one on the team really cares about it. Over the past six months the team members felt it was a phony success and that real success was delivery as you pointed out. Obviously this comes with a mature team, but I think it is achievable. Also, obviously, there are teams that will find this too extreme and would like the rhythm approach. I guess every team finds their own path with this. I for one have become a fan of as Ravi Mohan pointed out: “pick the top priority card and work on it, damn the estimates”

By: Premanand Chandrasekaran

Premanand Chandrasekaran — Thu, 20 Mar 2008 21:42:06 +0000

Amit,

Very well said. I’d like to take what you’re saying a step further. In my ideal world, we shouldn’t be required to estimate at all. Just keep picking the next important thing and get it done. If something starts taking too long, discuss alternatives.

Obviously, high levels of maturity and trust are needed for this arrangement to work. In this life, maybe…

By: Ravi Mohan

Ravi Mohan — Sat, 15 Mar 2008 03:13:45 +0000

This is good thinking (and writing).

About the only caveat I can think of is that for your scheme to work, you need a self motivated and talented team, who actually like writing software and are well above average in programming skill.

As you know, these days I am very skeptical of methodologies, agile/lean whatever, but having worked on both “classic” iteration based agile/scrum projects and also on the “pick the top priority card and work on it, damn the estimates” style you outline above, I can confirm that the latter way of working was an order of magnitude more productive than the former.

Cheers,

By: Steve Campbell

Steve Campbell — Fri, 14 Mar 2008 20:20:04 +0000

Removal of iterations seems to be just another improvement that some teams are able to make, perhaps linked to understanding of Lean concepts. It is not clear (to me at least) what the criteria are that make it a viable option.

In any case, I don’t think anyone’s suggesting that a new sprint team start this way, and so far I have not seen anyone say that we should do away with regular team retrospectives.

By: Amit Rathore

Amit Rathore — Fri, 14 Mar 2008 19:39:20 +0000

I agree that designing the implementation is important. However, I believe this needs to be a just-in-time activity. If the team tries to design the implementation during the planning meeting, two things happen – 1. it takes forever, and 2. the value from that discussion will probably decay away before the card is even picked up. Or a developer who might not have been present may end up implementing it, or the requirement might change a little bit, and so on.

This is not to say that the topic of design is not broached at all, of course. However, design is evolutionary, doing that in the planning meeting is sub-optimal.

About the commitment, I agree with Adrian above, you don’t need detailed task breakdown or hours-based estimation to commit to something, as long as everyone on the team is mature enough to understand estimates are estimates, and there is value in getting something in the hands of the customers as quickly as possible.