OK, you’re a software developer, and someone’s asked you to quick look at a feature, and give them an estimate on how long it’s going to take to develop. For this example, I will refer to that feature as ‘SuperFeature’, and we will have two estimating developer examples; Gina, who examples good estimates, and Lisa, who examples less good estimates. Priya is our product owner, and since Priya owns the product, good estimates give her the information required to make a intelligent decisions. Well-formed estimates enable her to prioritize work well, and manage expectations of customers and stakeholders.
Here’s two rules to estimating features successfully.
Rule 1: Your estimate should represent doing the ‘work done in a vacuum.’
It is counter-intuitive to estimate work in this way, but creating an estimate, as if that work is being done in a vacuum is the best way for your product owner to assign the feature a priority.
Example:
Gina, who estimates in a vacuum – “SuperFeature will take about 2 weeks to do.”
Lisa, who estimates based off of her current workload – “I will need 6-8 weeks to do this.”
In the first case, Priya knows how long the feature will take to develop. She knows that Gina and Lisa are both working on very high priority items, so she gets Liam to work on that feature.
In the second case, the Priya knows how long Lisa will take to get it done, but has very little awareness of the what priority Lisa is putting on the work. At next week’s stand-up, imagine Priya’s surprise to know that Lisa hasn’t even started work on it yet!
The lesson: Your product owner owns priority of the features. An estimate should give your product owner the information required to set that priority.
Rule 2: The larger an estimate, the more detail it needs.
If your feature is large, your product owner needs to know and understand why. In order to understand the work needing to be done, it should be broken down into tasks.
Example:
Lisa, who doesn’t break the work down – “SuperFeature will take about 4 months to work on.”
Gina, who realizes the work is complicated, and Priya needs to understand the details. – “In all, SuperFeature will take about 4 months. We’ll need 3 days to start building the catalytic converter, and then a week to refit and install the Whizzbang…” etc, etc.
In the first case, it’s hard to really even start the work, or even know how to break it up. Is it 4 months altogether? Can you break the work apart? Can you create multiple work streams?
In the second, Gina gives Priya all the details she needs to break up the work accordingly. She also does so succinctly, so that ordering tasks and dependencies are clear.
Following the two rules above will help make your estimates more valuable and your relationship with your product owner more beneficial.
Christopher Brown's - Blog 