If you're looking for the previous "Milestone Size" I guess it was the note about thrashing. Ultimately I'm on a the-power-of-baby-steps theme of late.
As I write this and the last note I'm remembering Sandro's words on minimum valuable increment. The description is not the same as what I'm toying with 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 impact as a first class attribute. My thinking marries-up with it in practice - Make your increment as small as possible 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, how I get things done in general, not just code but the full gambit of a consultant software craftsperson, the metaphor of trunk based development, continuous integration and continuous deployment all apply perfectly. Don't start something without finishing it. The long you have more than one thing running in parallel the more chance there is of conflicts. The more chance there is that one or both of the branches will be delayed and work will be wasted.
Anyway, down to the note...
-
in favour of the time based milestone
Frequent, guaranteed opportunity to refine focus without interrupting main workflow
-
against
Work has to fit into a predetermined timeframe (may also be an advantage
-
in favour of milestone ending when all tasks are done
More flexible use of time. Work not interrupted by time window closing.
-
against
To much leniency on time. Harder for new issues to wait for the next milestone.
This is all annotation of the following recommended protocol. In publishing this 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 with a defined milestone to reach by the end of the week
- Create new issues as they arise throughout the week
- Unless they are pure refinement or breakdown of the in progress milestone they cannot be added to it 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.
React
Typescript
Django
Laravel
Facebook
Microsoft
Google
Alibaba
D3
Tencent