There is content we don’t want to timebox, therefore there’s no need to link it to any timeline…
— Quote from someone that has direct responsibility over scope in a project (my emphasis)
This quote betrays a complete misunderstanding of the dynamics of software development, and a complete (albeit unintentional) ignorance of the market forces we need to deal with.
Here’s my point: by scope-boxing a particular Feature what we are doing is effectively giving up control of it’s size. Once the team is given the Feature they will work on it until it is “perfect”, that means we don’t have a clue when it will be done and therefore the schedule for that feature is completely unpredictable! Yes, sure we will stop development on it at some point, but will it happen before it is too late?
The advantage of timeboxing the content for a Feature (Feature must fit in a Sprint) is that we have a clear deadline at which point we evaluate if the feature is ready to go to the market! Without this constraint the team is left “alone” to decide when the feature is ready. But the team is the wrong actor to decide when a feature is ready! The product owner should be doing that work based on market intelligence, user knowledge, etc.
By scope boxing (as opposed to timeboxing) our features we are effectively giving up control of our projects!
Why is it so hard to understand this point? Where is my reasoning missing clarity?
Can you help?
Photo credit: danielygo @ flickr