The software development world is fast and dynamic. New innovations keep flowing in, and we need to make sure we use our timeline effectively. To achieve proper planning, the first step is to perform an estimate for that innovation whether it’s a feature or a project. Performing a good estimation is a skill that can save time and nerves for company leaders, developers, and managers. It ensures the smooth delivery and execution of a project with predictable timelines. So how do we achieve it the proper way?
Estimate Types
First of all, we need to say this: An estimate is a probability measurement and not an exact number. We can only predict it with a certain level of accuracy. What accuracy level do you need for that estimate? Estimates can be of two main types: high-level estimate and low-level.
High-level estimates, also called a T-Shirt size estimate, is an estimate that is usually given in the early phases of a project. It can be useful to predict a long-term company schedule for a quarter or say a year. A high-level estimate is usually given without a full dive into the project or feature details; the requirements can even be as simple as just one line of text or an acceptance criteria statement. A lot of assumptions are used to complete the full picture. Low-level estimates, on the other hand, are estimates that are used for later phases of a project. For example, this can be an estimate before the beginning of a two-week sprint or an iteration. It can be used to schedule the immediate work for a development team. Low-level estimates require a more serious dive into the project or feature requirements to understand business context. It should contain UI design, mockup, or detailed writeup specifications that will allow to cut the feature into smaller pieces.
Technical Decomposition
Once the requirements are known and available, it’s time to perform technical decomposition.
The decomposition is a process of converting business requirements into a work breakdown structure containing coding, testing, and other development work necessary for feature implementation. Depending on the type of an estimate, the decomposition can be also high-level and low-level. High-level decomposition may be grouped by major modules, services, and subsystems to be built, whereas low-level decomposition may include modifications in classes, UI widgets, creation of particular test cases, and other granular activities.
Dependencies
When the work breakdown structure is defined, the next step is defining dependencies for each activity on the list.
Dependencies can be internal, between the tasks in the decomposition, or external, if the tasks depend on other activities that exist outside of the scope for the defined feature or project. When dependencies are defined, it can be convenient to map them into a network diagram for better visibility. To learn more about network diagrams, please check out the related article in this blog channel.
Estimation Techniques
Next step is a key step—defining an estimated effort for each activity on the list, a particular number that would clarify the value in man-days or story points. Multiple techniques can be used to define level of effort. Let’s review some of them.
- Use expert judgement. This technique implies creating an estimate by someone who creates a number just by pure judgement or guess based on their previous experience. Such an estimate is simple but the least accurate. More effective techniques exist to make it more accurate and precise.
- Planning Poker. This is a very popular and quite effective technique to define an estimate. Multiple people provide their estimate for work independently in multiple rounds. In the first round, there can be a major deviation between values from multiple team members. The members that have estimates very different from others should explain the reason why that they provided an estimate with such deviation. After that, discussion can be held where team members discuss whether those explanations are reasonable or irrelevant. Follow up rounds will be held to account for thoughts and discussions. After multiple rounds, estimate values usually get balanced to a median.
- Historical reference – this is probably the most accurate and effective technique of estimation. In order to estimate a feature or project, some very similar or identical feature or project that was already performed in the past can be taken as a basis and estimate is performed based on its final consumed development time. If the feature or project are similar but not identical, the prorated points can be used to define parts that can differ, more on that in the next point.
- Team performance on similar tasks – this technique assumes that there was a work history for a team that is participating in the development. First, based on the complexity of tasks the team performed in the past, conditional points are assigned to measure relation between the tasks size and the timeline of their execution. After that those measurements are applied to the new tasks that are estimated, prorated to their size.
- Industry experience – this technique can be relevant if the project or teams are brand new and there is no historical data to rely upon. In that case an industry relevance can be used to estimate projects or features of similar complexity and scale.
To learn more about estimation techniques, I highly recommend a book by Steve McConnel called “Software Estimation: Demystifying the Black Art “. It contains a drastic description of all the techniques mentioned in this article. If you want me to go over some of the techniques mentioned in this article, or suggest more techniques let me know in the comments to this article.
Presenting Estimates
Some developers prefer to perform estimates, especially for High-Level, as a single number. However, I would recommend doing it in multiple records where each record identifies the nature of the job that needs to be done and its required specialization. The type of work can be development, QA, and specialization can refer to a particular area of the system that requires certain expertise. This will make it much easier and accurate for project managers to later map it to development teams and resources in schedule. Please take a look at an example:
Despite the estimate being ready you may want to also account for the risk factor for the estimate delivery. To do this properly please check out the article about the way to account for risk in estimates in this blog.
If you want to discover this topic in full depth, please also check out the video version of this article. it is available here:
More Information about Planning and Helpful Insights
To subscribe to new content use links in About Us page. Also check out this blog for other articles related to Software Development planning!
