As the old guy at a startup | Hacker News Reader

As the old guy at a startup

sofuckingagile.com

19 pointsasyncscrum7 comments

> "If you start at a new job and find something resembling a backlog in many areas, for your own sanity, thrown 90% of this out. It’s most likely a good idea to throw anything out that hasn’t been updated in a couple months. In start-up time, after a couple months it’s old news and no longer relevant."

I would take it all and consolidate to a single system so that there is one single source of truth. Do not throw things out, just prioritize them down where appropriate. But if you throw them out, you land in a CS problem where you get dinged on reviews because "I asked them for this months ago, multiple times. My request was ignored and they say they have no record of even having heard me." Of course, you are not going to do every little one-off request that comes in, but if you don't keep track, you don't know if it is really a one-off request vs. the 8th time some little thing has been asked for in the last 6 months.

Your customers do not care about "start-up time". They want a sustainable, stable product where their feedback has value. Don't throw out that feedback.

I think this is not referring to customer feedback backlog, but more internally generated ideas, reported bugs that are reported against features that have been completely reworked, things like that.

I tend to agree with the article, every startup I've worked at has had a large backlog of tickets in JIRA that were completely irrelevant to the current product. That stuff could be pruned pretty easily but never is.

I ticket with this in mind. Often I'll write a ticket and either categorize or write it to make clear the the idea/feedback/bug needs some time to ferment and prove its value. A lot of times these never get looked at again or (particularly with minor / difficult bugs) glanced at before being trashed forever. Things just look different with the passing of time.

OTOH some of my practices at a very small team would probably be incredibly harmful in a big team, I wouldn't take his advice without considering how it's applicable.

OP here, yes with a big team with established processes and a backlog that hundreds might be in love with, proceed with caution. And honestly, this is only to protect other people's sentimental value with the content. The lost time spent on backlogs with reviewing, reporting out, re-evaluating, migrating, reading between the lines, and other grooming, far out ways the handful of times you leverage it. This is an extension of the 'build trap' I feel, where we're convinced that we need to coddle the things that we might build.

In my experience, the things that get built that actually have impact are always recent realizations, not things that have been sitting in a backlog for a year.

New job? Collect as many jargon words as possible, find their standard English equivalent you're accustomed to using, and place all s/text/jargon/ in a script.

Pass your emails thru that file before hitting SEND and... instant success!

s/todo list/backlog/ s/prototype/mvp/ s/delay/priority adjustment/ ...

3 months in as the “old guy at a startup” and I can concur with a lot of this. Especially that my emoji game is weak.

Next stop, tiktok!

Reply on news.ycombinator.com