Ring ring!
[Agency] “Hello Devs4Sale agency, How can we help you?…”
[Client] “I’d like a mobile App please. How much do apps cost to design and build?”
[Agency] “Hmm, well a small app might cost around £5k to £25k, a medium app, might be around £25k to £100k, lets say… £50k and perhaps a big, complex ‘uber-duber’ app could well be in excess of 100k. It all depends what you need. What kind of app is it?”
[Client] “Well, it’s an all-singing, all-dancing, brilliant, shiny app with a ton of cool features!”
[Agency] “So it sounds like it might be a medium-sized project. We really need to discuss the requirements in detail to be able to give you an accurate quote.”
[Client] “That’s quite a range, are you sure??!! Will it be more like 25k or like 100k?”
Yes, that is quite a variance. Why does the medium app cost between £25k and £100k? Even if we guesstimate it at £50K, the actual cost might still be 100% higher or 50% lower.
The answer is obvious, we don’t know the detail of what we are estimating. Even after the first 30 minutes of discussing the features and requirements with the client, we still have no idea what the end price might be. So we embark upon a voyage of discovery, to try and get to an accurate cost.
Time Spent Vs Accuracy
The longer we spend estimating a project, the more accurate the estimate will be. With a low-level, detailed estimation we are likely to get the most accurate result possible. However, even then it is nearly impossible to create a quote that is 100% accurate and the time that is spent can come at a price. A lot of effort will go into this process, sometimes weeks of scoping and research and this cost will be factored into the overall price.
However, there are ways of arriving at an acceptable estimate. Consider the following:
- A low-level, detailed, estimate might take 2 weeks of requirements gathering, boot camps, and could be 90% reliable – at most.
- A 2-hour, high-level, ball-park estimate might still be 80% reliable!
Was the 2-week investment of time and effort really worth it? It took 20 times longer to get the level of accuracy up from 80% to 90%. It all depends on how precise the estimate needs to be.
Traditional Waterfall Approach
Typically the first step would be to work out what the high-level requirements are:
- As an end-user, I need to sign up and log in to the app.
- As an end-user, I want to access to feature x.
- As an end-user, I want to access to feature y.
- Etc.
Next, we might try to figure out the views and backend system required to deliver all these requirements. We naturally start to divide this project into smaller subsets of features and tasks. Then we keep adding more and more detail until we finally have a functional spec.
Bottom-Up Estimation
Following this, we might estimate each feature one at a time, consider testing, deployment, project management and other tasks that might not sit within the functional spec. Finally, we arrive at a cost! But it’s taken a lot of planning and research to get there.
This type of estimation process is sometimes referred to as ‘Bottom-Up’ and is usually what’s required with the ‘waterfall’ methodology. We start with the smallest tasks at the bottom, in order to determine the cost of each feature. With waterfall, everyone agrees on what will be delivered, the schedule, and the end cost. Most of the detail has been thought through in advance, and there is a commitment to delivering all the features to the client for a single price.
One problem with this approach, is that the end-design solution may start to change as the work progresses. This might uncover problems or weaknesses with the original spec. Changes will result in additional costs to the client as they will likely result in additional effort which was not accounted for in the original agreed cost. These hidden costs might come as a shock to the client.
Another problem here is lack of contingency. If the cost/time and features are fixed, where is the wiggle-room? Quality will suffer. If the project is running behind schedule and the number of features is set in stone, the quality of code will suffer. This results in more bugs, and a code base that might not be as maintainable in the longer term.
An Agile project will turn this ‘Golden Triangle’ on its head.
Agile Approach
The team might agree a fixed cost and schedule with the client whilst building contingency into the number of features. Although this might seem scary for clients at first, there are many benefits. There is less need to research and devise a scope or functional spec and no need to put together a detailed estimate since the costs are agreed, based upon time and resource.
Projects are again divided into features or user stories. The functional spec might not need to exist in any detail. This means there is less time investment in the early stages, reducing the need for detailed research and requirements gathering and there is much more scope for the software design to evolve during the sprints.
The risks are identified early in the project when the velocity of the team can be calculated, perhaps at the end of the first sprint. This gives the business plenty time to shuffle stories around and according to feature priority and business value.
Top-Down Estimation and Relative Sizing with Story Points
In an agile project user stories are often estimated using ‘effort points’ based upon the Fibonacci sequence. It is called a top-down approach because we not interested in the detail of the tasks, instead we are much more interested in quick-fire estimates of higher level features, or even epics.
Typically the features are estimated by the entire team. Everyone is involved in the process, but it can happen much more rapidly with a ‘poker planning session’. This could last an hour or two, rather than days/ weeks as with the traditional approach above. Having everybody involved means that the combined expertise of the whole team can be utilised. The precision decreases with larger features which might mean breaking the feature into smaller stories or tasks.
Fibonacci Sequence
½, 1, 3, 5, 8, 13, 20, 40, 100, infinity, ?, coffee break
A large number of stories can be estimated using this method. The idea here is not to arrive at an accurate estimate of time, the aim is to group the stories into those of similar sizes. In fact, the Fibonacci sequence forces us to take a ball-park approach. Since we are forced to find the nearest grouping, there will be ‘winners and losers’ and it will balance itself out in the end!
The reasoning behind using points rather than hours, is that it might be difficult to estimate in units of time at speed. Also the speed at which the team can deliver points of effort will depend on the skills of the individuals in the team. Team A might not be as fast as Team B but the relative size of the stories remains the same.
T-Shirt Sizing
Another, even faster, method of estimating the sizes of features or stories is using a T-Shirt approach. With T-Shirt sizing, we only have 3 or 4 sizes – small, medium, large, XL. There is no accuracy with a T-Shirt sizing approach, however it does mean that an individual can divide the features into groups in a matter of minutes. It might be a great way of becoming accustomed to relative estimating. If the team finds it easier, we could put some underlying numbers on each size – (e.g. small = 5) and then gradually shift to using the numbers in future estimating sessions.
Often with Agile projects, before each sprint, the team will re-estimate the stories taking a bottom-up approach – similar to a waterfall project.
Stories will be broken down into small ‘bite-size’ tasks and estimated in units of time (hours). This means the sprint can be calculated with the accuracy of a waterfall project.
We can then compare the bottom-up estimate with the total time available in the sprint and make adjustments before the sprint gets underway.
Conclusion
Waterfall
- A waterfall method is a ‘plan drive approach’ which creates cost/time estimates.
- Waterfall is subject to cost, time and quality risks. This is factored into the estimate.
- We typically try to reduce the risk by spending much more time on upfront research, detailed specifications with cost/time estimates.
Agile
- An agile method is a ‘change driven approach’ which creates feature estimates.
- The risk decreases as the project progresses
- We typically spend less time on up-front requirements, specification and cost estimations.
Should we always try to be agile? Perhaps it might not suit a projects’ needs, but it’s easy to see why more and more businesses are shifting toward this methodology.
