Buddha Buck recently asked the Extreme Programming list if there were a velocity range that could be considered 'good' for a team of about seven people doing two-week iterations. He felt that a velocity of eight or below indicated that the team's stories might be too big. The resulting discussion provided some answers to the question, and the questions behind the question.
Velocity is used as a tool to predict the future productivity of a team. If all of the stories that the team worked on were the same size, in terms of how much work it would take to implement them, then we could simply count the number of stories the team completed per iteration. A given team would tend to complete about the same number of these equal-sized stories each iteration, and management could make plans based on the team's known capacity.
In many environments, stories are not all the same size. Therefore, stories are given relative sizes, often called estimates. A story of size two is twice as big as a story of size one. A story of size three is three times as big, and so on. It is reasonable to expect that stories of size two will, on average, take twice as long to complete as stories of size one. In order to make these estimates easier to talk about, the sizing numbers are assigned units called 'points' or 'story points'. Thus we can say that a five-point story will tend to take about five times longer than a one-point story. On average, a given team will tend to complete the same number of points' worth of work each iteration; this number is the team's velocity. Thus, velocity is the team's capacity. It measures how much work the team can do per iteration.
Steven E. Newton described a 'good' velocity this way: "A good velocity is one that usefully predicts how much work you'll get done in future iterations."
Kent Beck observed another benefit of knowing the team's velocity:
Another purpose of measuring capacity is to improve throughput. If you plan for less than your capacity, you get less done than you could have. If you plan for more than your capacity, you get less done than you could have.
Charlie Poole reminded readers that developers tend to think in terms of how much work it will take to implement stories, while managers and customers tend to think in terms of the amount of value being delivered by completing the stories. It is important to note that story estimation and velocity are all concerned with the amount of work there is, and how long it will take to complete.
The most basic aspect of Buddha's question was answered, but the list discussion went on to examine some of the subtler issues present in it. In particular, Buddha was concerned that the stories the team was working on might be too big. The discussion thread confirmed that smaller stories tend to be preferable to larger ones.
Tim Ottinger pointed out that smaller stories provide more frequent milestones to help the team and stakeholders know how far along the work has actually progressed at any given time.
Clearly no story should be larger than an iteration. Of stories within the iteration, the larger story has a greater risk of not finishing. You don't want to be in the situation where you either get N points or 0 points. It would be good that you can have 40% of the stories points done (done-done) at the halfway mark.
Steven Gordon shared some related guidelines.
- If you are not sure if the stories are small enough, then they are almost certainly too big.
- If the stories were too small, the team should notice that overhead of tracking stories seems wasteful.
- The issues posed by stories that are too small are much less problematic than stories that are too big, so erring on the side of smaller stories is recommended.
- If too small stories is the biggest impediment that a team has, congratulate the team for having mastered XP.
Ron Jeffries shared that he likes to see stories sized such that a pair of programmers can complete two or three stories in a week. He was less enamored with the concept of points:
I think the whole point notion is nearly bogus and I regret my part in pushing it so hard. It distracts from the real point, which is to break stories down until they are small and can be done at a roughly constant pace.
How does your team decide how big the stories will be? Do you use the team's velocity as an indicator that the sizing is off? Leave a comment and share your thoughts.