Estimation is difficult by nature. That is something we are all aware of. There are several blog posts and articles on the internet that explain why forecasting software development time is difficult, and you can read them at your leisure.
We get our estimates incorrect all the time in the Mammoth-AI team, and that’s fine with us — it’s the nature of estimates, after all.
We sometimes get them horribly wrong. Unfortunately, it’s in the nature of software development estimates to be severely wrong in the same direction when they’re terribly wrong: actual effort surpasses predicted effort.
Estimating the effort you need to put in
The explanation is straightforward: there is a limit to how much faster you can do a work, but there is no upper limit to how much longer it can take in comparison to your estimate.
If you predict that a work will take you three days, your best option is to complete it quickly and save three days. But the worst thing you can do is waste an indefinite amount of time on it. In practice, depending on the importance of the endeavor, you’d probably abandon your efforts after bashing your head raw against the wall for a week or two.
It’s easy to dismiss incidents of significant underestimate as one-offs as a group. However, following viewing a sufficient number of them, trends will appear that you can attempt to incorporate into future estimations.
Dealing with new UX designs
Major new UX design is something that our team has found that we consistently underestimate.
It’s not difficult to create a new page that looks like existing pages: a form with labels and textboxes, a few buttons, and we’re done. When we have to develop a whole new workflow, though, it always takes longer than we expect. We create something, test it, realize it’s clumsy, rework it, get comments from other team members, rework it again, realize we need to add another component someplace, rework it again, and so on.
What can we do to avoid this? We keep design and development separate.
Integrating unfamiliar third-party components
Any integration with unfamiliar third-party components is another task that has a tendency to go over budget. We’ve reviewed the documentation, examined the API, and possibly even built a prototype, and now we believe we have a solid notion of how to build the actual functionality. When we start doing it for real, however, all sorts of issues can occur.
The API does not correspond to the documentation.
The Error Messages Are Incomprehensible.
In subtle but significant ways, features that we thought we understood turn out to work differently than expected.
Investigating these issues can take a lengthy time because, unlike regular code, the component is a black box, requiring trial and error troubleshooting. It’s possible that support tickets will need to be raised and discussed back and forth, causing extra delays.
Third time’s a charm
We’ve had this issue twice in the last few years.
In all cases, the feature took at least three times longer than we had anticipated. We don’t have a better approach to estimate this type of labor because we’ve only done it twice, which is enough to establish a pattern but not enough to provide us with enough experience to improve from. We might just triple our estimate the third time, whenever that is!
For more info: https://www.qaaas.co.uk/testing-services/
Also Read: https://www.guru99.com/software-testing.html