Agile Estimating: The Secret To Delivering On Time
This content is syndicated from by Kelly Waters. To view the original post in full, click here.
For decades, delivering on time has been the holy grail of software development.
I've been doing agile software development for quite a few years now. I've seen many benefits, but one of the most remarkable things of all, is how so many teams can quickly get good at delivering on time.
It's the art - and/or science - of predicting what can be delivered in a given timeframe, even if the same team was hopeless at estimating before!
This, for me, is one of the most compelling reasons to do agile development. Here is the secret:
- Estimate features, rather than tasks.
- Keep your estimates high-level intuitive guesses (don't analyse the details).
- Estimate in points to indicate the relative size of each feature.
- Consider estimating using a number sequence like Fibonacci. Fibonacci numbers get less precise as they get bigger, which builds a natural distribution curve into your estimates.
- Estimate as a team. Consider playing Planning Poker to facilitate this.
- At the end of your Sprint (or iteration), score the points for all features you managed to deliver. Only score points for features 100% complete, tested and potentially shippable. This is your Velocity. Count zero for incomplete features.
- Track your Velocity over time on a graph. You can also track your Reliability, i.e. the number of points delivered as a percentage of the number of points committed to at the start of the Sprint.
- At the start of each Sprint, look back at your Velocity for recent Sprints to decide how much to commit to for the coming Sprint.
- Don't try to reconcile points with hours or days.
- Commit as a team.
Like most great things in life, it's actually very simple. That's really the beauty of it. It seems a bit abstract, so many people might be retiscent to give it a try. I would urge you to try it.
You'll need to give it several Sprints before you pass judgement on it. You will find your Velocity bounces all over the place for the first 3-4 Sprints. But then it will settle down, as your team discovers its norm.
Trust me, it works. I have seen it work in many different teams, time and time again. It's a statistical approach to estimating. And statistically, if you estimate with relativity, everything is average in the end.
Originally published on agilesoftwaredevelopment.com