Whether every two weeks, three weeks, or once a month... The development team will peel off a set of tasks from the top of the Release Plan providing the latest business priorities.

These tasks are then re-evaluated by the developers and deeper sets of subtasks are created to enable a reasonable estimate... that is, if you haven't yet jettisoned the idea of doing estimates (see Detailed Estimation Sucks).

The Iteration Process looks something like this:

Basic Iteration Process

The Dev team and the Business get together and go through the list of desired issues.

• Assign an issue
• Get an estimate from the developer
• Continue through the list of desired issues until the resources are used up
  
• Modify list of issues/priority as needed based on business feedback during this process

There is a balancing act between what the business hopes to have done in a given iteration, and what the Dev team says they can accomplish. So, at the outset of the planning process, the Business is armed with their set of priorities, pulling from:

• A list of all available issues (not just new features!)
  
• The initial idea of what should be in the current iteration. (This would have been decided during the initial Release Planning session -- typically used to get a rough estimate.)
  
• The "1st in Line" and "2nd In Line" buckets
• Your own prioritization scheme
  

NOTE: The Dev team may also have a set of issues they want to work on (from infrastructure/automation tasks, to refactoring).

There is often a tug-of-war when it comes to planning an iteration. The Business is going to want the Dev Team to have estimates for their features. The Dev team might have questions regarding details before they can give an estimate. If this is all done in real-time, folks may think it can be a bit wasteful. The Business is listening to the developers banter back and forth about how to implement a feature and what the estimate might be. The developers may feel the need to work out some subtasks before estimating "publicly."

NOTE this section discusses estimation as part of iteration planning. Give it a good long consideration before wasting precious time on detailed estimates. Read more here: Detailed Estimation Sucks.

Priority

Another common tug of war is Business Priority. Once the business knows the cost of a feature, they may alter the priority. The Business can compute the Return on Investment (at least from a relative perspective) for a given feature. Feature X that might make a few customers happy that costs 25Z might be prioritized lower than Feature Y that will make many customers happy for only 5Z. Conversely, having Feature X's few -- but happy -- customers that turn out to be the critical partners that Marketing has groomed, need to be kept happy. So Feature X may win out after all. The simple point is to provide the Business with the "cost" of development and allow the priority to be adjusted.

In the early requirements gathering phase, you will hopefully capture this sort of critical knowledge up front should it affect design or release planning. Nonetheless, you can get a Feature X at any point in the product life with, or without warning.

If it will make the planning process go more smoothly, you may need to have a "pre-meeting" to do an initial pass at explaining the next set of desired features, and then allowing the Dev team to caucus and come up with some estimates or the need for further discussions about a given complex or large feature. In general, any issue requiring more than 20 hours should be broken down into subtasks -- both for ensuring that the task is well thought out, and to show interim progress.

Story Points or Hours?

It is a common agile practice to use something called "Story Points" so that your units of measure are abstract and not so readily tied to work hours. I have not tried using story points, but conceptually, whether you estimate an issue as 10h or 2sp and you realize that you generally accomplish about 5h or 2sp per day, you end up in the same place. Mike Cohn has excellent material on all manner of Story Point discussions. Including this one that describes using hours for short-term planning.

Developer Estimation

The estimates should be made in Ideal Hours.

Ideal Hours

What the heck does this mean? The "ideal" time is what it should take to do the issue uninterrupted. Since many of these issues requires digging and testing, you have to account for those activities in addition to pure code/sql writing. What you would not include is time to learn SQL or the tool, or inflate it by the time you spend in the Scrum, etc.

Allow them to take on tasks to the tune of:


For example, a two week iteration represents 80 work hours per person. The Ideal Factor can start out at a rate of 50% to account for design time, scrums, discussion with the business, unit tests, testing, foosball. As the team marches forward, that value can be changed to account for reality.

Estimating Basics

This is a skill and some would say an "art" form (I am an overly optimistic estimator).

• Use hours (e.g., 5h) for your estimating (not days)
• Consider the task estimate based on "Ideal Engineering Hours"
• If multiple people need to work on a task, add up the two people's hours
• If the estimate is larger than a couple of days, be skeptical, break it down. (Unless you are one of those rare breeds that have excellent estimating skills.)
  

Logging time

• Use a timer – you'd be shocked!
• If you help someone else on their task (>15m), you can "Log Work" to their task.
• Log your time as you complete it.

Milestone Review

Following the iteration, remaining -- unfinished -- issues are either moved into the next iteration, or moved out altogether. Then, the team should take pride in demonstrating what they have built. Sometimes it is a code review and a modicum of visible output (maybe tests only). Other times it is a nice demo to the Business, QA Team, etc.

• Every two weeks
• Starts with a review of visible features for QA to see
• Review leftover tasks and bump to next milestone

Oops, We Didn't Finish All Issues!

That's okay. Try to improve each iteration. It usually isn't a huge problem if you missed a few issues (say out of 20 or 30). If the team is doing their best, what else do you want? Why does "management" care to hit the number dead-nuts on? BTW: Some people would call those extra few stories "stretch goals" -- which I hate on so many levels.