> If you don't have a PM, don't fuss with trying to rotate acceptance duties amongst the engineers. Use a different tool, one that doesn't have as strict a separation between designing, delivering, and evaluating.

Okay.

> One of the insidious things about Tracker (and a lot of Extreme Programming practices) is that it can lure you into thinking that substitutes for customer feedback are just as good as the real thing. "The feature's finished, I clicked 'deliver' and the PM accepted it." Nope. The feature isn't done until you hear back from a customer about it.

So, if Tracker can't track stories though their whole lifecycle, why not use a different tool that can?

The answer is that for institutionalised Pivots such as the author, there is an identity between Pivotal Tracker and correct process. So, if you want to follow a shitty process, don't use Tracker, but if you're following a good process, Tracker must be the right tool. Even though it still can't do this very basic essential thing.

That said, i strongly agree with almost all the practical advice in this piece! Perhaps not surprising, given that i'm a partially deprogrammed ex-Pivot.

Oh, except:

> Delete your icebox

I've never heard an argument for this that made any sense at all to me. I suspect this is just another manifestation of deletionism vs inclusionism, and as such, there is no explanation for either belief that is intelligible to someone who does not already believe it.