People are good at estimating their own ideal effort<\/em> on well-defined work within their realm of experience.<\/p>\n People are poor at translating ideal effort into calendar days, estimating how long others will take to perform work, and estimating work that is either poorly understood.<\/p>\n Estimation is time consuming with diminishing returns so the effort should be managed to cost, i.e. time-boxed. That is why Agile practices invest more energy and place more value in estimating immediate work than on more speculative work farther out. <\/p>\n All estimates contain uncertainty. Industry research says an upfront estimate can be 25% to 400% of actual performance. The range of uncertainty is deeply dependent on context: how much work is involved, development lifecycle, experience with the particular work, shared experience within the development team and maturity of the management organization.<\/p>\n It is poor practice to “pad an estimate”. Padding doesn’t match the scatter that surrounds upfront estimation. For large scopes of work a developer should express an estimate as a range of uncertainty (i.e. “four to eight months skewing to between six and eight”).<\/p>\n Middle managers should not pad or trim a developer estimate. That is undermining the developer’s authority and making them un-accountable. The estimate is the estimate. <\/p>\n That doesn’t mean that the business doesn’t make planning decisions based on estimates. It means those decisions are separate from, though informed by, the estimate.<\/p>\n Targets<\/strong><\/p>\n When a product owner or sponsor takes a developer estimate of 4-8 months and sets a release date six months out, they are moving beyond the estimate to set a business target. This is a judgment of what expense and time to market promise sufficient value to justify the work.<\/p>\n The product owner is using the developer’s estimate to inform themselves of the risk they are taking with their investment. An aggressive target within an estimate with high uncertainty is a larger risk than a conservative target on a more certain estimate.<\/p>\n Commitment<\/strong><\/p>\n Setting an achievable target and owning that decision, communicating the rationale for your decision and having that rationale inform your priorities earns trust and rallies a team to deliver.<\/p>\n Don’t set arbitrary targets.<\/em> Don’t burden yourself with unnecessary risk, demotivate your developers and thoughtlessly constrain the value built into your software.<\/p>\n Do set meaningful targets.<\/em> Take calculated risks, manage costs, partner with your developers and know what and when you need to deliver to your customers.<\/p>\n It’s not an estimate.<\/em> The developer cannot assume your risk. <\/p>\n It’s not a commitment.<\/em> You’ve got to earn that. <\/p>\n At the end of the day, the product owner is responsible for understanding the business climate, understanding the customer, describing and prioritizing the work, and managing the company’s investment to a successful outcome.<\/p>\n","protected":false},"excerpt":{"rendered":" A product owner describes work. The team estimates it. The product owner sets a delivery target. The team commits to it. Estimates People are good at estimating their own ideal effort on well-defined work within their realm of experience. People … Continue reading ![\"wall](\"http:\/\/farm1.static.flickr.com\/11\/13164176_db4a95d09d_m.jpg\" "\\"wall")
<\/a>It’s the targets, stupid<\/strong><\/p>\n