Winning with Scope Creep - Building Next Team

Context

Scope creep is a projects killer. You keep adding feature after feature, project becomes complex, changing things becomes harder and pivoting into something else becomes impossible.

It starts innocently. Some user of your app tells you how painful is something to do. Or how cool it would be to have something else.

Saying NO is hard. Your mind (and maybe other people) will challenge you: “isn’t it a simple change?” or “wouldn’t it be great if we could do X?“. The worst thing one can do is to rush to a keyboard and spit out the feature into codebase.

In this blog post I wanted to share a story how I won with scope creep in one of my little side projects.

Meet “Next Team”

The need was simple. My group of friends love to play Time’s up.

If you don’t know it - it’s like Taboo but on steroids. In short:

• two teams - no limited amount of players
• one person describes something, rest of the team is guessing
• after X seconds (usually we play 30 seconds) we rotate who describes the word and which team is guessing
• there are 3 rounds, in each round there are some additional constraints
  • describe term using as many words as you want
  • describe term using only single word
  • describe term only showing it (no sounds allowed)
• there is the same pool of terms to be guessed in all 3 rounds - you benefit when you can remember what was in the pool

Multiple times we ended up spending time and not having this game with us. For some time we were using a version on Play Store but then it disappeared.

So I decided to re-create it.

Defining requirements

Before that, I had many side projects that have been never finished. They all had few common denominators:

• incredibly ambitious
• trying to solve problem using advanced and complex technology (kind of microservices with event bus between them(
• even if they were trying to solve interesting probles, they were too hard to deliver

This time I said it will be different. I cut the scope to the minimum:

• Simple website
• Frontend only
• Players will pass phone to each other after their turn is finished. We don’t need everyone to be playing on their phone.
• Settings page may be ugly - it’s rare to be visited by players.

Execution

Even if building frontend wasn’t my thing back then, I delivered it in ~3 evening, figuring out React on the way. It wasn’t perfect but it was functional. Chat GPT generated lot of content for us to guess. It wasn’t perfect, but it was enough for having fun during game.

After one week we played it for the first time. I got some feedback from friends. I applied it. We played it dozens of times later on and some friends started to use it during gatherings with other friends / family memebers.

Demo time

You can check it out at https://next-team.proszowski.dev.

Conclusions

There’s some feedback I didn’t address. And guess what. Even without it addressed my friends and family members are using it and have fun.

That’s the power of solving the right problem. It doesn’t have to be solved perfectly well!

Also this experience showed me that the faster I delivered working thing, the faster I got feedback on which I could act on.

It’s a very simple example, but these things are translatable to bigger projects as well.

Cut the the scope to minimum. Ship fast. Decide if it’s worth acting on the feedback you got or not.