[bind10-dev] hardening sprint thoughts

[JINMEI Tatuya / 神明達哉]

At Wed, 14 Mar 2012 10:55:31 +0100,
Jelte Jansen <jelte at isc.org> wrote:

> There are a lot of tasks and tickets of relative minor importance,
> that tend to get dropped off sprints; Every sprint, this is a choice
> we make, and of course it is much more important to work on the Big
> Stuff, rather than those smallish minor improvements. However, as
> Shane can probably attest now, this leaves a LOT of stuff undone, most
> of which (I think) would not be much work. It leaves known bugs for
> users to find, which is always bad, and I think we also all have a
> number of tickets we know of and have been wanting to fix for ages,
> but never got around to.

I'm generally positive about the idea.

A couple of related points:

- I suspect it could be possible some of the letfover stuff turns out
  to be too minor on revisiting it after some period of time (even if
  when the follow up ticket was created we thought it a MUST but just
  deferred due to time constraint).  So it's also good to close such
  tickets immediately using an opportunity like "hardening".  One
  concern in this sense is that the last sprint of the same release
  cycle may be too soon to make such a decision, and we may end up
  working on really minor things.

- I also think we should consider this in a larger framework of how we
  plan the entire release cycle.  Right now we are planning major
  feature for each release assuming we have full three sprints, and
  checking the reality with the known and/or expected points of the
  expected tasks for the features.  I think this process has been
  working quite well recently.  But if we intend to use the last
  sprint of a release cycle for "hardening", we should revise the
  planning math: we basically need to assume we have a two-sprint
  window, and we can only plan features that can be done within that
  narrower period.  This means we'll be able to include fewer features
  in future releases (which will also recursively affect much longer
  plans such as yearly ones).  I think it's actually a good thing than
  prioritizing too many immature features, leaving ticking bombs in
  the code, but we need to expect that (for that reason, I'm less
  positive about doing it for this release cycle).

---
JINMEI, Tatuya