In part one of this series, The Art of Accurate Software Estimation, I introduced my goal of understanding and minimizing the challenges of software estimation. I also presented some of the context considerations that the business environment influences. In this post, we continue this endless quest of an accurate estimate with consideration for other contextual perspective regarding some of the things that are often neglected when attempting to compile an estimate.
The technical development effort is only one aspect of what it takes to deliver working software. While it is certainly the largest portion of a project, it is very important to consider the time and resources that will be responsible for all the other aspects of delivering a successful software project. Setting a clear expectation of how the development team’s estimates will be used in relation to these non-dev related tasks will help the development team focus more clearly on exactly what they are estimating, the development effort. Here is a list of things that project managers need to consider in addition to technical implementation:
This is a measure of time per day in which 100% productivity can be reasonably expected. Since 100% productivity is a myth even when 110% effort is being applied, it is safe to say that a percentage of time must be accepted as unproductive. Bathroom breaks, a unexpected lunch that runs over, a production crisis that requires immediate attention, team morale conversations and any time prior to coffee consumption, among other things are all reasonable contributions to this percentage.
Process and Planning Meetings
The focus of all process and planning meetings is to both improve team productivity and communication of requirements. Without getting too deep into agile, one of its most important tenants focuses on constantly improving the process. This is applicable in any organization, and is one of those vitally important aspects of the overall success of a project. Make sure to account for the time it takes to understand, evolve, and improve the process.
This is the attempt to measure the likelihood that requirements will change after some piece of functionality is delivered. While wireframes and design comps help minimize these revisions, every organization will find that they once they are using some piece of functionality they now have a better perspective of how it would work better or may even find that they want something drastically different. Any large scope changes will miss delivery dates on a scale proportional to those changes. If this is something you can expect, and all software projects should expect this to some degree, then we should be planning time for client revisions.
Projects have a choice between heavy reliance on manual testing, non-developer UI automation driven by QA staff, or greater reliance on developer written automated acceptance tests. Manual testing is the most monotonous and over the long term could lead to serious deployment delays. Pure UI automation tests written by QA staff requires expensive software and is very fragile, but can be effective. But over time, software development is shifting more and more towards automated acceptance testing, where fewer QA staff ensure that the development team is writing appropriate unit tests, automated smoke tests and automated regression tests, jumping in with hands-on QA when necessary. When done correctly automated tests make for bullet proof applications that are easy to change, enhance and extend. No matter how your organization decides to handle QA, the time it takes to ensure a quality product should be included in any responsible estimate. And regardless, unit testing should be considered a non-negotiable quality assurance practice, meaning that development estimates should include time for writing them.
In the context of a highly scalable web application scale costs a lot of development time. For example, think about the architectural considerations and the enormous expense that Facebook has had to invest in as they have scaled to hundreds of millions of users. Building Facebook for 100 users seems pretty easy, while hundreds of millions boggles the mind. Understand what scale is being targeted and communicate this to the development team to minimize production environment crisis, or overblown solutions that will never see even 10% of their potential scalability.
Cost of Maintenance of Live Software
It is a safe assumption that bugs will be found in the production environment. Not all of these will need to have immediate, stop everything and fix this bug treatment, but some will. These types of escalations are always more costly and far more unpredictable once we have live data. It is important to understand how these production issues might influence the course of active development projects, and some best guess consideration for these types of stop everything bugs should be considered in the final estimate.
These artifacts of the development process are often overlooked, or externalized as something the development team won’t have to think about. In reality, the more your entire team understands these additional aspects the better. It improves confidence with the overall process, it allows the technical team to focus on the effort of delivering functional code, and it sets a great context for thinking about what it really takes to deliver a professional and production ready system. These considerations provide an excellent segue into the subject of our next post in the series, Setting a Clear Expectation of Done.