Milestone size continued
If you're looking for the previous "Milestone" I guess it was the note about thrashing. Clearly I'm on a the-power-of-baby-steps theme recently.
As I write this (and the previous note) I'm remembering Sandro's words on minimum valuable increment. The description is not the same as what I'm toying with here, but the sentiment is related. Sandro describes how to use it like a template. He's clearly given it a lot of thought and includes being ready to measure the value as a first class attribute. My thinking marries-up with it in practice; make your increments as small as possible in order to bank the value of your work as early as possible.
This makes so much sense in so many ways. For me, just recently it is an antidote to the waste that can result from interrupting a workflow part way through a step. If the step is too large the chance and the cost of interruptions are both higher.
While I've been using this theme to illustrate choices I'm making around how I work and how I get things done in general, not just coding but the full gambit of work as a consultant software-craftsperson, the metaphors of trunk based development, continuous integration and continuous deployment all apply easily.
Don't start something without finishing it (thin vertical slices, continuous deployment). Any time you are working on more than one thing in parallel you increases the risk of there being conflicts that obstruct you completing either one (trunk-based, continuous integration). Such conflicts mean that one or both pieces of work will be delayed and time will be wasted.
There can be lots of objections to the statements above starting if we fail to mention that you must take small steps. If the tasks don't take long to finish then you can work on lots of different things in a reasonably short length of time. If you do have to throw the work away then it's not a big deal. Etc., etc.
Anyway, down to the note that I was copying up from paper...
Comparing time-based to task-based milestones
Note: the two things are not mutually exclusive, but comparison is useful.
In favour of the time based milestone
Frequent, guaranteed opportunities to refine focus, without interrupting workflow
Against the time based milestone
Work has to fit into a predetermined timeframe (can be seen as an advantage)
in favour of the milestone ending when all tasks are done
More flexible use of time. Work not interrupted by time window closing.
against the milestone ending when all tasks are done
Too much leniency on time. Harder for new issues to wait for the next milestone.
This is annotation of the following draft protocol, I recognise it is nothing new, it is just me noting it down in my own words having gone "round the houses" to arrive at a familiar conclusion.
Basic Protocol
- Start the week commiting to the milestone you want to reach before the weekend
- Create new issues as they arise throughout the week
- Unless they are pure refinement or breakdown of the in progress milestone, they have till at least next week – i.e. no moving the goalposts mid-game.
Like I say, nothing revolutionary, it's all been mentioned in eXtreme Programming and other Agile guidebooks before. Personally it's never seemed more obvious and simple to me.