Hacker News new | ask | show | jobs
by jasonpeacock 2193 days ago
ShapeUp[1] makes the same argument as TFA. Either it's a bug worth fixing now, or it's not. If it's not, ignore it. In reality, nobody ever goes through the backlog saying "gosh, I have nothing to do, let's find old bugs to fix".

[1] https://basecamp.com/shapeup

1 comments

that's not true at all in my experience. In the past we've had "bug bash" type activities, or used that lower-hanging fruit as training opportunities. As an architect i've sometimes grabbed tasks like that just to stay fresh but also out of the way of the prioritized team backlog.
Bug bashes are a bit like cool down periods in my experience – if your focus is 100% on features all of the time then every now and then you need to catch up on open bugs or piled up tech debt. I'd argue these types of activities are not necessary at all when all stakeholders contribute to the scope of each iteration (see https://simplabs.com/blog/2020/06/17/failing-and-winning-at-...). Still, if a bug isn't taken on for x weeks or months, I'd say 99% of the time it never will be and can just as well be closed since it's ignored anyway.
Yep, ShapeUp describes an open "Cool Down" period between cycles, where people are free to work on whatever they want - favorite bugs, features, docs, developer tools, etc.

They discuss how everyone maintains their own personal list of what's important to them and use that to drive their work.

But maintaining a single, centralized list of everything has little value. Anything important is already being tracked in the roadmap, including bugs impacting customers of sufficient priority.

It really is worth reading the ShapeUp book, it provides a good, alternate view of commonly-held beliefs.

ShapeUp is great! I don't think a cool-down phase is good though – if something is important to someone and it is indeed important for the business but still doesn't get planned in any iterations that means either

a) it's not actually important compared to other things so having someone work on it in a cool down phase is likely not well-spent time

or

b) there is a dysfunctional team/organization in which important stuff doesn't get prioritized correctly (typical example for this being 100% product management driven organizations in which refactorings etc. never get any time assigned)