Practice: Weekly Cycle

Plan work a week at a time. Have a meeting at the beginning of every week. 
During this meeting:
  1. Review progress to date, including how actual progress for the previous 
week matched expected progress.
  2. Have the customers pick a week's worth of stories to implement this week.
  3. Break the stories into tasks. Team members sign up for tasks and estimate 
them.

  Start the week by writing automated tests that will run when the stories are 
completed. Then spend the rest of the week completing the stories and getting 
the tests to pass. A team proud of its work will fully implement the stories, 
not just do enough work to get the tests to pass. The goal is to have 
deployable software at the end of the week which everyone can celebrate as 
progress.

  The week is a widely shared time scale. The nice thing about a week as 
opposed to two or three (as I recommended in the first edition) is that 
everyone is focused on Friday. The team's job--programmers, testers, and 
customers together--is to write the tests and then get them to run in five 
days. If you get to Wednesday and it is clear that all the tests won't be 
running, that the stories won't be completed and ready to deploy, you still 
have time to choose the most valuable stories and complete them.

  Some people like to start their week on a Tuesday or Wednesday. I was 
surprised when I first saw it, but it's common enough to mention. As one 
manager told me, "Monday's are unpleasant and planning is unpleasant, so why 
put them together?" I don't think planning should be unpleasant; but in the 
meantime, shifting the start of the cycle makes some sense as long as it 
doesn't put pressure on people to work over the weekend. Working weekends is 
not sustainable; if the real problem is that the estimates are overly 
optimistic, then work on improving your estimates.

  Planning is a form of necessary waste. It doesn't create much value all by 
itself. Work on gradually reducing the percentage of time you spend planning. 
Some teams start with a whole day of planning for a week, but gradually refine 
their planning skills until they spend an hour planning for the week.

  I like to break stories into tasks that individuals take responsibility for 
and estimate. I thin ownership of tasks goes a long way towards satisfying the 
human need for ownership. I've seen other styles work well, though. You can 
write small stories that eliminate the need for separate tasks. The cost of 
this approach is more work for the customer. You can also eliminate sign-up by 
keeping a stack of tasks. When a programmer is ready to start a new task, he 
takes one from the top of the stack. This eliminates the opportunity for him to 
choose a task he particularly cares about or is especially good at, but ensures 
that each programmer gets a variety of tasks. (Pairing gives programmers a 
change to use specialist skills, whoever holds the task.)

  The weekly heartbeat also gives you a convenient, frequent, and predictable 
platform for team and individual experiments. "OK, for the next week we're 
going to switch pair partners every hour on the hours," or "I'll juggle for 
five minutes every morning before I start programming."


------------------------ Yahoo! Groups Sponsor --------------------~--> 
$9.95 domain names from Yahoo!. Register anything.
http://us.click.yahoo.com/J8kdrA/y20IAA/yQLSAA/nhFolB/TM
--------------------------------------------------------------------~->