tag:blogger.com,1999:blog-3599452548077943366.post3511711791584003626..comments2011-09-09T15:03:59.344-03:00Shawn Crosbyhttp://www.blogger.com/profile/12093823138737535996noreply@blogger.comBlogger2125tag:blogger.com,1999:blog-3599452548077943366.post-11946866021246535492011-09-09T15:03:59.344-03:002011-09-09T15:03:59.344-03:00Good point...I&#39;m not sure you can show anything up front, but I&#39;ve found feature development to be a fair bit quicker when the code is meaningful. I can usually show a faster delivery of new features a few sprints in if the code is clean.<br /><br />In my opinion is you can&#39;t manage what you don&#39;t measure. Time to resolution on issues is likely a good measure.Shawn Crosbyhttp://www.blogger.com/profile/12093823138737535996noreply@blogger.comtag:blogger.com,1999:blog-3599452548077943366.post-79649984395941187722011-09-09T14:29:16.955-03:002011-09-09T14:29:16.955-03:00Interesting concept. <br /><br />How do you prove to the brass that the delayed release has actually resulted in less maintenance? <br /><br />If the motivation of less maintenance is more new features and less patch releases between the next release. How do you show them your up-front efforts have paid off?<br /><br />Extending a deadline they understand. <br /><br />Perhaps the metric is: number of reported bugs post-release related to the new features of that release (pro-rated by the extra time spent)?@TheSandyWalshhttp://www.blogger.com/profile/09609915519064692107noreply@blogger.com