3 ms·

That's a fantastic approach, we definitely need something like that where I work. It can get tricky sometimes though, because I need to add my own things to th

That's a fantastic approach, we definitely need something like that where I work. It can get tricky sometimes though, because I need to add my own things to the stack, like an improvement to the platform or a library, which means that I now need to play the game. But I like this simple to-do list approach, let everyone else fight over it.

wpietri 15y ago
There are a few ways to handle technical work like that. The simplest one is just to do those things as features require it. Most non-developers don't care about what the details of you're doing anyhow, so just don't tell 'em. The next way is to maintain a technical queue that's parallel to the main story queue. We use this mainly for improvements that speed the development process generally but no particular feature requires it. It's just understood that developers will do some of that each week. As long as we keep delivering other stuff, it's fine. The hardest way is to put technical cards in the product queue. I tend to reserve this for things that are large enough to have schedule impacts because getting a product person to understand the importance of some technical thing is always an uphill battle. For a lot of things, the real trick is to turn something from a "technical" card into one with direct end-user benefit. E.g., putting in a load balancer. Instead of talking about that, I write cards like "system handles X simultaneous users" and "system survives single-box failure". I'll still advocate for them, but when do do them ends up being a business problem.