I came across this article by Phillip Calçado wherin he introduces The Rule of the Second Card.
The first card played on a given area of the code base is expected to take a long time. The second card should take at most half of the first card’s time.
This obviously only applies to the first and second card in a new area of work. Because the first card will need some time an planning, possibly some spiking to evaluate potentional solutions, it is expected that the first card in a new feature is going to take longer. This is a great rule of thumb that, when broken, can give several indications of a project being in an undesirable state.
Hack Job
The developer (or pair) that did the first card possibly chose a poor implementation that created a lot of technical debt. Therefore the developer on card two has to do a lot of rework. Typically a secondary card should be a small incremental addition to the first and should not require major structural changes.
Poor Planning
It could be as simple as the fact that the wrong card was developed first. It is likely that the cards were not prioritied with work flow in mind. Agile principles say that the customer should prioritise the cards, but I think that prioritsation is a group task. This lets the developers make sure that "this card would be easier to do after that one" actually influences the decision.
Poor Acceptability Test
A lack of clear and sufficently complete acceptability tests may result in a card being prematurely defined as "Done". Obviously something that is incomplete is going to affect further work.
Poor Estimation
A simple and highly likely situation is that the cards were estimated incorrectly.
So it is quite easy to end up in a situation where a secondary card is going to break The Rule of the Second Card, but when you do, it is time to reflect on why, and how you got there.
Comments