Chances are that if you ever asked this question you got a pretty vague answer. Many factors impact the time it takes to create an app. Learn what they are and find out how to estimate your next app’s timeline.
Planning is an important aspect of our lives. When will dinner be ready? How long is the movie? When will my new app be completed by?
We all do it. To be able to plan well, we need to have some notions of how long something might take. But planning and creating estimates it’s not something people do well.
It gets worst in software!
Due to the nature of app development, to create an accurate timeline you’ll need to know the details of the app. e.x. What will the list of items screen consist of? Will there be filtering? How about search? Will users be able to change its sorting?
Furthermore, no app will ever be exactly the same. We’re not building carbon copies of other apps. Even if we were, other factors come into play. So looking into industry averages as a reference is not a good idea.
In today’s post my goal is to help you better understand what contributes to a project’s timeline.
I will also walk you through an example using the process we use to estimate timelines. By the end of the article I hope you will understand how companies and how you can create an accurate timeline.
But before I get into it.
Why the need to know how long something takes?
There are many different reasons why. The most basic reason is to set proper expectations and to plan ahead. We want to know when something might delivered so we can start using, marketing or selling it.
Most of us report to other people and need to stick to their agenda. Knowing if a project is on track and when it’ll be completed by is one of the requirements. Unfortunately people in power create a lot of these deadlines without consulting the people actually doing the work. These deadlines are then passed down to others. If you been in that situation, you know how frustrating and stressful that can be!
But here’s the thing:
- People are terrible at estimating and planning.
- Looking at industry averages means nothing. Because one company delivered an app in 2 months doesn’t mean another company will deliver a similar app in the same amount time.
Most industry averages I see on blogs are created from a small sample of data. These surveys fail to specify what type of products they are working on, scope, technologies, or team expertise. There is no direct correlation between one project and another.
But how can you know how long something might take?
The truth is that you never know exactly how much time you will need. There are many unknowns and risks when creating software. As a result, many different factors can affect timelines.
Experienced teams that a have a history of working together can come up with more accurate timelines. Why? Because they use data from their own past projects to project into the future.
What affects an app’s development timeline?
This is one of the major contributors to how long an app might take. So what is the scope of the project? It is what the app should do and shouldn’t do. Not only the number of features affect the timeline but also their complexity. It also means what platforms and screen sizes it should support.
Because of the nature of app development, the scope will change and grow as the team dives into each feature.
Is the project filled with uncertainty and requires lots of research and development? If so, chances are timelines will be longer. The higher the uncertainty the greater the chances risks will come up.
What look and feel are you going for?
How important is the UI? Does the UI need to be spotless? Are custom graphics and design very important or a minimalist design will do? Apart from the aesthetics, how well do you know the target user? Have you done any user research? User Experience is key to create a good app but requires effort and time.
What’s your budget?
This is pretty straight forward, but sometimes it’s overseen. Your budget will dictate the length of the project. How much budget you have will dictate the effort a team can provide and how far they can support the app for.
Who’s in your team?
Team composition, experience and chemistry. How big is the team? What skills and experience do they have? Do they have experience working together? These affect how fast a team can complete a feature. Remember: A less experienced team might charge half the price but might take 4X the amount of time to finish it.
When are you done?
What is your definition of done? What are the quality requirements to ship the app? What are the features needed to have a complete product? Deciding what features go into the app is key, but also the quality and how thorough each feature is. These will affect how your users receive the app.
What development process are you following?
Different processes will deliver apps faster. An agile process will deliver shippable products after each iteration. In contrast, a waterfall approach will deliver a shippable product after the team completes all features.
Are you leveraging open-source libraries?
Is the team building everything from scratch or utilizing existing components and libraries? Developers can use existing tools to finish apps faster. If a team has to develop everything from scratch, development will take much longer.
What external factors are in play?
Most projects have dependencies like external teams or integrating with 3rd party services. Dependencies will affect timeline because the team can’t complete the work without them.
As you can see by the list above, a lot of factors can affect an app’s timeline. You might be thinking, how can we make any sort of plan if it’s nearly impossible to know the timeline?
There are some ways teams can estimate a project without having to know all details. We believe in creating products following an Agile methodology.
Developing apps with agile
Our process involves deciding on a timeline and price. We work with our clients until we’ve reached that deadline. Our goal as a team is to create the best possible product within that time frame and budget. What features that go into it are not decided because they might change. We work together to create the best possible product and how we can bring it to life in the shortest amount of time.
The agile approach is rather than fixing the scope, we fix our effort (resources and time). As a result, it’s easier for teams to react to market changes and to deliver value to customers faster. This transparency of constraints keeps both us and the client honest about a consistent and fast release cadence.
Typical mobile app development timeline — case study
For this example let’s assume we’re trying to create an Instagram copy. I’m choosing Instagram because I enjoy the app and I hope most of us have heard or used the app in the past.
To keep things focused, let’s imagine that we have already created a the project’s vision along with its success criteria. We have also developed a roadmap for planning.
At this point, we know what the purpose of the project is, how we’ll measure its success and what features will provide the most value.
Now we can get into estimating how long our project might take.
When we’re planning releases we group similar stories/features (epics). Because epics are composed of stories, we can estimate their complexity. We use relative estimation to estimate their complexity. We compare each epic to a base epic story and assign it a size. We know the size of the base epic, its complexity and how long it took us to develop. We use these factors to estimate the entire project.
Estimating a project’s timeline
Let’s say we had the following feature sets. Note: You might break them down differently.
- Authentication: Login, Logout, Forgot Password, Register
- Create: Upload Image, Add Filters, Add description, Add location
- Social: Add comments, Like, Share on social media
Our base epic, which was 2 pts in size, is similar in size to the authentication epic, so we assign it 2pts also. But, the Create epic seems like twice as hard so we gave it 4pts. The Social epics seems less complex so we gave it 1pt. Different companies will estimate things differently depending on their base story.
- (2 pts) Authentication: Login, Logout, Forgot Password, Register
- (4 pts) Create: Upload Image, Add Filters, Add description, Add location
- (1 pt) Social: Add comments, Like, Share on social media
Based on our previous experience, developing epics of 2 pts took one sprint (2 weeks). Depending on the team, this length of time might be 2 days or 6 weeks. Let’s say for us, it’s 2 weeks.
So, if we added our points, we would estimate to complete the project in 7 weeks (we finish 1pt per week).
As we start working on features, we start getting a better idea of how long things take for this project. The closer we get to completion the more accurate our estimates will be because we have more data. Every project is different so estimates will always be educated guesses.
So that’s it!
I’ve shown you what affects timelines and why industry averages are not a good indicative of how long your project might take. I also walked you through an example of how we estimate things in an Agile context.