A project manager will always understand another project manager and give only the best advice:) So let’s give the floor again to our project manager Ivanna (aka Vania). In her previous article, she shared her ideas on retrospective.
Today, she welcomes her fellow project managers to read about overestimated and underestimated sprints.
There are times during sprint planning when a team, maybe because of insufficient experience or simply by not taking into account all factors, gives too low of a time estimation (or too optimistic a forecast about the sprint end). What might be the result of this? Missed project deadlines and incomplete tasks.
Our primary duty is to give the most realistic plan for the task fulfillment. If you give your customer vain hopes and fail to deliver the promised results, you demonstrate poor service. If repeated regularly, it is likely to cause your customer to leave.
It is sad...
The consequences of sprint underestimation
The term Commitment in the Scrum methodology indicates the amount of work that a team undertakes to perform within a given sprint. A failure to fulfill a commitment may lead to a number of consequences:
- it is impossible to plan the final product release date
- the customer is upset
- the team is dissatisfied, its efficiency and team spirit drops, and everyone is sad: "We have failed the sprint again"
- conflicts within the team may arise, with people saying "I managed to do my tasks, but we failed because of him/her”
- everyone gets stressed and fatigued
On the other hand, does someone have to be responsible for such errors, especially if they are big?
In a project manager’s work, it is important to not overdo punishment for an error. After all, who would want to take the responsibility for something they are not always able to control and or have an influence on? Punishments for mistakes are a powerful anti-stimulus, which can discourage a team from taking responsibility and showing initiative.
The consequences of sprint overestimation
In today's world of web development, there are many factors that can disrupt even the short-time plans of the Scrum team for a couple of weeks, let alone terms for which the time estimation may be even more inaccurate. Hence, my advice: do not bite off more than you can chew. To me, it is better to overestimate a task than to underestimate it. At least in this case, you will have:
- successfully completed sprints
- an improved micro-climate
- an increase in productivity with time (you should see to it your team does not relax too much)
- satisfied customers
- if you do things right, everyone will later learn to accurately predict their strength and capabilities
For example: on our project, the problem of task underestimating was solved as follows. The project was large, and the time for completing a task grew with time. In addition to writing the code itself, the total estimate consisted of the following components:
- development
- communication with the team
- communication with the dev lead
- deployment to staging
- testing on staging
- fixing and stabilization
- deployment on live
- re-testing on live
- re-fixing and re-stabilization
Be sure to have a preliminary that is approved by the dev lead first, though.
So by following these rules, you will learn to make realistic estimations.
