by jmorris
8. October 2009 22:22
Note: This post was motivated by a 3 hour discussion with a release manager regarding
why the name of the release was the same as a feature that we had pushed to a
future release – “If feature x has moved
to release y, why are we still releasing a build called feature x."
Why? Simple, it holds you and/or the team accountable for
releasing the feature in that release on the planned date. This doesn't
sound so bad one would think. After all, the feature was conceived hopefully
from some end user or business need, feasibility was assessed, and the sprint
was planned with dates engraved in stone. The reality is that while LOE
can be estimated, there are additional factors at hand that wreck havoc on what
will be completed by the cut-off date.
Typically, common cause variance can be mitigated and the
estimate included in the original LOE, however the same cannot be said for
special case variance. For example, you
can pretty much assume that a certain amount of effort will be attributed to
research and discovery, before the
developer even starts working on the task or feature. While in the exceptional
case a developer may have sufficient domain experience to simply start coding a
whip out the feature, the rule is that the developer will have to spend time familiarizing
them with the environment, before jumping in. This is expected to cause a certain amount of containable variance with
respect to a project or sprint. However, how do you reasonable plan the case
where another developer on the team contacts some grave illness, such as swine flu
and is not available and reduces the number of resources available?
In cases such as this, we simple do not plan for these
special cases, because it is virtually impossible. If you did try to plan for
them, you would never finish planning because there are an infinite number of
things that can happen. It costs too
much to plan for these types of things!
Back to my original point, when you name a release after a
feature you commit yourselves to completing that feature and releasing it on
the planned date, however you omit the possibility of special case variance affecting
the outcome. In which case you still want to release something so maybe you
release another, less resource feature; but the
release is named after the feature that was omitted…this is awkward
(especially for the build engineer).
You will communicate your intentions better (i.e. the goal
is a release, not necessarily the release of a specific feature) if you name
the release after some arbitrary name not tied in directly to a feature.