IT projects, whether they’re a new app, or even the installation of complex technological systems, can be exciting. It’s a new world waiting for you to build it.
However, learning how to estimate the resources needed for an IT project is crucial when you’re working with clients, on a limited budget, or simply when you want to stick to the resources you got.
Today, we’re taking a deep dive into estimation, why it matters, and how to do it right.
Why Estimation Matters
abac was born out of a desire to create amazing, innovative software. That’s what we were always striving for, and while we still aim for that, only focusing on the product wasn’t viable when we hit the market. There we were, dreamy, focused on functionalities, while all of our clients seemed to always be in a rush.
They’re not asking “When will that be ready?” or “How much longer until we can launch?” in vain. These questions have good reasons behind them.
Imagine you’re a client in need of a new app. You contact a software development team, like us, and we get back saying that we can create apps in 3 months or 3 years, depending on a myriad of factors. This uncertainty is a big pain point for businesses, because they also have a lot of dependencies to take into account.
For starters, there’s timing. A lot of markets only have a short window of opportunity for specific projects, so it’s crucial that an IT solution is delivered within a predictable timing. Estimation can help your team understand when an MVP can be ready for investors, as well as when the full product will hit store shelves, so you can better gauge your chances of success.
On top of timing, cost is important as well. No company has unlimited resources, and if you pay your software development team by the hour (whether it’s outsourced, or in-house), you need a way to estimate how much resources poured into that team will be required to create your final product.
These are just some of the reasons why estimation should be something your development team is focused on. Now, let’s see how to do it.
How People Used To Do Estimation
The manufacturing world managed to achieve high-quality estimation through standardization, restandardization and the fact that machines can be used to process raw materials into finished products all the same millions of times over.
That’s why it’s easy to look at the hours spent on the assembly lane and translate those hours into profit. The IT world tried to do the same, but it didn’t work. In IT, creative work and troubleshooting can mess up your calculations really fast because, well, people are not machines.
Up until recently, “ideal man hours” was the estimate assigned randomly to a project, or part of a project. In short, “ideal man hours” is the time ideally spent by people on a given project. However, this metric was a ballpark at best, since it only relied on somewhat educated guesses and experience for it to work.
Luckily, developers and startup owners don’t need to rely on ideal man hours any more, because we have better systems available. Let’s talk about those.
How To Estimate Effort The Right Way
A user story is an informal description of a feature, as seen from the perspective of the end user. It’s important to keep user stories in mind, because they can be used to more effectively measure the effort put into your IT project.
But more importantly, the concept of a user story is a standard. It’s a solution to account for all scenarios that a user might be in, and it’s a crucial standard to communicate functionalities if you need a software company to estimate an IT project.
And no, user stories don’t just apply to frontend elements. The backend has an impact on how users experience a product, so basically any project you have can be broken up into smaller user stories.
Now for using them: You can assign story points to all of your project chunks.
Let us explain.
A story point is practically an integer used to denote the overall complexity and effort needed for any developer in a team to implement a user story according to the team’s established definition of done.
The most common integer values attributed to story points are the ones that can be found in the Fibonacci sequence, mainly 1,2,3,5,8,13,21 and so on. The values are attributed this way in order to generate a sense of magnitude for the development team, as each number in the Fibonacci sequence is the result of the sum of the previous two numbers.
So how would this look in practice?
After a project’s details are laid out on a requirements document, and the user stories are clearly defined, the development team sits down for a meeting to calibrate the value of story points. This is just to get a sense of the user stories, what a 5 or an 13 integer might mean for that specific project, and to start assigning integer values for all user stories.
After that, the team needs to understand its velocity. Velocity refers to the number of story points a team can deliver within a predefined time frame, and it might be trickier to identify than any other metric. That’s because before you start a project, it’s a bit harder to understand accurately what a team can do. However, this gets better in time, so assign a value as best as you can starting out, then keep improving upon it the more you work with a specific team.
Then it’s off to work.
But estimation is not over. This type of meeting shouldn’t just happen in the beginnings of a project – it should be repeated weekly, or even more often than that, to assess progress and recalibrate the user points assigned to each story.
Cost Estimates
Beside the effort output of a development team, clients and development teams also need to understand the costs of a given project. Setting-up an efficient story points system will help here as well, and they’re also inter-dependent. A user story system is formulated based on costs.
Calculating estimated development costs can be done by first dividing the total number of story points estimated to the velocity of a team in order to find out the number of iterations needed, and then multiplying the number of iterations with the total number of development hours that will be billed by the software development company.
That might sound a bit complicated, so let’s use an example to drive the point home.
For a project that already has an estimated story points count – let’s say 500 – and an established team of developers – let’s say 8, which work full time, and can output work equaling 160 story points per week – all you need to do is add in the price.
So if your developers are working for 50 euros an hour each, and can finish the project in 3.1 week (500/160), or 15 working days, it’d all cost 48,000 euros.
That’s because you multiply the working days required to finish the project with the number of developers, and the price/day of each developer (400 euros, in this case).
It’s also important to implement a user story system to achieve clarity and a better collaboration with clients. When a business sees “100 hours” billed, they can’t picture the amount of work and resources involved behind. However, in a backlog of 100 story points that a team can deliver in 4 sprints, any client can see progress, because they’re noticing each iteration.
Conclusion
We hope this article shed some light on how to estimate the resources needed for an IT project.
And remember – estimating the resources needed for an IT project is not easy from the get-go. It’s important that you always take a look back and recalibrate measurements with more data.
_________________________________
The most important thing to start developing an IT project is formulating user stories. A user story is a description of a functionality (or that of a user scenario) for a specific user, explained without technical terms, to be easily understood by both the client, and the development team.
Story point = the needed effort to implement certain functionalities.
User stories from the backlog will be processed by the development team in 2 week iterations (also known as sprints). These iterations can be shown to the client in demo sessions. This way, we can make sure that we receive, and implement, feedback from the client.
Velocity = the speed at which a specific team can implement a set of functionalities.
