How to Position Your Team for Success in Estimation

Estimates are critical if you want to be successful with projects. If you begin with a bad estimating approach, the project will almost certainly fail. To produce a much more promising estimate, direct each estimation-process issue toward a repeatable standard process. A smart approach reduces the degree of uncertainty. When dealing with presales phases, having the most precise estimation findings can assist you to deal with the project plan. This also helps the process to function more successfully, especially when faced with tight schedules and the danger of deviation.

A team of specialists must do Test Estimation in the early stages of the project. By having a reliable crew, the teams can make more accurate estimates. The estimating approach must be a repeatable process that the team undertakes at the start of each project, regardless of the methodology or development lifecycle used. It is also strongly advised that the team attend a “lessons learned” meeting after each stage, with the ideas and choices generated during this session utilized to prepare for the following step. These meetings must be scheduled to go over the estimate that the team created earlier, incorporating new factors that were not considered in prior phases or past projects with a similar structure. This practice will help the team enhance their future forecasts.

The Stop, Start, and continue the approach, which is a valuable framework for offering or asking for feedback, is typically used to generate these “lessons learnt.” It includes three things the individual should maintain doing, three things they should cease doing, and three new things they should start doing. Feedback is critical for assessing current levels of performance as well as suggesting areas for improvement. Unfortunately, most individuals are not great at either providing or receiving feedback. The Stop, Start and continue technique is a simple and effective paradigm for overcoming some of the difficulties associated with both delivering and receiving feedback.

This strong foundation serves as a reminder that before beginning each project stage, you must assess the worthwhile efforts. For instance, certain testing activities are ignored with the presumption that there won’t be any difficult problems to resolve. But when the test team gets down to business, it learns that certain test cases call for a little more work than others. Technology problems, fresh alternate flows that weren’t taken into account in the initial strategy, and other factors may be to blame for this complexity.

It is also typical for teams to dismiss testing efforts for revisions that result in extremely low or minor development efforts. However, any adjustment, no matter how little, might have a negative influence on product quality. After each testing process, the development team must address any problems that were discovered. This work is frequently underestimated, resulting in over-budget projects. After running numerous cycles, your efforts may be successfully measured and improved.

It is easy to overlook organizational concerns in the estimating process from the perspective of the team. These concerns may be more closely tied to shared resources, knowledge management, and external dangers, among other things. Nonetheless, although these difficulties may have an impact on the estimation’s outcome, the team must conduct the estimation by focusing solely on task efforts. Thus, organizational difficulties must be addressed as part of the risk-management process, and they must be reflected in the project plan alongside the estimated results.

Buffer Teardown

The majority of the time, team members will add a little amount of additional work, or a buffer, to the initial estimation to make it more flexible. This is a terrible habit. The estimation must be honest, with every specific challenge openly shown for all team members to evaluate. Each group member must control the same concepts and assumptions. Any disparity will yield untrustworthy outcomes. There must be clear guidelines and norms in place before any estimating session begins to prevent the use of inaccurate numbers, for example:

• “We’re going to estimate efforts assuming one person is working on each activity constantly.” There are no pauses, weekends, or holidays. We will estimate efforts without making any assumptions about a schedule or deadline.”
• “We will not employ buffers to store deviations.”
• “We’re going to estimate efforts rather than risks.”
• “We’ll estimate in terms of man-hours,” or “we’ll estimate based on complexities.”

Estimation results must simply offer measures in terms of effort or complexities, without accounting for coffee breaks, potential risks, or buffers. The project plan and schedules must include risks, interruptions, and buffers. To achieve results based on shared concepts and assumptions, each team member must understand these guidelines.

Estimation Made Without Calculating All Factors

When the team calculates the estimated work, they need to examine all factors involved in their sprint commitments. These factors should be well defined as a checklist for the team to follow as part of their estimation process. Here is a sample checklist:

• Are there any dependencies on other teams?
• Who are the people available to accomplish the task?
• What is the experience and knowledge of those people?
• Are there any known risks that can affect the timelines?
• What is the development and testing strategy?

Conforming to the “Expert” on the Team

The process of estimations involves all team members. They are equal and can share their feedback as part of the estimation process. The problem begins when team members lack the confidence to provide their estimation and therefore conform to the opinion of a strong team member. If we want to build a cross-functional team, we must ensure each team member can contribute to the overall effort and share their feedback.

A good way to resolve this is for the expert in the team not to estimate and have the rest of the team estimate. Once they are all done, we can ask the expert to share their estimate with the rest of the team.

Adjusting Estimates Without Communicating

The team had their planning session, estimates were given, and the team starts the sprint. They start work on a story and suddenly realize that their original estimates were wrong (i.e., the solution envisioned is incorrect). The team adjusts the original estimates during the sprint based on the new information they now have, without telling anyone. This indicates major problems within the team that you must understand before they have a bigger impact on the team’s ability to perform (e.g., fear within the team of being wrong, the estimation is not effective enough, or being used incorrectly).

Sharing Different Points of View

Allowing individuals to express their thoughts is an excellent strategy to lead the team to an agreement. When there are conflicts or a significant difference between two or more measures, it is essential to allow team members to express their points of view and explain how they arrived at specific conclusions. This concept is used in several techniques, including Scrum planning poker, and Extreme Programming. It is the most effective method for ensuring that the team is pleased with the final results and that there are no unresolved issues. After the discrepancies have been discussed and members’ viewpoints have been given, the point in question must be estimated again until the team reaches an agreement.

It’s critical to distinguish between a leader and an enabler from now on. The former will force the team to accept his estimate, excluding other team members from the decision-making process. This style of micromanagement is rarely successful. The facilitator, on the other hand, will include the team in decision-making and will urge members to do the evaluation, making the estimation more honest and successful.

Definition of Done (DoD)

Another consideration when doing effective estimations is agreeing on what “done” implies. To accurately estimate efforts, the team must understand when something is complete and what items must be accomplished to get there. The Definition of Done (DoD) should be one of the main starting points for any Agile projects that involve different stakeholders. The Product Owner and the team should always work together to agree on a clear Definition of Done which will define whether a story or feature is ready as an increment delivery.

There are different interpretations of how to determine the DoD. One common way to do it is to state that once the software testing is conducted, the development is finished. In this case, the team just says, “A story is completed only when the tester in the team says it’s done”. If that is
how you decide to do it in your team, you must ensure the tester is the focal point for the Product Owner, so the team understands the PO’s intentions.

For me, this method of tester approval is less effective for several reasons:

• Single point of failure.
• Developers may ignore their responsibilities. (Why shouldn’t they if they can always blame the tester?)
• It creates a separation of testers and developers.

The more common (and far more effective) way to implement DoD is to use checklists that specify the criteria and requirements needed for completing a feature, sprint, or story. Let us look at a few examples:

The Definition of Done for a feature may be determined by the following criteria:

• All essential stories relevant to this feature are approved by the customer.
• There is a full, stable working version ready for release.
• All bugs are resolved technically, or in an acceptable state with the approval of the PO.
• Feature documentation is complete including user manuals, release notes, and known issues.

The Definition of Done for a development sprint may be determined by the following criteria:

• The sprint goal is accomplished.
• All user stories are completed and approved.
• Release notes are written and documented.
• Automated tests were written, executed, and passed.

The Definition of Done for a user story may be determined by the following criteria:

• All tasks necessary to implement and test the selected story have been identified, estimated, and approved by the team.
• All bugs associated with the story have been reported and verified.
• All coding and testing activities are complete.
• Every story added to the sprint backlog is fully understood, approved by the team, and has all the elements of a user story including acceptance criteria, acceptance tests, etc.
• The code has been integrated into the main branch.

Problem Management

Finally, while estimating projects, one of the most important things to remember is to divide down the scoped activities as much as possible. If you have to estimate the height of a building, you probably don’t know where to begin. However, if you figure out how many walls you’ll need to raise and how many bricks you’ll need per square meter, you’ll be in a better negotiating position to precisely draft the project plan.

You have greater control over this now measurable difficulty when work components are smaller. You probably don’t know how to quote a skyscraper, but you must know how much one brick costs.

David Tzemach

The founder and owner of the Agile Quality Made Easy blog (25K followers). A platform that he uses for teaching and coaching others, sharing knowledge with people, and guiding them towards success while giving them the inspiration and tools to discover their own path.

See author's profile