Estimation of tasks in process strongly biased as it’s done in different perspective, business perspective judge based on the effort of execution, communication within the company or customers ,… while estimation of technical team are connected to required efforts of building something, if you are a product manager you need to help your team to come up with an estimation that is feasible for them and viable for your company business. You need to manage these two expectations in your organization to come up with a working estimate as a whole. product development How to do engineering estimation? As I see engineering estimation of tasks is hard and frustrating in so many manners, unhealthy use of engineering estimation results in dissension and unhappiness of your team , they see their efforts as waste and in the long-run it vain your efforts on building a strong committed product team. So don’t blame your team for not meeting expectations/deadlines! Instead: 1-Involve everyone on the product team in estimation. Each team member brings you a different perspective on the required efforts of delivering a user story. Tips : before starting to plan for what you are going to build in upcoming weeks,organize a pre-planning meeting with your product team.A product team could include developers, designers (UI/UX), QA engineers and a data guy , explain them the scope of task and specs precisely and in details.Provide your team with user, business,sales,marketing and legal context of each feature you are going to build. 2-After describing the tasks,give your team time to do their research on what you are going to build, upfront & before any estimation, before you start designing, or writing any single line of code. Tips: collect up all your specs in a short outline (1–2 pages) document includes: a high level overview of your product and how it will looks after these increments , what you’re looking to create,required/not-required features and functionalities,what matters most to customers,you and business of company.In addition to this document if there is any initial mockups or share it with your team too. prototype 3-As your product team finished with their researches, discuss & review their findings on barriers, risks, and considerations of all you’ve planned to build. Tips: by discussing on these findings, you should learn if you need to change the direction of your product because of these barriers or constraints, is there something that you didn’t know it before and is there any further specs that you need. after discussing on this trade-offs you should come up with the best working approach to build the first version of your product/feature. Accordingly 4-Collaborate with your team to break down each task to the smaller chunks that can be measured, talk about hourly estimates of each of these chunks to come up with the total estimate of each task. Tips: teach your team how to employ some of the estimation techniques like WBS (Work Breakdown Structure),Planning Poker,Function Point (FP), Three-point while they are analyzing. 5-After all these pre-planning explorations, refine your understandings and estimate each task as a whole. Tips: always take into account a time for interruptions, unpredictable bugs,status meetings,changes to requirements specifications, creating or updating design documents, user’s manuals or product documentation with the new changes. If 2 or more teams collaborate together on building , there will be overhead of communication (phone calls, emails, meetings) and merging source code that need to be considered. 6-Finally measure the effectiveness of your process continuously. For each task try to figure out: How long did it take in the end? did it take longer or shorter than what you’ve estimated? Why? Tips: organize a bi-weekly or monthly retrospective sessions and involved your team to collaborate on how you could improve the process. You’ll get better and better with time. Good luck with your estimation!
