Each team may define programmer velocity differently. But within a team, every engineer must use the same definition – their velocities must take the same things into account. If not done consistently, tracking and load balancing will not work and the Iteration and Release plans will be unreliable. If you have not yet started using XP, this paper is not for you – Read this after reading the XP trilogy (see bibliography). If you are using XP, read on – this is how one team in ISS defined Programmer Velocity. This is what the XP literature calls a "local adaptation". More recently, teams in ISS use team velocity and do not track programmer velocity. But back when we did, this is how we did it.
Ideal Engineering Days
Before discussing velocity, we must define Ideal Engineering Days (IEDs). An IED is when everyone just leaves you alone to program. Unhook the phone; close Outlook, ICQ and AIM; cancel meetings; and put up a do not disturb sign.Naturally, we never get 5 full IEDs in a week. You do have to go to meetings. You do have to check email and voicemail. And you do have to help others. In our case, the Events team, helping others takes the form of pair programming. If your team is not pairing, helping others takes the form of peer reviews, code walk-throughs, integration testing, and chalk talks.
Still, you might think that the more IEDs you can get in per week the better. Not necessarily – You may be neglecting something. You might not be spending enough time helping others, refactoring bad code and writing tests. If that's the case, your code will be difficult to maintain and your team will suffer.
We estimate tasks and stories in Ideal Engineering Days. We might also call these XPUs (eXtreme Programming Units). Ideally, stories should be broken down into tasks that will each take ½ to 2 IEDs.
Programmer Velocity
Ok, so we estimate in IEDs. What about all those meetings, phone calls, emails and interruptions? What about peer-reviews or pair programming? How do we account for those, and how do we deal with inaccurate estimates? Programmer Velocity must take all of that into account. Reread this paragraph to see what must be included in your velocity.In the last iteration, I completed my tasks (those that I signed up for and am responsible for), originally estimated at four IEDs. It was a two-week iteration. So, I spent about three days each week pairing with others on their tasks, writing documents like this, attending meetings and fixing defects. In this example, my Velocity is 4.
Velocity is simply the original estimate in IEDs for the tasks you owned and completed last iteration. This is the definition used in the green "Planning eXtreme Programming" book. If I completed tasks originally estimated at five IEDs, then my velocity is five. It doesn't matter how long it actually took. What you count is the original estimate of the stories/tasks actually completed.
Each programmer does a different number of IEDs per week. Everyone's velocity is different.
• Velocity takes into account how much "other stuff" you do. The more "other stuff" you do, the lower your velocity.
• Velocity is also a measure of how over-conservative or ultra-aggressive your estimates are.
• Velocity is measured. After each iteration, look to see how many IEDs you originally estimated for the tasks you completed. If you picked up more tasks during the iteration, add the original estimate for those into your velocity. If you did not complete all of the tasks you signed up for, do not add the estimates for those into your velocity. Remember; only count IEDs for tasks you led. Don't guess – measure it.
You may want to compute velocity over as few as one or as many as three iterations. If your velocity is stable or steadily moving in one direction, use "yesterday's weather" [Planning Extreme Programming, pages 33-34, 90, 117-118]: Your velocity for this iteration is your measured velocity from last iteration. If your velocity is unstable , first make it stable. If you can't, then measure velocity over more iterations.
There is no ideal value for velocity. However, if your velocity is more than 5 in a 10-day iteration, consider whether you are spending enough time refactoring, testing and helping others.
Managers, note: Velocity cannot be used to measure programmer productivity or value. "It's a result, not a control variable." [c2 wiki] It would be inappropriate to compare programmers by their velocity.
How to use an Individual's Velocity
After programmers sign up for and estimate tasks, the tracker balances everyone's workload. Programmers that have too much work give some tasks to other programmers. Balancing activity goes like this:Total IEDs estimated for this iteration (my tasks)
VS.
My velocity.
A common mistake is to divide the number of days in the iteration by 2 "because we're pairing." Don't do this. If you have a 15-day iteration, do not divide 15 by 2 and say there are only 7 days. There are 15. Pairing is accounted for in everyone's velocity. If you multiply the task estimates by velocity AND divide days by two, you are overcompensating (double counting).
Example: Fred's velocity is 2.5. Fred should sign up as lead for 2.5 IEDs worth of tasks. These are tasks that he "owns" and is responsible for. Do not count tasks he intends to do as a partner this iteration – that's accounted for in his velocity.
Example: My velocity is 3.5. I sign up for tasks. My estimate comes out at 5 IEDs. I'm over loaded so I give a 1.5 IED task to someone else. Now I'm balanced. During the iteration, I get behind and need to defer ½ IED of a task to a later iteration. At the end of the iteration, I measure my new velocity. Since I didn't complete all of my tasks, my new velocity is 3 – the original estimate for those tasks I did finish.
Example: Chet's velocity is 6. So is Joe's. Chet and Joe correctly sign up for 6 IEDs for this iteration. Halfway through the iteration, the tracker notices that Chet is falling behind. Chet agrees to give one of his tasks, a 1.5 IED, to Joe, who is making great progress on his tasks. At the end of the iteration, Chet completed tasks originally estimated at 4.5 IEDs. Joe completed tasks originally estimated at 7.5 IEDs. Now, Chet's new velocity is 4.5 and Joe's is 7.5.
When tracking, I prefer to only track and balance a programmer's primary tasks – I don't try to balance work as pairs and I don't sign up as pairs. I like to keep it light. However, signing up and tracking as pairs actually gets people to pair up, so it may be worth the extra effort for your team to track and balance pairing activity as well.
Miscellany
Engineers should pair with others as much as others pair with them. For example, if Sue signs up to lead 5 IEDs, she should pair with someone else for around 5 IEDs. This will happen naturally if the tracker balances the workload.If Sue doesn't help others with their tasks as much as others help her, some other team member has to pick up the pairing slack. This inflates Sue's velocity and deflates someone or everyone else's. This is not a problem as long as Sue is consistent – otherwise velocities will be unstable and less useful.
Special assignments, such as writing essays like this, can also impact your velocity. If a pair will be working on the assignment and if you can estimate it like a programming task, then treat it just like any other task in the iteration. If not, budget some of your time during the iteration for the special assignment – treat that time as unavailable. At the end of the iteration, measure your velocity as if you had fewer calendar days than everyone else.
Variations
Your team does not have to use the velocity definition presented above. You can come up with your own. I used to use a variation that used lots of messy division. It was based on the (now deprecated) Load Factor math from the white eXtreme Programming Explained book. I don't recommend it.Here is another approach you could use. If your team thinks and estimates in terms of average size stories or tasks, then your team may want to define programmer velocity in terms of points per iteration, w here 1 point is an average size unit of work. For example, I might be able to do one point per iteration, whereas Charlie might crank out 1.5. My velocity would be 1 and Charlie's would be 1.5. Since tasks are not all the same size, Charlie can take on a task that is 50% larger than average, whereas I should work on an average one-pointer or two ½-pointers.
Pick an approach that works well for your team.
Story Velocity v. Task Velocity
Above, I defined velocity as the original estimate in IEDs for the tasks you owned and completed last iteration. You also have a story-velocity. Your team may decide to track Story Velocity or both Story and Task Velocities. If you decide to only track one, Story Velocity is more useful in that it can be used for both Release and Iteration planning. Task velocity is only useful for Iteration Planning. You can't do Release planning without your story velocity. (You cannot predict your end-date if you don't know your Story velocity.) I personally believe this and it's also what Ron Jeffries said at XP Universe 2001.Why wouldn't the two velocities be the same? Because stories are estimated at a higher (and less accurate) level of granularity. Also, story estimation is done less often and may have been done with different assumptions or different team members. Story estimation should be done by the whole team as a group, but some teams only have a sub-set of the team estimate the stories (not a good idea). Conversely, task estimates are done more often and are usually done by only 1 or 2 programmers. They are done at the start of the iteration in which they'll be implemented, which is the most accurate time to estimate.
Use Task velocity in Iteration Planning to see if the team or any team member is over-committed for the iteration.
Use Story velocity in Release Planning to get a rough idea of what stories are in what iteration.
Update BOTH velocities at the end of EVERY iteration.
Team Velocity v. Individual Velocity
In the definition above I said "you or your team". Some teams track Individual velocity (more paperwork, more granularity, more accurate balancing). Other teams track Team velocity (less work, lightweight).It's up to your team to decide whether to use Team or Individual Velocity.
Bibliography
Kent Beck, eXtreme Programming Explained, Addison-Wesley, 2000. (The white book.)Ron Jeffries, Ann Anderson, Chet Hendrickson, eXtreme Programming Installed, Addison-Wesley, 2000. (The purple book.) Pages 64 and 65 are especially useful.
Kent Beck, Martin Fowler, Planning eXtreme Programming, Addison-Wesley, 2000. (The green book.)
No comments:
Post a Comment