Essential questions for high-level estimates

As a software engineering manager, creating high-level estimates is essential for planning and budgeting. However, estimating can be tricky when you don’t have all the necessary information. Asking the right questions is critical to uncovering relevant details that can impact your estimate accuracy. 

The challenge with high-level estimates is that you usually only have high-level information at the requirements level. That doesn’t mean you can’t aggregate more high-level information and consider risks.

That’s where asking the right questions comes in! In this post, I will list questions you can ask requirement providers and engineering teams.

These questions will help clarify critical expectations from requirement providers and support engineering teams in understanding the effort that might be required.

Before you go, here are some older posts you may also be interested in:

SEM Blog | Seven Estimation Techniques for Software Engineers

Understand what level of estimation maturity your organization adopts and some alternatives for improvement

blog.pplupo.com

SEM Blog | The first rule of estimations: Know thyself

Understand your dice bias before rolling it.

blog.pplupo.com

Questions for requirement providers

Requirement providers can be users, user representatives, product owners, clients, product managers, and other roles. They are the people in the organization that usually tell engineering teams what needs to be built.

Problem perspective:

1. Can you describe the problem you are trying to solve (not the feature you want to build)?
   Understanding the problem that the project aims to solve can help you to identify the project’s scope. Very often, requirement providers focus on explaining the solution they envision and don’t explain the problems they are trying to address.
2. Are there any requirement providers that should be consulted for this estimation?
   Sometimes requirement providers focus on what they are experts on and forget about other parts of the system that might be affected by the changes, especially when these areas are not at the core of what needs to be implemented.
3. Are there any existing systems or tools, internal or external, that will be integrated with the software or features being built?
   Knowing about existing systems or tools that will be integrated with the software or features being built can help you to estimate the effort required for integration.

User perspective:

1. Who will be the end-users of the software, and what are their needs and expectations?
   Knowing the end users and their expectations can help you to define the features required to meet their needs.

Quality aspects:

1. Are there any regulatory or compliance requirements that must be met?
   Regulatory or compliance requirements can impact the scope of the project and the estimated time needed to complete it.
2. Have you established any non-functional requirements, such as performance, security, usability, scalability, or availability, that need to be considered? In case not, should we adopt the organization’s minimum standard?
   Non-functional requirements are essential to ensure the quality of the software being developed. Asking for these requirements can help you to identify the project’s scope and level of complexity.
3. Are there other artifacts that need to be produced that the organization doesn’t usually build?
   A new project may require documentation that has never been built before, or maybe the documentation must follow a client’s specific template in this project.

Cross-team collaboration:

1. Do you expect the engineering teams involved to provide training to support teams or other personnel?
   Providing training to support teams or other personnel can impact the estimated time needed to complete the project.
2. Are there dependencies on other requirement providers that may not be fully dedicated or available during the project?
   The availability of required personnel may affect the estimations and impact deadlines.
3. How many releases do you expect? Just one, or do you expect one MVP and multiple releases?
   Understanding the expected number of releases can help you to estimate the project’s overall duration and resource requirements accurately and engage DevOps and release management teams in the estimation activity.

Questions for Engineering Teams

I guess it goes without saying that the answers you get from the requirement providers must be relayed to the engineering teams. Otherwise, what would be the point of gathering all this information?

Once this information is combined with the functional high-level description (hopefully not a one-liner), your team may be able to provide a high-level estimate.

The questions below aim to make them think of different scenarios, consider risks and assess other concerns that may impact their estimates.

Requirements:

1. What is your understanding of the requirements and scope of the project?
   Asking about the team’s knowledge of the project requirements and scope can help them identify any potential misunderstandings that could impact the estimate’s accuracy.
2. Are there any similar products available that you can look at?
   Knowing about similar products can help the team to estimate the effort needed to develop the software and create a better high-level estimate.
3. Have you allowed time for changes or additional requirements that may arise during the project?
   Accounting for changes or additional requirements that may arise during the project can help you to create a more accurate high-level estimate. They don’t necessarily need to do that (and may not even be the best people for this job). Also, depending on your processes, this can be worked out during the project. However, it is essential to know IF they are including time for that or not.
4. What else will have to change to keep consistency across the system?
   This is a very contentious point regarding scope creep. This is when your client says “Yes, I asked you to change this, but we can’t have it different from the rest of the system. I thought it was implied that you would change this everywhere else.”

Technical aspects:

1. What languages, tools, and technologies will be used? Are the teams familiar with them? Will training be needed?
   It’s essential to understand the specific technical requirements of the project and the expertise required to execute it. By identifying the technologies involved, the team can evaluate the existing knowledge of the team and whether additional training will be needed to complete the project effectively. Without this information, the team might underestimate the project’s complexity and, as a result, underestimate the time required to complete it.
2. Are you familiar with the architecture of what will be built?
   Understanding the project’s architecture includes its components and how they will interact.
   Very often, especially for product-focused organizations, projects are tied to modifying existing systems. Even in new projects, knowing how the architecture will be defined at a high level is essential, as it will impact productivity and may require training.
3. Is it integrated into the current platform/systems? What are the integration points?
   Many software projects need to connect to existing services, whether third-party or in-house. These services may not be well documented or may even require changes. By identifying the integration points, the team can assess the level of effort needed to integrate the changes with these systems, as well as any potential risks or challenges that may arise.
4. What are you assuming can be reused? What is the chance it can’t be reused, and if not, what would the impact be?
   Reusing existing components or code can save time and effort during development. However, it’s also essential to consider that some of these components might not be reusable, which could have a negative impact. By evaluating the chances of reusability, the team can make a more informed estimate of the project’s effort and timelines.
5. What will need to be changed?
   Requirement changes require various artifacts to change during the project lifecycle, such as code, tests, documentation, and other technical support materials. Often this requires teams to look for existing artifacts and documentation, which also helps with better estimates.
   Scoping this appropriately enables the team to plan for and mitigate the impact of these changes on the project’s timeline and ensure that the necessary artifacts are up-to-date and aligned with the project requirements.
6. What is the impact of the changes on components, services, or systems, that are not supposed to change?
   It’s important to identify unwanted side effects.
7. What are the key technical challenges you anticipate, and how will you overcome them? Which ones, internal or external, could significantly impact the timeline?
   This is an open question to allow the team to identify and prepare for any technical hurdles during development. By discussing potential challenges and solutions, the team can get a better understanding of the project’s technical requirements and identify areas that might require additional resources or expertise.
   It also helps identify risks, potential mitigations, or contingency plans.

Collaboration:

1. Are there dependencies on other teams or specific people that may not be fully dedicated to this project?
   Identifying any dependencies on other teams or specific people can help you to create a more accurate high-level estimate by accounting for potential delays.

Quality:

1. Have you estimated the time needed for in-sprint testing, fixes, and adjustments required?
   In-sprint testing and fixes are essential for ensuring that the software is being developed to meet the requirements and is high quality. It’s critical to allocate enough time for this work.
2. Given the number of releases expected, are you including time for deployment, pre-release (regression) testing and non-functional testing?
   Deploying, testing, and releasing software can be time-consuming, mainly if multiple releases are expected. It’s essential to allocate enough time for these activities to ensure the software is released with high quality and without significant issues.

Special considerations

Once the answers have been provided, document them. Analyze them and consider which ones should be treated as assumptions accompanying the estimate. Don’t just provide the range (yes, aim for a range instead of a number), but explain where these values are coming from and validate the assumptions with other stakeholders. Also, communicate all the risks that have been identified, potentially with corresponding treatment (contingency and/or mitigation), probability, and impact.

Conclusion

In conclusion, creating accurate high-level estimates for software development projects requires a thorough understanding of the project requirements and potential risks. By asking the right questions of requirement providers and engineering teams, you can uncover critical details that impact the estimate’s accuracy. By considering different perspectives and aspects, you can gather relevant information, even at a high level, that can be used to produce a more accurate estimate.

The key takeaway is never to assume you have all the information needed for your estimates. Instead, make sure to ask questions, gather relevant details, and be proactive in identifying potential risks to create high-quality estimates useful for planning and budgeting.

What about you? Do you ask different questions? What are they? Sound out in the comments below. If you liked this content, please share it. You may also want to subscribe for more Software Engineering Management content.

Cheers!