Off and on, over the past few years, I have been asked to estimate many software projects. From estimating individual features (which are to be implemented), to providing business-case wide estimates for dozens of features over a long period of time. Estimating the effort required to build software is difficult, but not impossible.
With a project that I have recently been involved in, estimates were given in ‘number of development days required’. A simple formula then worked out, based on dev days, how many testing and business related days are required.
This was all well and good for a little while (note the word little), until it was decided to change our entire testing framework, for the better I might add.
Continuous Integration and automated testing was now an integral part of our development, no way could we meet our original, time-based estimations with all this additional work which we were expected to undertake. This had a flow on effect throughout the entire team. Actually tracking our velocity in ‘Points’, as opposed to time, has obliterated this hurdle, and just instilled a lot more confidence, and productivity, within the team.
I have seen this have negative effects on teams due to poor estimates. The development team end up feeling guilty that they are not meeting the business expectations and management seem to wonder why projects are taking much longer than has been budgeted. Ultimately, this will lead to the project, or business case, not being fully delivered, or the project spending a lot more than was budgeted for by adding additional head counts to meet the expected velocity.
Trying to solve this is a constant battle between software estimation and time elapsed. Basically, estimating in units of time does not work. Estimating an activity in Points, based on the complexity of the task, will allow you to know exactly how much a task is going to cost. One point costs one point; it has the same concept as money. But it is important that you never attempt to correlate the value of time to the value of points.
These Points are just a measurement of how complex you think a given task is. If multiple tasks have the same complexity, they will be given the same number of points.
Once you have determined the number of points for all the business requirements, you need to look at the velocity. This is what the business is going to use to determine how much the team is able to deliver in a set period of time. New teams will generally have a ‘rough’ velocity that will be refined over time, but it doesn’t take too long. The velocity is just a measurement of how many Points are being completed in a set amount of time.
Once the team has sat together and assigned points to all the requirements, and once the velocity is established, you are able to confidently tell business how long the task is going to take to be completed. The benefit of this is it takes the ability of the entire team into account, regardless of experience.
In Summary
Providing estimates in points and measuring the amount of points you can complete over a period of time, increases management and development visibility into overall progress and progression.
If you seem to be having trouble estimating the number of Points required for a given task, break it down into multiple tasks. The further you break these down, the more detailed the estimates will be.
Any time that there is an addition to the requirement, increase functional or technical scope, make a note of it and increase the estimate.
Measure your velocity via burn down / burn up charts which are visible to the entire team
- By Peter Leed – Consultant – Revolution IT
