After the project is estimated and engineers start development, everything looks clear. What could possibly go wrong? Read about challenges and pitfalls during estimations.
This is the second part of articles series How to Estimate mobile projects. Read also Part 1 — A step by step guide where we described the initial process of breaking down features and estimations.
The first 90 percent of the code accounts for the first 90 percent of the development time. The remaining 10 percent of the code accounts for the other 90 percent of the development time.
—Tom Cargill, Bell Labs
Changes and uncertainty
Sometimes, a project’s details change during development. Some changes are small (changing fonts or colors), some changes are large (adding an extra page or swapping screens). Changes themselves are not a problem, but they certainly affect the initial estimation. Sometimes, in order to make small changes, you need to rewrite a large piece of the system.
Read this developer horror story, which describes how many steps you need to take in order to change the text in the application that is already published in the AppStore.
Asking the team to estimate another feature…
The future changes are the things that nobody can estimate at the beginning of the project. Therefore, we must keep in mind that initial estimation becomes irrelevant when the project’s scope changes, which is the case in 90% of all projects.
Reinventing the wheel
The world of iOS development has lots of libraries that significantly reduce development time. We use libs like AFNetworking/RestKit, ReactiveCocoa, Runes, Themis, SDWebImage, SVProgressHUD, other UI controls, our own libs and so on. We can focus on the really interesting or complex components, and implement more valuable features before release. The more cool problem-solving libraries are in our arsenal, the more accurate our estimation is.
The mobile world is evolving so fast that we often google before implementing large components of the application, for example, how fast our favourite database is in the new version of iOS. Such research reduces the chance of stumbling upon unexpected problems during development and allows us to be in the know.
Some tasks are more time-consuming than they appear
Never underestimate the challenges that are associated with the real-world features. Among them are such things as time operations, especially with time zones, and specific hardware capabilities like cameras, GPS, push notifications or Bluetooth. It takes more time because development on a real device is “slightly” slower than on the simulator (although Apple tries to make our life easier every year).
In the same category we include integration with other physical devices such as an external microphone or smart watch.
Augmented reality and working with physical devices: that takes time!
Normally, embedding Apple services such as In-App purchasing and iAd doesn’t take a long time, and most developers think “it’s easy”, but it may take a long time to test, so we usually mark previously mentioned tasks as ‘time-consuming’.
In addition, the application won’t submit itself to the Store. We add several hours for submission to the overall estimated time. This is especially sad when you have to take lots and lots of screenshots for each localization, but now we can open up the fastlane tool, and things go much faster. Needless to say that it’s easy to forget something in the pre-release atmosphere, so we have created a ‘before submission checklist‘ to keep things in one place.
Must-have features that are always forgotten
What features are present on 80% of the applications, but are often forgotten during the estimation? Screens with a bunch of texts, such as the FAQ, TOS, license agreement and disclaimer. Alert-reminders asking users to rate an application and leave some comment in the store. A “contact us” button to send an email. These features are ‘easy’, but you should put them on the list, too.
Gathering usage statistics is very important in order to make the right decisions in the future. The simplest way is to track each screen opening and the pressing of every button. But sometimes you need to collect more complex events to calculate conversion or to understand whether the design works as expected. To do this, you need to think about what kind of events statistics will be useful and to integrate analytics tools (like Flurry, Google Analytics or Mixpanel).
Communication and documentation also take time
Developers usually estimate only the technical side of the story. Time spent on communication is also important. For example, often it’s necessary to design server-client API before starting the development phase, but sometimes API documentation is being designed on-the-fly. It takes time to coordinate teams, especially if they work remotely. In this case we don’t estimate ‘communication’, but ‘creating/updating API doc’.
According to the agile manifesto, working product is more important than comprehensive documentation, but it doesn’t mean that docs should not be created. When we estimate complicated features we don’t forget to add points to create the documentation. Talking about client-server interactions we often create sequence diagrams. Reading such diagrams instead of digging through the code trying to figure out what’s going on, saves hours, but creation of the diagram also takes time.
Unpredictable team factors
Teams make mistakes. More often the team underestimates the complexity of the task, but sometimes they can overestimate it. A few tips on how to reduce this risk to a minimum. Permanently increase the level of the team (gain more Exp!). More projects estimated and done means more XP gained. Besides, it is important to conduct the retrospective team meetings to try to figure out the reasons for inaccurate estimates. Also, communicating with other teams, listening to their experience and mistakes, helps. And of course, reading a variety of developer resources daily or weekly to monitor community’s pitfalls and trends is also helpful.
Team changes are unpredictable…
Teams change. Swapping horses when crossing a stream is obviously a bad idea. It’s not a developer’s fault if one team estimated the project, but another one is going to develop it. Unfortunately, it happens. In this case, it is necessary to discuss and re-estimate the project with the new/updated team. Well, it seems like a waste of time, but in fact, it makes it easier to navigate in the project timeline and to understand the schedule before it gets too late.
Iterate and re-estimate
We talked about rough estimates in Part 1. In fact, agile project development involves continuous planning and evaluation sessions every sprint or two. Those features that were rough estimated should be re-estimated in more detail, taking into account the knowledge of the system that has emerged.
Features estimation, implementation, and estimation analysis are a part of the development cycle. The team gains XP and reduces the risks associated with every new project estimation.
Well,
in the developers’ world, there are many factors that affect the project’s estimation at the different stages. Unfortunately, it’s impossible to take all of them into account. Fortunately, we know many of these factors and know how to minimize risks.
On the one hand, it is crucial to improve the team constantly, creating various and complex projects, sharing practices with other teams and absorbing their experience. On the other hand, development should move by small iterations, constantly keeping one’s eye on the ball to see the possible divergences from the plan as early as possible.
Want to start your own project? Let’s talk.
