[bind10-dev] hardening sprint thoughts

[Jelte Jansen]

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

On 03/14/2012 11:25 AM, Michal 'vorner' Vaner wrote:
> Hello
> 
> On Wed, Mar 14, 2012 at 10:55:31AM +0100, Jelte Jansen 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.
> 
> Definitely. But I probably got used and forgot about most of them,
> the ability of human brain to adapt is both a blessing and a curse
> ;-).
> 
> I think I like the idea of hardening sprits (I don't know why it's
> called hardening, though. Does it make the code harder to run or
> the software harder to use?)
> 

I think the more political name would be 'release sprint', we can use
that if you want. I think the term hardening comes from the
stress-test based approach. This proposal could also be called the
garbage sprint :p

What I think best encapsulates what I have in mind is the last train
idea; I do not know the english term for it, but in Dutch the
'bezemtrein', literally 'broom train', is the last train on a line at
night. This train stops at every station, so it can pick up any
traveller that got out of the pub too late to catch their originally
planned train :)

> 
> Hmm, two notes about it: * I'd be very against estimating all the
> tickets in one go. That would drive all people and most AI's
> (todays of of future) mad. And we would not take enough care to do
> it properly. So setting a quota of 10-20 more tickets from the
> backlog should be considered.

Oh yes, I do not plan to make you all suffer through that; I was
thinking of adding any new tickets to the estimates for the next
sprint, but for older tickets I first want to wait for Shane to finish
his munging, then phase the ones left over in gradually.

> * I'm not sure how old an estimates can be until it is useless. I
> fear that our unit estimate is changing or fluctuating over the
> time. So a ticket estimated a year ago to 3 would be different
> difficulty than ticket estimated to 3 now. And we won't handle all
> the tickets soon, there will be some that will sleep in the backlog
> for a long time.
> 

Yup. Part of the idea here is to get much, much less of that. I assume
(or hope) that we will have much less of that once we get into this
cycle, and I wanted to propose separately that we need to keep the
backlog much cleaner. Additionally, we could consider resetting
estimates that were done some fixed time span ago. (say, if a ticket
is not even proposed for three months, see if it is still valid. And
either remove it, or reset its estimate so people see it again. Or
something :p). Hopefully, being forced to at least read these tickets
again (and the new tickets), makes people more active in proposing
them for sprints :)

(yes there is a lot of hoping being done today :p)

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

iEYEARECAAYFAk9gdawACgkQ4nZCKsdOncXwswCbB7+115pNQRC2FcdJhSnfoTkD
0PUAniQUHB9FarK7qvcne5Wa+OJ6E8ar
=RbfC
-----END PGP SIGNATURE-----