If you are reading this article, our trusted business analysts have likely agreed to impart upon your project some much-project estimation. And well, you’ve come to the right place!
After all, for today’s blog post, we would like to spell out our meticulous process for preparing estimations, the different sorts of artefacts you should be ready to receive and how this all will play out in the end — on that note, by the by, if you find that any or all your expectations have not been adequately lived up to, please do not hesitate to contact us at any time. This will help SPG to continue improving our company’s services for you as well as our future customers.
So, with this in mind and without further ado, let us dive right in!
A Unique Process
In essence, our estimation process has three distinct levels of depth: User stories and epics, acceptance criteria and of course, the estimates proper. For every stage, not only should our customers be given greater clarity, but also receive some very useful artefacts.
It all begins, however, from a fairly singular premise: that all requirements are fully estimable when broken down into their core components.
In this way, instead of wasting time worrying about contingency allowances and haphazardly attempting to forecast the future, as explained in our article How We Estimate, we reduce all requirements into tiny increments with various degrees of complexity and compare these results with the projects we completed in the past.
By making use of this unusual process, we are able to visualise the likeliest scenario of how much time a project should take. We use the term “likely” because naturally, this does not mean that our estimates are set in stone. As with any other inexact science, there is always room for both error and further adjustments.
Handy Artefacts
While Agile development greatly prioritises working software over extensive documentation, in the initial stages of a project, we firmly believe some paperwork to be absolutely essential, as it enables our customers to make the most informed decisions. As a result, outlined below are some of the artefacts you can expect from us.
1. User stories and epics
First, we write user stories, which are short narratives designed to express our customer’s requirements in a clear and understandable way. This could be something as simple as “as a prospect, I would like to be able to register for a free trial.”
Some user stories may also be grouped together under larger umbrellas known as an epic. Each epic can be labelled in a variety of logical ways, such as authorisation, reporting or user management.
2. Acceptance criteria
From time to time — but more often when misunderstandings seem particularly likely to occur — we may also include acceptance criteria, alternatively known as the definition of done. These aim to provide the necessary conditions that must first be met in order for a story to be regarded as complete (e.g. remember password, or register via facebook).
3. Estimation in hours & complexity points
Finally, as briefly touched upon, after converting requirements into user stories, our software engineers decide which of these will be easy enough to implement to be chosen as the constant and given the value of one complexity point. Stories deemed equally easy to implement should also receive one point, and those which are more complex than the constant are determined to merit either two or three points.
Because we know how long it takes our developers to implement a single complexity point, we can later convert points to time, and time to money. In this way, our customers are given estimations in both hours and complexity points. The former is especially useful, as it allows our clients to determine whether or not they have been correctly understood.
For example, most clients would expect the implementation of a single login page to take considerably less time than generating extensive reports. Whenever they see a discrepancy here, however, they are able to touch base with our developers and seek to rectify the issue.
As for project estimation in hours, this is widely considered to be the most important artefact, as it provides our customers with a potential timeline of future events.
The Question of Accuracy in Project Estimation
By very definition, working with estimates is an imprecise endeavour; yet some helpful practices exist to increase reliability.
For example, if our client would like to build a customer relationship management system, he may either do so with specific or more abstract requirements. However, it is certainly advisable to come prepared with a detailed list of prerequisites, as of course, in general, the more detailed your requirements, the more accurate our estimations.
Nonetheless, this concept is also somewhat paradoxical, as another thing developers must be looking to avoid is the practice of decomposing user stories to the point of them becoming what is known as “sand” — a reference to the grain-sized nature of these tiny requirements.
Although in practice, developers may end up finishing multiple stories a day, they do so without really getting anywhere. This wastes plenty of valuable time and consequently, culminates in much longer periods of development. In our own experience, for instance, the minimum size of a user story should never fall short of a half day’s work, or 4 hours, to be precise.
Don’t Jump to Conclusions
Far too often, customers will observe what they consider to be extraordinarily large or small numbers in estimations and subsequently — without giving it a second thought — abandon plans to do business with the responsible software provider. This, however, is harmful for a number of reasons.
Because human language is an imperfect communication medium, if figures are too small, for instance, this is probably due to a misunderstanding of a project’s level of complexity. Perhaps the customer was expecting a web chat application much in the vein of Google Hangouts or Skype, yet in the process of relaying his requirements, somehow left developers with the mistaken belief that all they had to do was build a messaging form.
Of course, the same could also be said in reverse, where developers are left under the impression that a project is considerably more complex than what customers originally had in mind — yet these casual mix-ups can easily be resolved with some sensible further inquiries.
Team Structure & Project Speed
For our longer estimations, we also produce alternative forecasts that allow you to compare the duration of your project under various structural conditions. In this way, if a project is estimated at 6 months (960 hours), we may determine that a small team of two developers would be competent enough to effectively halve your delivery time down to approximately 3 months (480h). Similarly, by adding a third developer to the mix, we could bring down the estimated time to a probable 2-month period (320h) — so you’re always free to opt for the structure that most fittingly agrees with your company’s needs.
In addition to saving time, choosing to assign a team to your project will also result in a panoply of other benefits. Not only are customers blessed with the power of team effort and multiple thinking brains, but they also have plenty to gain from the use of automated practices like continuous integration and delivery, and the oft-misunderstood — yet undeniably effective — pair programming and code review.
A Final Review of Project Estimation
So that’s it for today, but to summarise, if your SPG estimates are now under way, you should soon be receiving your bundle of user stories, epics, project estimation by complexity points and hours, average budget and team size proposals. We hope this article has served to clear that up!
Of course, these estimates are a very small portion of our wider Agile methodology, so just in case you missed it, why not take a look at this other article on our entire development process?
And remember, if you have any lingering questions or concerns, feel free to let us know. Our team are always available to help you in any way we can :).
