[nathas]

We're doing 2-day sprints at work, and it largely has the same effect in terms of productivity.

Very clear, concise, sharp goals that are actionable and measurable.

Programmers can decently estimate what they can do in a day. I know I struggle to estimate for longer projects.

[talmand]

Questions...

Is there any concern of burnout with maintaining such a pace?

What happens if something slips the 2-day goal?

How do you deal with something that requires more than two days? Split it up over multiple sprints? What if you can't?

[nathas]

It's a startup, and I've read 10+ articles on HN saying "< 40 hour work week is most efficient for technical work".

While I agree, focusing on getting something shipped every 2 days isn't a huge pace. It means you iterate tightly and goals are understood to be scoped to only 2 days of work.

If something slips the 2-day goal, it's debt, and it's expected to be nailed first-thing in the next sprint. It's a flexible system.

For bigger projects, you _have_ to be able to split them up. I honestly can't think of a single project where you couldn't break it down into constituent parts in which you could iterate through several sprints to finish it.

If you're doing research-based work, I'll admit this probably isn't the best approach. However, from a business and personal productivity perspective, it's working very well.