Hacker News Reader

Comment by milesvp | Hacker News Reader

This list is missing the most important one in my experience.

Stop trying to do so much.

I was on a team that really got good at pushing back on aggressive estimates. You wouldn't believe how much more we got done and the things we worked on were of higher value when we stopped agreeing to add more to our sprints.

It really helped that we got good at doing retros. Where we looked at what we said we'd do vs what got done, and saying, well, next time it looks like we can only agree to X% of what we think we can do.

Like, I know the phrase "slow is smooth, smooth is fast", it'd worked really well for me when doing physical tasks. This was the first time I'd experienced it for mental tasks as well.

View on HN

As a solo dev, "slow is smooth, smooth is fast" coupled with ruthless focus and prioritization has resulted in the biggest increases in my productive output.

None of the OP’s tips for increasing product velocity apply to my company. The essence of product velocity reveals itself when N=1.

Focus on a few things. Don’t rush, do them well. Say no to everything else.

The article is talking about throughput not latency. There are not dates mentioned.

Forgive me. I thought I was being clear that I was talking about throughput.

My team, when we started to get better at not overcommitting in any given period was able to produce more countable work. Not just more story points (inflation is super common) but more actual deliverables. It was weird, because we all felt like we were working less, we just thought we had to be honest about our commitments. But when you looked at the trend line at the end of the quarter, there was an increase in what we were able to do.

I don’t claim to know why this works, but it’s such an old phenomenon that there are lots of sayings that hint at it. I know that when I’m personally not overcommitted I have more capacity to focus. When I have fewer things on my plate, I context switch less. But I think something else happens as well. When you say no to things, it forces others to be more deliberate with their asks. They stop asking for low value things.

Excellent

Seems likely that a big reason for the increase was unseen, but cumulatively huge. When everyone is not rushing so much, fewer interruptions happen. Each is tiny, but the cost of context switching is cumulative and even nonlinear. You're benefitting from bending that in the good direction - reducing thrashing.

I'm on a 4 dev team (one of many). 3 of us commit to only do what we are pretty sure we can do. One of our team commits to way more than they should. Guess which of us is always carrying over stories and whose new functionality creates new bugs ever sprint? They never can wrap stuff up completely, they are like a tar ball of chaos. Unfortunately they are supposed to be our tech lead so all we can do is shake our head and watch.

Reply on news.ycombinator.com