Comments on: Scheduling requirements changes – part 2 http://tynerblain.com/blog/2006/04/11/scheduling-requirements-changes-part-2/ Software product success. Sat, 19 May 2012 12:04:06 +0000 hourly 1 http://wordpress.org/?v=3.0.4 By: Scott Sehlhorst http://tynerblain.com/blog/2006/04/11/scheduling-requirements-changes-part-2/comment-page-1/#comment-355960 Scott Sehlhorst Fri, 25 Apr 2008 02:31:00 +0000 http://tynerblain.com/blog/2006/04/11/scheduling-requirements-changes-part-2/#comment-355960 JP, Thanks for contributing and welcome to Tyner Blain. You're exactly right, you need to prioritize change requests (CR's)along with new functionality. From a product management perspective, they are no different. "Do this thing, it is worth $X" I wrote an article that addresses some of this a while ago. <a href="http://tynerblain.com/blog/2007/07/31/prioritization-and-value-maximization/" rel="nofollow">Prioritization and Value Maximization</a>. I think we're on the same wavelength! JP, Thanks for contributing and welcome to Tyner Blain.

You’re exactly right, you need to prioritize change requests (CR’s)along with new functionality. From a product management perspective, they are no different. “Do this thing, it is worth $X”

I wrote an article that addresses some of this a while ago. Prioritization and Value Maximization. I think we’re on the same wavelength!

]]> By: JP http://tynerblain.com/blog/2006/04/11/scheduling-requirements-changes-part-2/comment-page-1/#comment-354226 JP Wed, 23 Apr 2008 14:16:28 +0000 http://tynerblain.com/blog/2006/04/11/scheduling-requirements-changes-part-2/#comment-354226 and the analysis of include/don't include a CR in a release should also look at the value delivered in that release. If you push out one functionality from current release, value of the current release can decrease if the value of the CR is not greater than the value of the pushed out functionality. IMHO, the functionalities that deliver more value (including CRs) should be released early. what you think? and the analysis of include/don’t include a CR in a release should also look at the value delivered in that release. If you push out one functionality from current release, value of the current release can decrease if the value of the CR is not greater than the value of the pushed out functionality. IMHO, the functionalities that deliver more value (including CRs) should be released early.
what you think?

]]> By: Scott Sehlhorst http://tynerblain.com/blog/2006/04/11/scheduling-requirements-changes-part-2/comment-page-1/#comment-795 Scott Sehlhorst Thu, 13 Apr 2006 03:56:03 +0000 http://tynerblain.com/blog/2006/04/11/scheduling-requirements-changes-part-2/#comment-795 Great point Roger! We just added a post explaining exactly that. <a href="http://tynerblain.com/blog/2006/04/12/how-to-use-timeboxes-for-scheduling-software-delivery/" title="How to use timeboxes for scheduling software delivery." rel="nofollow">How to use timeboxes for scheduling software delivery</a> Thanks for the good idea! Scott Great point Roger!

We just added a post explaining exactly that.

How to use timeboxes for scheduling software delivery

Thanks for the good idea!
Scott

]]> By: Roger L. Cauvin http://tynerblain.com/blog/2006/04/11/scheduling-requirements-changes-part-2/comment-page-1/#comment-791 Roger L. Cauvin Wed, 12 Apr 2006 19:43:30 +0000 http://tynerblain.com/blog/2006/04/11/scheduling-requirements-changes-part-2/#comment-791 You might want to incorporate time-boxing into this discussion. With <a href="http://cauvin.blogspot.com/2005/07/time-boxing.html" rel="nofollow">time-boxing</a>, you hold the deadlines constant and vary the features you implement within them. So if you're having any trouble meeting a deadline for an internal or external release, you cut features rather than extend the deadline. You might want to incorporate time-boxing into this discussion. With time-boxing, you hold the deadlines constant and vary the features you implement within them. So if you’re having any trouble meeting a deadline for an internal or external release, you cut features rather than extend the deadline.

]]>