Work Timing

I l @ ve RuBoard

The work environment is set up to help the team get the most out of every hour , not to sequester them. XP introduces the concept of "velocity," which includes setting a sustainable pace for a project. Web projects sorely need this.

Avoiding Burnout

When you do your first Web site and work four months straight twelve hours a day, it can be justifiably considered a right of passage. If you are still doing this by your fourth Web site, it has become bad project management and speaks to nonexistent customer expectation management. If this is how your company works, get out before you burn out. Every project will have instances where people have to work long hours, but these should be rare occasions with darn good reasons.

Setting Velocity

As stated in Chapter 4, we set our velocity in the release plan at the start of the project. We select the number of people on the team and multiply it by 50 billable working hours for a two-week iteration. Every week we expect our team to put in 5 hours each day working on the project undistracted, including attending meetings. Teams will differ in how much you can ask of them, but be clear about your expectations and be flexible in how different people meet them. Some team members will do 10 hours one week and 40 the next . Others will consistently do 25 hours each week. Make your judgments over a longer scale.

Time Tracking

Automate your time tracking system. As the project manager you must account to the customer for the time spent on a project. Time sheets handed in weekly are difficult to maintain, so if you can't track time via an automated system, get the numbers for the past day at each morning's standup meeting. You should be putting this information into a spreadsheet or other system so you can keep a journal of estimates against actuals. The team needs constant feedback about their estimates if improvements are to occur.

I l @ ve RuBoard