Unpacking the problem
Estimating your project
Estimations should always be considered as just that - estimations. Anyone with experience building software knows that the unexpected often occurs during development and should always be planned for, in order to manage expectations. The best plan is to take a scientiﬁc approach that has allowances for the key factors that often impact a project’s timeline. These factors include allowances for risk, managing technical debt, allowing time for regular business operations and providing time for project-related work that isn’t development (for example planning and review meetings).
Estimating at its core can be managed in several ways, but it’s recommended to use a time-based system. A general rule of thumb when estimating is that the bigger and more complex something is, the less precise you can be. The time-based values follow a Fibonacci-like sequence. This is common practice within agile estimations to ensure developers don’t get too caught up in the speciﬁcs, and instead focus on relative scale versus other work. Splitting the estimations between development and testing effort can further simplify the process and allow developers to focus on the speciﬁc work item.
The more complex and unfamiliar a story is, the higher the risk that the time for development will be underestimated. To ensure that the risk is appropriately considered in estimations, these factors should be considered for each ticket to allow time for the unknowns. Developers estimating should score these risks parameters, to be included in all calculations. The risk factor is calculated based on the unfamiliarity and complexity of the of the story.
It is not uncommon for product features to change and even become more complex during natural discovery in the development phase. With that in mind, it is advised to provide an allowance for when the delivery team needs time to scope out new discovery or de-risk a concept during development. The discovery allowance is spent at the discretion of the delivery team and product owner. It will be used when the intent of a feature has changed, details deﬁned were insufﬁcient or are deemed too high-risk.
During the development process, teams are focused on delivering high-quality features at a deﬁned pace. This allows the team to ensure that features are delivered to the deﬁned speciﬁcation. However, defects and potential improvements outside of these requirements are a reality of software development. Experience has shown that all projects require periods of time, known as Iteration N, to address these defects and improvements to prepare for production. The length of time tends to directly correlate to the size of the project. Tasks performed during Iteration N tend to include tackling defects, addressing technical debt and implementing core improvements. These all share a common goal; improving product and code quality.
Also factored into a delivery allowance should be time for releasing the software. The most time-consuming release is to a production environment. The production environment is the ‘ﬁnal’ live version of the application.
The Launch Iteration (period of time set aside to releasing) begins the moment an application is ready to move to a production environment. Generally, the ﬁrst release will be the longest and will gradually decrease in time the more often the application is released. Typically, during the iteration, the team should be focused on resolving any outstanding issues blocking release, documenting the application, preparing for the Support team and quality assurance processes.
Within any commercial software operation, delivery teams can’t be allocated to their development work for all working hours. Activities like internal meetings, helping their peers and learning & development take up time and should be recognised when estimations are being considered. This time should be factored into an allocation factor that can be applied across all estimations.
The allocation factor also accounts for time that isn’t developing features but is still providing value to the customer. All scrum related meetings and time spent releasing to the beta environment form part of the allocation factor. It is expected that any allocation calculations will be approximate based on regular business activities, such as iteration cadence and standard monthly learning and development allowances