Product development estimation is an integral part of the digital product development space. It involves providing an estimated time of completion for the development process. As desirable as this process sounds, it is clear that most developers do not like it. This dislike is born out of many myths and misunderstandings surrounding the practice. In this article, we will discuss some of these myths, and justify their relevance or irrelevance to the product development process. Finally, the article will also proffer certain solutions that would allow developers to see the essence of the estimation practice.
We are Bad at Estimating!
One of the beliefs that have pervaded the product management space for a while now, is the belief that humans are inherently bad at estimating. From estimating the quantity of an item to generating an estimate for the completion of a project, humans have always fallen into to error of giving inaccurate estimates. It, therefore, follows that since humans are inherently poor estimators, there is no need to estimate for the product development process.
Despite this belief, estimation remains a very important aspect of every developmental process. Product owners and financiers must have a timeframe for the completion of the product. Developers and product managers need to be able to answer the question, ”When will this product be done” as one of the experts in the field have stated, “Estimation helps differentiate tasks and processes, it helps the team understand that one task is easier than the other, and as a result, it allows the team to prioritize some tasks over others”
Also, estimation allows the team to manage its capacity as well as the stakeholder’s expectation. These and many more are some of the benefits of using estimations in the product development process. However, it is not enough to understand the benefits of the product development estimation process. Software developers need to have a refined opinion about the process.
Rather than seeing estimates as a barrier to project completion, it would help if developers would see estimates as a tool for communication. Developers should understand that project estimates helps communicate deadlines and priorities to other members of the team.
Wrong Use of Reference Points in Estimation
Another reason why developers have been averse to the use of estimation in the developmental process is the wrong use of stories or reference points. More often than not, reference points and user stories are used to determine how long a task or activity will take. While this use is beneficial in part to the developers, it is one of the wrong uses to which reference points are used.
Rather than use reference points as a measure of time, it pays to use them as a measure of size or complexity. By doing this, helps the developers and also the whole team to see the size of tasks that can get fitted into a sprint.
On the flip side, using reference points as a measure of time, and a metric for measuring the team’s success tends to discourage the developer. This is because new challenges could come up during the tasks and this could elongate the timeline. An extended timeline means that the team would not be able to complete the task within the time estimated; this may be discouraging to the team.
Finally, another reason why reference points should be used as a measure of size or value is that it helps the teamwork faster. When you are working in Scrum, you are supposed to be more efficient and faster. Using story points as a measure of value would help you understand that the team is working hard and fast over time, even if there is an extended timeline or duration.
Recommended Read : Splitting User Stories – Agile Best Practices
Only A Scrum Master can lead the Estimating Process
This is another myth and error that has led developers to avoid the estimating process. Experts have opined that a scrum master is not a job title, rather it is a way of seeking accountability for the agile process. Therefore, one doesn’t have to be a scrum master before they lead the agile estimating effort.
In choosing the leader of the estimating process, emphasis should be laid on how invested and imbibed the person is in the whole project. There should be a lookout for certain skills, which include the ability to shuffle tasks among team members at every sprint. The scrum master should also be able to exude orderliness, organization, and punctuality.
Other characteristics that you should look out for are the ability of the person to sacrifice individual glory in place of team success, and also find joy in solving people’s problems. These characteristics are not commonplace among many people and this is why it is a bit difficult to find a very good Scrum master these days.
Lastly, the scrum master must understand his role and responsibility. Essentially, he must understand that he is responsible for the facilitation of reference points and events, gearing the team on for continuous improvement, and also removing difficulties for team members. The scrum master, while showing commitment to the due completion of the project must also remember to protect the team and its capacity.
New Team Members Cannot Join the Estimation Process
Another erroneous belief has found root in the industry. It is widely believed that new team members cannot join the process else they will cause a setback for the team. While it is true that the addition of new team members can be a bit tricky, it cannot cause a setback for the estimating process. The team may indeed experience some drag when new team members come on board, however, the whole process becomes a success with the increase in capacity, which also translates to more people. Therefore, the drag experienced when the new team members get added to the process will even out later when you get more tasks done in future sprints.
In conclusion, there is no problem with adding new members to the estimating process. They must be included as they will be part and parcel of the whole developmental process, and they are currently working at a different pace. Remember that estimation is a collective effort and it is helpful to hear everybody’s opinion when determining the estimate, especially in a team where members are from different backgrounds.
Tendency to Follow the Estimate from the Most Experienced Team Member
As with other facets of life, groupthink is also a risk in the mvp development process, especially while creating the timelines and estimates for tasks. This risk manifests in different ways. One of these ways is to agree with the majority of the team members, despite having a contradicting view or opinion. Another manifestation is the tendency of the whole team to follow the estimate provided by the most experienced member. Also known as anchoring, doing any of these will only result in inaccurate estimates and inflated egos, none of these is good for the success of the project.
MVP For Startups: The Most Crucial Step To Start Any Business
One of the solutions to this problem is making the estimation process anonymous and asynchronous. As a result, the whole process would be bias-proof and team members would only give their honest opinion without having to pander to other people’s egos.
To go about the anonymous process, upload the reference points or stories on the digital board used by team members. Then you can ask team members to privately assign a value to each reference point or story. You can ask members to use cloth sizes to depict the size or complexity of the task. So, S would depict a simple task while XL would depict the most complex task.
This way, the team can give an honest opinion about the story points and hold discussions on the reference points with the least aligned value.
Conclusion
If the engineering team and the product manager can find a way to work around these myths, the team may be willing to adopt the estimating process and imbibe the use of estimates to make their work better and more efficient. However, apart from working around these myths, the team should work on certain points to become better with tasks and reference points.
First off, the team must avoid comparing its progress with that of other teams. Progress should be measured through value and tasks completed, and not with the time taken to complete these tasks. It is important to remember that there are no two similar scrums and sprints. You also don’t know how these teams defined their reference points or story.
Also, it is important to mention that the team should cut themselves some slack even if the tasks take more than the estimated timeframe. It is rare, almost impossible, to get it right with estimation in the first trial. Estimation is meant to be repeated over and over again to attain a certain level of perfection.
