Sacred Schedule

You are a developer on an agile project. It is during the development phase of an iteration.

If you don't end the iteration on time, you have no basis of knowing where you are. Recall that most projects are estimated as 90% done after the first third of the project and remain so until long after the due date. If you slip schedule you lose control rapidly. It becomes easy to do it again. If you fail to complete a task in the current iteration, someone is unhappy, of course, but you know where you are.

• There is pressure to finish everything, but the clock gets in the way.
• One more (hour, day, week) would let you finish all this work. But you might not finish then, either.
• If you don't know how fast you can really go, you can't plan for the future.
• With accurate velocities (story points per iteration) you can plan future iterations and releases with confidence. This lets you control cost.
• Nothing in development is really sacred, however.

Therefore, don't put off the scheduled end of an iteration, even for just a day.  Some tasks may not get completed, but this is self-correcting in your future velocities. The only work that gets counted in an iteration for the computation of the next velocity (Yesterday's Weather) are the tasks completed and accepted by the customer. If you didn't finish it, don't count it. This will give you a lower, but more realistic, velocity for the next iteration.

• If you don't finish a task or a story in the current iteration, you can save (but not commit) the work done and write a story for its completion with a new time estimate. The customer can schedule these or not in future iterations.
• Customers may have a hard time with this initially and require training. They like to think that the pile of stories in an iteration is like a contract. They are unhappy when you don't complete everything. If you have kept everyone informed along the way you can lessen the blow for the customer at the end. Write stories and move on. Coach, take notice.
• Plan to have the final integration test at noon of the last day of the iteration. If everything comes together nicely you can refactor for half a day. Or have a party. If not, you have half a day to make it right.
• Over a few iterations you will know how much work, in story points, the team can do in (say) ten days. This gives you the basis of long-term estimation by extrapolation, as long as the average difficulty of the stories remains the same.
• However, there are situations in which the customer has a special need. There may be long-scheduled meetings with real users who have traveled a distance to try certain features.  You might need to accommodate this, even if it means (gasp) putting in overtime for a short period. Management should expect lower productivity after a push, however. Sometimes it helps to reward people for the effort required in the push. Above all, however, avoid the death-march syndrome that is all too common today.
• The work completed forms the basis of long term planning by management. Once you know how many story points you can complete in an iteration you know how much work can get done by some future date and/or how long it will take you to complete an estimated amount of work. If you slip schedule, you have no basis for this planning.