Why track against estimates from the iteration planning game?

I was challenged over lunch today with the statement “Release level estimates are the only ones that matter” by a couple of guys on my team. In our context release level estimates are estimates that are made at the inception of a project. Unfortunately for me I had my Release level sunglasses on and could not see a very good argument against this idea at the time. The basic premise was that the business wants the project delivered so delivery estimates made after project inception are meaningless to the business. We have a project plan and our goal is to follow the plan.

I offered that estimates made at iteration planning games are more accurate and could highlight problems with estimates, or assumptions made at the project inception meetings. While I believe that is true, it did not look like a very powerful argument to me and I don’t think it convinced them of much either. Then, later I found my Business Value glasses and started to reconnect the dots that construct a better argument for focusing on the iteration and related estimates. These glasses come free with a viewing of http://video.google.com/videoplay?docid=-5105910452864283694&q=google+engEDU (offer not valid if you don’t drink the kool-aid).

The basic problem with the project plan that I can’t believe I forgot is that it, like the rest of us, is only born to die. Faith in a project plan assumes that there is solid ground from which you can measure things. Unfortunately, as Einstein tells us, you can only ever measure something in relation to something else and even then only at a certain point in time. There is no solid ground from which to make measurements that remain constant over time. The only constant is business satisfaction. So the perfect business plan on March 1, will be something less than perfect by April 1 if not before, at some level of detail.

The moment two key business people get together and come up with a better way to do something, and that results in a card change, you have deviance from the project plan. From that moment on estimates as to how long it will take to get to the, now deprecated, plan objectives are measures towards sub optimal business value. If you have a bunch of smart people doing your software delivery like I have on my team, and strong connections with smart business people (they sit in the same room with us and attend the stand-up), then innovation starts happening almost immediately. The more it happens the more deviation develops between delivering the project plan and delivering optimal business value. When deviation happens that looks bad to a static plan and to people managing to a static plan, but if it is the result of innovation it will look good to the relevant parts of the business and it should then feel good to an empowered delivery team. Iterations can acknowledge these events as new stories that the business deems worthy (added value) or increased velocity (decreased cost), but a static project plan only sees them as deviation.

What do you do with tech debt cards (if you have them), or bugs, or any other sneaky time consuming task that has no place in a project plan? If you are monitoring team progress via iteration work you will recognize and estimate these tasks. Any problems they are causing will then show up on your radar. A well-run team will look for ways to make this work visible to the business or find ways to remove the need for this work. Hopefully time on tech debt and bugs can be reduced to the point they will become non-issues. By checking velocity by project level stories you don’t see the bugs and tech debt. You see slow velocity but no reason why. By tracking at the iteration level these tasks can be estimated, tracked and recognized as sources of scope creep or the result of bad processes that need to be changed.

So tracking velocity against iteration estimates tells you your team’s potential to deliver business value based on the needs of today, velocity tracked against release level estimates only tells you how well you are progressing along a track that is a sub optimal path to business value, though it may have been perfect back in January, six months ago, or whenever your project began.

I am sure I am forgetting some vital benefit of the old Project plan , so feel free to speak up and defend it.