Finally! We have a velocity!
One of the teams I coach is getting close to their first release using Agile methods. Our first planning and estimation effort was difficult because we had no previous stories to compare with and no kown velocity. So we had to estimate what our velocity would be. Not a very comfortable position, but what can you do if you have no historical information?
It turns out that our estimate was not too far off. We didn’t give a “point estimate”, one date. We gave a range of dates between a “best case” and a “worst case” scenario. The size of the range between the two dates indicates our uncertainty about the estimates. We’ll probably deliver a few days before the “worst case” date, which is an acceptable date for our customer. Our releases are not timeboxed, they are scope-driven.
The next release should be easier to plan and schedule now we have a velocity and a set of implemented stories.
Defining the next release
The next release isn’t very large. In about an hour we wrote the stories and estimated them. We reused many of the existing stories. We estimated the stories in story points by comparing them with the existing stories. This release will be about one third the size of the previous one.
We know our velocity, therefore we know how many mandays we need. We know how many men and women are available for the project and when they’ll be available, therefore we know when we’ll be done in the best and worst case.
Easy.
This one will go faster!
When we calculated the number of mandays, the developers exclaimed that this number was too high. They argued that their velocity would be higher on this release because they wouldn’t have all the startup costs of the first release. They were now more experienced.
To which I replied: We’ll see…
Maybe we’ll have lower startup costs. Maybe we’ll work faster because we have more experience. If we do, our burndown will tell us soon enough. It would be nice to end up closer to the “best case” than the “worst case” estimate this time. In any case, we need some time to clear out some ‘technical debt’. We’ve decided to invest 10% of our time in debt-reducing work.
IF we deliver sooner than expected we’ll take on the next release sooner than planned. There’s more than enough work waiting to be done.
And next time we’ll schedule using our improved velocity.
