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.
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
Author: Joe Bergin
Original at http://csis.pace.edu/~bergin/patterns/xpPatternsEuroV7.html