Product Velocity: Accurate Estimation of Task Delivery Time.

An engineer who has worked on software for years will confidently give you an accurate estimate time of completion of a similar project. But, technology is broad and systems are different, if you bring the same engineer to build a different software and ask them for an estimated time of completion, they will never be able to give you an accurate time frame, rather a bogus time frame that is never near accurate. But, this is a problem of the past now.

Apart from the challenge of working with a team of engineers, designers, and other hard-delivery personnel or teammates. Who are probably more experienced than you both professionally and perhaps age-wise. Accompanied by the hot breath landing behind your ears from the executives of your company. In a parallel universe, you may be lucky to have a product owner or project manager working with you, to whom you will be reporting. The roles of a product owner and project manager are different. In some firms you the product manager, may have to report to the product owner. Wherein, the product owner in this case acts as a representative of the board of executives. Although his word is not final, the product owner might be a soft landing because they will definitely take some heat off you coming from the busy executives. The project manager strictly must give a valid time frame for a product to be built, what it will take to build and what the product or project will require to build. Sometimes you may have to report to the project manager who will report to the product owner who then reports to the executives.

However the situation may be, these two will pressure you for results. As a product manager, you are expected to deliver a product within a particular time frame which will be defined on a larger scale by the project manager and then fine-tuned by you the product manager because the project manager gives a general estimate of project completion. But the product manager is responsible for the people who build the product i.e., the engineers. Hence, the product manager needs to be experienced enough to be able to figure out a near time of completion of a project regardless of what the teams say.

For example, if the front-end team says they expect to have completed task ‘X’ in six weeks. This timeframe is just an estimate and if we are realistic it may take shorter or longer to complete this task. Because these guys are humans. So, in that six weeks, they may have added one week for flexing, another one week for getting into it, and perhaps another one week for soft work and then leaving us with three weeks of which they might need to do real work. As a product manager, your ability to give a near-accurate estimation of product task completion will earn you more respect because it will help the entire team be more efficient to easily complete and move on to other priorities.

Therefore, you need a working framework that you can use to properly give an estimated time of product task completion. A working system that can guarantee you around ~95% accuracy is Product Velocity. Unlike how the name sounds, it is not physics or mathematics, so be calm. What is product velocity? Product velocity is a concept of time management estimation method used by senior product managers which rely on present and past work experience to properly estimate the completion of a new task. It uses numbers, called story points. It involves the ranking of sprints and getting an average score.

The trick here is. During the sprint planning meeting, instead of asking the engineer how long it will take them to complete a task/sprint, ask them how difficult they think this task is and make them rate the difficulty on a scale. The scale can be 1-5 with 5 being the highest and hardest and 1 being the lowest and easiest, different firms have their own scales. So, you will have the engineers rate the difficulty of the task on a scale of 1-5 (you can use any scale, but for this example, we will use 1-5) this is what we call story points. Now, you take each rating and tag it on each ticket on the sprint, then at the end of the sprint, you check the story point to see what was completed and its scale of difficulty.

For example, out of 10 items we were able to complete 4. Let's say these four have story points value of 5+2+4 = 11. This 11 is our velocity. Meaning we were able to complete an average of 11 numbers of story points in x period. Using this principle overtime repeatedly, you will be able to predict how long a project will be completed once they have been ranked. You must make sure your engineers are familiar with the ranking system. If you do this right, you will become a time bender. I hope someone got that reference!

There you have it, now you can easily give the correct estimation of product task completion. Understand the concept and the idea first and you will be a master of the time in your workplace.