Clarifying the Purpose of Iteration Planning

I was recently asked whether it would be OK for a team to complete their iteration planning without going to the point of estimating tasks in hours. To answer this, let's consider what the purpose of iteration planning is. In my view, the purpose of the iteration planning is for the team to arrive at a commitment to some set of functionality that they feel reasonably confident they can complete in the coming iteration. The purpose is not to identify tasks.

The purpose is not to estimate the number of hours for each of those tasks. The purpose is to figure out how many and which product backlog items they can commit to delivering in the coming iteration. If a team can do this without discussing tasks and hours, so be it. If a team can walk into the iteration planning meeting and one team member announces, "Sssh, I've receiving divine inspiration......... We can do the first three items plus the sixth on the product backlog," I would call the meeting over and we'd have our commitment. I'd be impressed and I'd be skeptical, but we'd be done with the meeting.

Since I haven't seen a team do this yet, I strongly recommend that an iteration planning meeting involve identifying tasks, estimating the effort of each, and then using that information to arrive at a set of product backlog items the team can commit to. I think this is the best way for a team to arrive at that reasonable commitment that I believe is the purpose of this meeting. Is it the only way? No. I've also worked with teams who decide that they will split work up such that all tasks are "about half a day". They then can skip explicitly estimating the hours for each task because, in a way they've already done it. But, until I learn how to receive divine inspiration at the start of my iteration planning meetings, I'm sticking with identifying tasks as hours as a good way to figure out how much to commit to.

A Free PDF to Help You Choose the Approach

A Free PDF to Help You Choose the Approach

I’ve created a PDF you can download that will help you decide which approach is best for any story you’re adding detail to. It also includes examples of the two approaches.

Download my PDF



Mike Cohn

About the Author

Mike Cohn specializes in helping companies adopt and improve their use of agile processes and techniques to build extremely high-performance teams. He is the author of User Stories Applied for Agile Software Development, Agile Estimating and Planning, and Succeeding with Agile as well as the Better User Stories video course. Mike is a founding member of the Agile Alliance and Scrum Alliance and can be reached at [email protected]. If you want to succeed with agile, you can also have Mike email you a short tip each week.

The discussion here is closed but join us in the Agile Mentors Community to further discuss this topic.

Go to