[bind10-dev] hardening sprint thoughts

[Jelte Jansen]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1


As discussed on the call yesterday, I'd send out an initial vision of
a change in the way we do sprints.

First off, let me repeat the problem I see right now;

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.

So I was thinking of starting to do hardening sprints. In the original
scenario I heard them described, they fall into the general workflow
as follows; say you have a release cycle of 3 sprints, then the first
two sprints would be used for adding all the new functionality planned
for the release, and the third sprint, a hardening sprint, would be
used for polishing up.

There are of course a number of conflicting visions on whether to do
hardening sprints; some people think they are essential to the
process, others think they are a clear sign the process is broken ('if
you need a hardening sprint, your definition of done is wrong').

Some viewpoints:
http://www.agilegamedevelopment.com/2009/04/hardening-sprints-and-dead-frogs.html
http://blog.mountaingoatsoftware.com/correct-use-of-a-release-sprint
http://scrumplus.blogspot.com/2011/10/process-smell-hardening-sprint.html

In my idea, this would consist of smaller tasks that got left out,
annoyances that you've been wanting to address, and filled up with
defects. I would not like to see it become purely leftover work from
the previous sprint, but if anything falls through, this is where it
would go. And we'd fill the rest up with defect tickets. It would also
be the place to allocate some time for more 'real-use' testing, and
find things that are not yet caught by our unit and system tests; We
kind of did this before the last snapshot release, and we did find
things, so I'd like to actually allocate some time for it.

So for 'normal' sprints; we'd have one or more 'feature' goals, which
usually consist of a set of related tickets, and make up the majority
of the time for the sprint. This is then complemented with the usual
5+ defects, and we can still propose and champion any other ticket to
be included (just like we do now). And for 'release' or 'hardening'
sprints, we do not 'preselect' anything based on features (unless
leftover), but expand the defects and 'any' to be the whole sprint. I
am thinking we should allocate slightly less time in number of tickets
for the sprint, so people can spend time stresstesting and running, or
writing system tests, and we have room for errors caught by this.

So for instance, these tickets would be good candidates IMO:
- - The reordering of the includes
- - The several 'fixes for OpenBSD'
- - tickets like #1654 'reduce xfrout logging'
- - tickets like #1647 'logging in xfrout is incomplete'
- - tickets like 'tab-completion in bindctl fails'
- - tickets like #1626 "Error: Unable to parse response from Auth:
Expecting , delimiter: line 1 column 87 (char 87)"

I'm also considering another change: Right now, I only request
estimates for the tickets in next-sprint-proposed, and the tickets
that I know are related to the features we will be working on. I think
we should get every ticket estimated. The immediate change would be
that I'll also be requesting estimates for tickets in the New queue,
and once Shane is done munging through all tickets, get the rest done
as well. So take note, initially the estimation burden will increase
quite a bit :p. I am hoping this will have the side effect of better
understanding of and discussion on tickets, before they are even
proposed to a sprint.

Jelte
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.11 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org/

iEUEARECAAYFAk9gaxMACgkQ4nZCKsdOncUmVACgx9lrTuxtZvnczrdsol4XoaQI
9JAAlRNLuLkYs0dpXpzJVusaUw6GPzM=
=5ksG
-----END PGP SIGNATURE-----