Monday, July 25, 2011

Product Owner's Guide - Breaking down estimates



Overhead this while at work.


"The Product Owner wants us to break down our inital estimate on the development effort into parts like analysis, design and coding ...".


That sounds to me like the Product Owner(PO) thinks that whatever estimate that the team came up with is too long and wants to cut the estimate. If the team gives such such a breakdown, then be prepared for the negotiation about the time needed for the project to be discussed.


But how is the team going to come up with such a figure anyway? I always found the statement like "Most of the time is spent in design but little in coding", or using the 80-20 rule that 80% is spent in design and 20% in coding. Is that statement still relavant today? In the past (I mean way way past), people do spent a lot of time in design because computers process ur programs in batches and you better get it right the first time if not you wait a day for the next run.


Fast forward to today, where we have powerful ides, programs run almost instantly, where you can code a little, test a little, you are more likely to try a program a vertical slice and then build up your system from there, with refactoring tools so powerful, changing methods, implementing interfaces no longer is such a chore.


 Now back to the story, not matter what the project team tries to justify their number the PO will just try to cut it. The problem with most people is that they have some prenotion of when the project will end, but they do not realised that an estimate is just that, an estimate, it's a educated guess base on whatever information you have. An estimate is not an accurate prediction of the future and couple with the fact that software estimates are usually wrong. Steve McConnell says it well in his book Software Estimatation.

"Estimation should be treated as an unbiased, analytical process;
planning should be treated as a biased, goal-seeking process"

So if you ask someone for an estimate, you are asking for his opinion on how long it will take, and you shouldn't try to cut his estimate down.

More likely is the product owner is trying to get a plan from the team not an estimate, and the team's estimate isn't matching his plan. His plan can be anything, could be trying to meet some timeline for marketing, or some trade show demo.


  Product Owners please just tell the team what is your plan, it may be because of marketing, budget and other reasons that you need to slim it down. But please tell the real reason and not by trying to get the estimate within your plan.


  For the development team, try to find out the underlying reason for doing such an exercise, buy a copy of Steve McConnell Estimation book and give it to him. Negatiate on the scope, not all features need to be a mercedes, sometimes a vespa is good enough.


  The only thing that can be reliably cut down to meet the target is actually the scope of the project. Does the Product Owner need 100% of all the features of the software to be done to be really useful? More likely than not something like 50-70% will probably be good enough.


Main takeaway - Estimation and Planning are 2 different things, try to make sure what is it you are talking about.


   

No comments:

Post a Comment