Kenneth Larsen

March 5, 2021

Product Notes: Building Rome in a Sprint

It turns out that Rome wasn't built in a sprint. I think this resonates with a lot of people who do product development because often the expectation is to build Rome in a sprint. Why is this happening?

1. The Scrum guide says so

Chances are that you are following a 2-week sprint cycle. Why is that? Do two weeks match the time it usually takes to develop a medium-sized feature in your codebase? Or did you find the 2-week number in a book about Scrum? Building anything a sprint requires an understanding of how long it generally takes to deliver features with your setup.

2. Maybe your stakeholders are not aware

Often I've heard complaints about lack of developer experience, slow deployment processes, and horrible legacy code. These issues will often hinder a quick delivery. But when I ask "Have you shared this with a stakeholder or manager?" the answer is surprisingly often no. If your stakeholders are good people they will listen. If they couldn't care less then you are most likely not working at a very nice place.

3. The MVP that lasted forever

Has anyone ever told you that "if we can just ship this MVP real quick then we can refactor it later once it has proven itself?". If so, how often did you get to refactor? My guess is not very often. This will leave developers disappointed and stakeholders happy. An unequal happiness balance is dangerous if it is happening often. But if you don't refactor that MVP, you'll end up with roman ruins in a sprint.

These were my notes about product development from week 9. See you next week.