Estimation, Target, and Commitment for Software Products
Notice: “By my estimation, we can be committed on x to reach y.”
You may not be familiar with such a structure, but estimating, committing, and targeting is one of the tasks we deal with in producing software products daily. Unfortunately, these words are not well separated for us, and sometimes we use them interchangeably if they are very different in meaning. To resolve the problems that result from our misuse of these concepts, and of course, to continue to work correctly as a team, we need to understand the differences between the development team and us.
Estimate :
Estimating is, in fact, the exact guess as to the development team’s task completion time, and this guess should be based on previous data, such as team performance for similar tasks in the past. On the other hand, the estimate cannot be assigned to a specific number, such as day and hour, but the estimate must be considered as a “range” range.
The critical thing to estimate is that software developers can make estimates based on their experience, consultations, etc. Product managers and owners need to be aware that they should not negotiate estimates. , Because estimates are just guessed about what to do.
If the estimates are not based on experience and the developer decides to rate the forecast according to the amount of time it “wants” to do it, or the amount estimates when the product manager or owner “wants” to It may be over, in fact, we have the constant challenge of over-estimating or under-estimating.
Target :
The goal is the point we have planned to reach. Or in other words, this is our ideal Deadline. Another critical point is that we should not negotiate on time to reach our goals. Because these schedules are not easily changeable from planning to product promotion, contracts, and promotions. Also, the preparation of the desired product in due time is one of the things that will satisfy our customers whether they are domestic or foreign customers.
Commitment :
The only thing that can be negotiated is our “commitment” to get things done. We need to constantly ask ourselves how we can balance the time when the development team becomes “committed” to doing something and based on its estimation and the time constraints to reach the primary goal. In fact, “commitment” is when we and the development team agree to reach our goal in every way possible.
for example:
We talk to the seller about buying a physical item, asking him to tell us when he will deliver it. He replies that the delivery will be around December 20. You accept his estimate but ask him to give you a specific date so that you can be fined if your goods are not delivered on time on that date. The seller, therefore, promises you that the item will be finally returned on December 22 at your place of work and by the end of that office hour.
So ideally, we need to work with our development team on what they are doing to deliver accurate estimates and talk to our customers (stakeholders) about their target dates so that we can be fully committed to and committed to a specific time for product delivery.
Keep in mind that estimates and goals cannot be changed after they are set by our development team and customers. The only thing we can change is the Scope. We just need to always be careful that our estimates are not interpreted as our commitments. Make sure that you, your development team members, and your customers can separate these concepts. This way we can prevent Scope from becoming too large and reach our target date.
Let’s review again:
Estimation is the approximate time at which a task is performed. These estimates will be based on previous experiences and similar work. They are not negotiable and do not equal commitment.
Objectives: There are times when we need to reach deadlines. Deadlines are usually determined by people outside the development team.
Commitments: This is when the development team is committed to delivering the end product or product.
How commitments are managed:
We manage our commitments based on knowing certain parameters, ie target time and our estimations. Since goals are equal to specific dates, estimates can help us commit to a specific time frame for delivering the work in question. Without estimating how long it takes to get a job done, we cannot commit to a specific time frame.
Where we are having trouble:
Sometimes developers overestimate their performance in real-time to give themselves a little more space and tolerance for their work, and since owners or product managers also know this, they start negotiating with developers. Payers make estimates.
What causes this problem?
The reason for this problem can be rooted where the development team’s estimates are considered by owners and product managers to be exactly equal to their commitment to get things done, and if we skip the estimated time, feedback and Tracking and micro-management begin.
In this case, the developer will not feel good about doing the estimation at all and will only do so because you have to give up and don’t ask so much “how long does it take” !!!
In this case, as we read in the basics of economics, people make their decisions today based on their concerns about the future. If the developer fails to give you a sense of security, tranquility, and trust to appreciate what we’ve been assigned to do, we’ll have more / less real-time estimates, and this will continue.
Why the estimates are scary:
Estimates cause internal stress for several reasons. First, because of a lack of trust in the development team as well as interference and negotiation in the estimation process, they do not have sufficient freedom to do so. Secondly, the criterion for making these estimates is time. Is.
Since most companies contract their employees on a day-to-day basis, it is a mistake to estimate the amount of work people have to do during the day. It is here that the hourly estimates and, of course, the lack of separation of the above cause the developer to be at a loss of peace and fear of job security.
What is the solution:
Here’s a way to estimate things using the Fibonacci number chain. This way items are estimated by size, big or small, and by comparison. Also, not using time for estimation eliminates previous problems. Implementation of this approach will take time with the need to change the way everyone thinks. So avoid sudden changes to implement any way your team works. Also, to implement these practices, consider the capacity of your team as well as accompanying and engaging in change.
Feel free to comment below. Please hit that clap button to help others find it if you enjoyed this article.
