Estimation of tasks in product development process strongly biased as it’s done in a different perspective, business perspective judge based on the effort of execution, communication within the company or customers,… while estimation of the technical team is 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.
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!
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 the 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 to them the scope of tasks and specs precisely and in detail. Provide your team with the 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 the company. In addition to this document if there are any initial mockups or prototypes share it with your team too.
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. Accordingly, after discussing these trade-offs you should come up with the best working approach to build the first version of your product/feature.
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 time for interruptions, unpredictable bugs, status meetings, changes to requirements specifications, creating or updating design documents, user manuals, or product documentation with the new changes. If 2 or more teams collaborate together on the building , there will be overhead of communication (phone calls, emails, meetings) and merging source code that needs 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 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!