![[personal profile]](https://www.dreamwidth.org/img/silk/identity/user.png){kind=small}
Managing project backlog
Sep. 21st, 2017 07:14 pmAt work we seem good at accumulating to-do items. Our Trac has many open tickets. Back when our workload was lighter, from Trac I would pick off the occasional longstanding bug and fix it. We since moved to Trello where we already have many labeled cards spread across many long lists on many boards. Trello is a virtual version of how I used to array post-it notes on my cabinets and walls. I have some thoughts about how this large backlog of Trello cards can be organized but in general there is an interesting management problem to be solved that our move from Trac to Trello does not much address.
I wonder how other large projects manage. Our increasingly many backlogged Trello cards do capture a lot of useful ideas, knowhow, investigation, etc. even if they must presently lie dormant. It is difficult to maintain enough awareness of them to know which to promote when to a more active board. We have other non-backlog boards for specific versions and products that reflect intent to act on their cards. Personally I fear that, as with Trac, we are already approaching a point where whole regions of our Trello space are largely neglected and forgotten, though by no means worthless.
I find Trello far from ideal but, assuming that we keep using it, I wonder what approach is best. Personally I favor dividing the backlog among our team, handing items around as best fits what we know. The idea is that we would each spend just a little time each week organizing our part and cycling a little further through it. Many of the to-do's in our brief review should be quickly handled as it still not being their time or accepting that they will never happen. Then, management need only consider those that members of our team put forward as candidates for acting on.
I wonder how other large projects manage. Our increasingly many backlogged Trello cards do capture a lot of useful ideas, knowhow, investigation, etc. even if they must presently lie dormant. It is difficult to maintain enough awareness of them to know which to promote when to a more active board. We have other non-backlog boards for specific versions and products that reflect intent to act on their cards. Personally I fear that, as with Trac, we are already approaching a point where whole regions of our Trello space are largely neglected and forgotten, though by no means worthless.
I find Trello far from ideal but, assuming that we keep using it, I wonder what approach is best. Personally I favor dividing the backlog among our team, handing items around as best fits what we know. The idea is that we would each spend just a little time each week organizing our part and cycling a little further through it. Many of the to-do's in our brief review should be quickly handled as it still not being their time or accepting that they will never happen. Then, management need only consider those that members of our team put forward as candidates for acting on.
