Software estimations - getting to know your product better
Software development estimates are one of the most important factors during the investment process. A lot of people are involved and usually each of them has varying expectations, e.g. defining the scope of the project or information about time and budget constraints needed to deliver the final product. However, the final objective is the same: to create a successful product that meets the business goals. In this article, we want to show you why estimates are so crucial for both sides - clients as well as for development teams.
Table of contents
We are going to point out some difficulties that occur quite often and how to deal with them using best practices and some expert tips. We will share the methods which we use to better prepare for sales proposals, define projects’ scope, sprint plannings and more.
Why do we need estimates?
Because they are with us throughout the full cycle of building a software product - beginning with rough evaluations without much detail to very accurate and precise information from the development team. Without them, a business cannot decide if it is worth investing and building the product or even which development direction is the best within the defined time and budget constraints.
Steve McConnell, an author of software engineering textbooks summarizes it well:
A good estimate is an estimate that provides a clear enough view of the project reality to allow the project leadership to make good decisions about how to control the project to hit its targets.
What kind of decisions or actions are made based on estimates? Here we list a few examples:
- Planning the budget and time boundaries for the project.
- Building the team with required competencies (e.g. specific technical skills, marketing expertise, analytical skills).
- Planning capacity (including holidays).
- Setting objectives within the company (e.g. related to the project).
- Prioritizing functionalities using their estimated ROI.
- Building a road map.
- Defining the scope of the project (e.g. for a first release).
- Planning the company budget.
- Preparing metrics necessary for measuring the success of the project.
…and so on. As you can see, following a software estimation there is still plenty of work to be done. No worries, focus on small steps.
The additional values of estimation
Besides the above mentioned uses of estimations, there is more value for both parties, both the investor/company and development team, that significantly increase the trust and quality of cooperation:
Transparency - as everyone is on the same page it is easier to talk about features, negotiate the scope or change direction in case of new opportunities.
Known risks - in a process of software estimation, usually some risks appear and thanks to that the company can be better prepared for and take into account these risks.
Known standards and quality - if it is the first step in a collaboration, the estimates give you great insight into how the development team works:
- what experience they have,
- which factors they include in the estimation process,
- what solutions they come up with,
- are they goal-oriented and understand your business objectives?
Common understanding between business and IT departments - this topic is worth explaining a little further.
As Steve McConnell said:
..when executives ask for an ‘estimate’, they’re often asking for a commitment or for a plan to meet a target.
It is important to build an awareness of the distinction between them to avoid possible misunderstandings and problems with a too-tight timeline or undelivered products.
An estimate is a prediction based on experience, historical data and a lot of assumptions that have to be validated (often during the development process).
It is not possible to forecast all the impediments which may cause delays or, in best-case scenarios, new ideas that help to sort out problems much faster. Example: Usually we do simple landing pages in 2-3 weeks, but this one is more complex, so we think it will take one week extra.
A target is related to a business objective, a goal. Example: We need it before the summer season.
If it is possible to deliver a product faster - great news! On the other hand, any delay can lead to a decrease in the ROI or leave the product out-of-date.
A commitment, however, ought to be an outcome of both the estimates and a target - it is like a promise. The team must ensure that it is capable of delivering the product to a specific level of quality and set a deadline for delivery. Example: We are able to deliver the first version of the product with four main functionalities by the end of May.
So as you can see, a commitment should be a result of cooperation between the IT and business sides - shared understanding helps adjust solutions to current business needs and opportunities.
Why are estimates so tough?
It has already been shown that estimates offer huge value for the business, developers and the whole project, but also bear in mind that it is a truly complex process for the team. So, where’s the catch?
Software development is not a routine process with solutions for every case - quite the opposite! The key is to figure out how to use available technologies, tools and resources to build great products.
Common problems and challenges
Estimates can vary between team members
Varying technological expertise and know-how in specific areas could result in very different estimates from different team members. A person who already has experience in a similar project or business approach may feel more confident about the time/budget needed to create a product. Another individual might have a different perspective and won’t agree with the other’s evaluation.
If it is possible, the best way to handle this problem is to commission estimates from the team that, eventually, will be responsible for delivering the product. They will be aware of the objective, know the scope, and have already discussed the technology approach in detail. It also saves time to explore the whole idea from scratch.
Another way is to gather a few specialists and confront their distinct views of the matter. A method worth mentioning is Planning Poker as it gives everyone a chance to justify their opinion about the project’s complexity, threats, additional opportunities, and strengths and gives a broader vision of the project.
All the assumed advantages or risks should be written down and delivered to the final team before development.
Estimates are delegated to less experienced team members
It was mentioned above that estimates shouldn’t be a task just for one developer or specialist. Especially if this person is a junior or significantly less experienced person than their colleagues. Why does it happen? Because without an awareness of the value and consequences of the estimation process, people take it lightly and treat it as a painful duty.
The first thing is to show all the benefits and how important those assessments are. Get a mixed team of experts and less experienced members as this is an amazing way to learn new techniques and show how the business works. The more senior team members are able to point out more unforeseen issues; e.g. with performance, libraries, environment, architectural imperfections, API integrations, and so on.
It has to be noted that no project has the same:
- requirements,
- team composition,
- business context,
- technology,
- priorities & constraints.
So, the team should be creative and never be stuck in a routine - additional questions and a fresh look from new colleagues is often really appreciated.
Not including non-dev actions
Don’t forget about all the tasks that take place during the development cycle. Besides the programming work there is much more to do:
- Scrum meetings (in Scrum methodology),
- manual and automatic testing (including debugging and rejections),
- UX and UI design,
- additional communication with stakeholders,
- courses or training,
- holidays, vacations and sick leave,
- obtaining the needed technical resources,
- other current tasks with high priority,
- … and so much more
These factors are crucial regarding further planning and setting a timeline.
The feeling that we know everything
Early estimates are vague. During the development cycle, we discover more about the product and gradually receive better numbers from the team. It allows us to react and adjust the plan to the new data and information.
Steve McConnell introduced this situation as the ”cone of uncertainty”:
What we see here is that the biggest uncertainty occurs in the phase of building a general concept. The cone narrows when we better understand the product - when the team refines the requirements, creates designs and asks more questions. During implementation and testing, new and unforeseen issues may arise that have to be tackled. Eventually, the finished sprint and/or release gives us data useful for metrics and enables us to draw conclusions.
At Boldare, we work with a lean approach which helps us to react as quickly as possible when new opportunities pop up. It means that we are ready for any changes that lead to improving the quality of the product or decreasing the risk of achieving the business goal.
How can you estimate more effectively?
Depending on the phase of the product, we can use a variety of techniques - from those focused on general principles to the more specific.
General estimations
- Use the historical data from previous projects - seek analogies from finished products and benefit from the lessons learned.
- Rough estimations from experienced developers - this is a ‘good-enough’ approach if estimates are needed ASAP and/or we do not have enough information to be precise. Write down all assumptions and consider time estimates in terms of min and max ranges.
- Break down the features and requirements and estimate them separately - by dividing a project into smaller modules and functions, it is much easier to determine the time necessary to develop them.
- Along with the project, all assumptions will be meticulously discussed and re-estimated within the bigger team. For this, we use and recommend methods like Planning Poker (mentioned earlier), T-Shirt Sizing or White Elephant Sizing.
What information could help?
Besides the project’s business goals and requirements, you can provide your team with more information in order to help them find the bigger picture. With additional information people are able to suggest more accurate solutions:
Vision - This describes the purpose of the product, the reason why you want to build it, and what kind of problems you want it to solve. Describe how you envision this product in the next few months and years - that gives a broader perspective and helps with choosing the right technologies and architecture, and keeps in mind the future possible extensions. It is also inspiring and motivating for people - it is really exciting to think about a project that will support other people in their work on a daily basis.
Target users - Once the team knows the ‘WHY’, it’s time for the ‘WHO’. Who is going to use the product, how will the users benefit from this solution? Where are they living, what are their interests, their favorite movies? Get to know your users better and share this knowledge with the development team. Thanks to this input, it is easier to focus on the main users and those functionalities important to them.
Budget - This information will be really helpful while thinking about the team’s structure, possible solutions and the final scope. The development team may also find that it is not possible to create such a (let’s say) complex product within the proposed budget (which also saves the time needed for additional analysis). If this happens, you can think about reducing the range of functionalities or try to renegotiate the budget.
Time constraints - Thanks to this information, it is easier to predict how many people we need to involve, making it possible to deliver a specific scope for the work within a given time period. Sometimes when constraints are really tight the team splits the scope and commits to a part of the project that can be finished before the settled date and the rest is delivered after the product release. It is also important to include all holidays and vacations that may occur during the development process and prolong it.
Boldare approach
First contact
What does all this look like here, at Boldare? The first estimations we provide are included in the proposal. They are based on all the materials we receive from the potential client and a call during which we ask a lot of questions and analyze needs. It is a crucial phase, as we need to know how we can help and suggest the best tailor-made solutions.
Solution architects prepare the overall concept of the project and, together with our specialists, discuss ideas and estimate the requirements. We anticipate all assumptions and risks that must be addressed in advance of the development cycle.
Along with the proposal, we point out the stage where we are going to start. We work with a lean startup-based Full Cycle Product Development process, starting with a Prototype and MVP, through Product-Market Fit to Scaling. It helps to focus on the main goal of the product for each phase.
As soon as we have a proposal ready, a sales executive presents it during another call and asks the client for feedback. Sometimes when business requirements change, the deadline is closer than expected or new investors appear and we adjust the offer to better suit all needs.
Cooperation
At the beginning of the cooperation, we always organize a Product Discovery Workshop with all final team members. It is the first opportunity to meet each other, work together and meticulously go through the project and its details. As a result, the team gains general knowledge about the business as well as the product, the technology is chosen and the initial product backlog is prepared.
With the created backlog, tasks are assessed again, but this time with more information and fewer unknowns. Thanks to the scrum framework we use on a daily basis, we always conduct meetings that help keep us updated with the project’s progress and the budget. We monitor burndown charts, refine the tasks and re-estimate them again when new details or ideas come up.
So as you can see, estimation is a process that continues throughout the whole development cycle. It is important to come back and look at the estimates from the perspective of a completed feature or product - historical data is priceless in terms of future estimations and improve the team’s estimation skills and accuracy.
Tips for better estimations
Just before you start your next estimations, here are some pro tips to make the process a bit easier and more efficient:
Compare the solutions - if you have worked with a particular technology or in a specific industry, you are more likely to envision the scale, complexity and potential impediments.
Review the estimates after the launch - that is the moment when you are able to see the gap between the initial estimates and final delivery time.
Prioritize tasks - prioritized needs will be helpful when considering any time and budget constraints.
Stay agile - update estimates after any changes are made to the requirements or project scope to stay on track and continuously measure progress.
Parkinson’s Law:
Work expands so as to fill the time available for its completion.
Summary on software development estimations
To sum up, estimates are useful and need to begin with the investment/business decision phase as well as during development (in line with agile methods). Accurate estimates are a huge challenge, so the best we can do in order to improve that accuracy is to cooperate and draw conclusions based on experience and metrics.
References:
https://stevemcconnell.com/blog/17-theses-software-estimation/
Steve McConnell: Software Estimation: Demystifying the Black Art
Share this article:
