I was just explaining to a fellow indie hacker that scope creep is something to be aware off. He never really planned in advance what he wanted to build exactly. Every time we talked, the feature set somehow shifted, widened.
Now, with an upcoming deadline to meet, I was explaining the fundamental problem with scope creep. For us, indie hackers, scope creep is a serious danger too, because it affects the duration of the project, the moment of truth and our emotional position towards the project.
While linking to the wikipedia page I found a very curious note about the positive sides of scope creep:
Scope creep can occasionally have incidentally positive results. For example, the video game The Elder Scrolls: Arena was originally intended to be a "medieval style gladiator game",[3] but due to scope creep, the game quickly expanded into an open-world, epic role-playing game (without the titular arena combat at all), spawning several successful sequels of increasing complexity.
I used to be a passionate gamer and really loved the Elder Scrolls series. So this fact was shocking to say the least. The only reason the series was a success was due to scope creep..
Looks like sometimes losing control of the creep is beneficial too, might as well keep that in mind. Allow yourself to pay more attention to a feature, the ux or whatever you think is important to you.
yeah great point. it seems like scope creep has a negative connotation but it may just be neutral. i think the key to deciding whether to widen or shrink scope of any sized chunk of work is deciding how much reliable impact it will have for the effort your about to put in. if working with others, especially non-tech people it's super important to walk them through enough to understand the scope decision and get in a good habit of sizing work in a way that works best.
If you are ready to change the deadline of your project, you can add new features.
If you need to deliver at a precise date, don't.
If you just develop random features without any plan, it's very likely your project will never be finished for you, therefore never released. You need a planning with precise and define tasks plus you need to know what features you need for your beta / first launch / second version and so on.
You can add a time dimension in your planning if you need it. If it's a side project, you don't need deadlines.
I love how you end with side projects not requiring that set of requirements 😅
Sorry I wasn't clear: if you want to ship your side project one day, you need planning and requirements. Only the time dimension (deadlines) is not necessary, if you don't want to.
Obviously that was your point and I totally agree. There's one exception to the rule I guess, which are projects meant for education/self-learning having no definite goal.
This comment was deleted 7 years ago
That's a great alternative perspective, thank you for sharing. It must have been hard having to lose the financial support last year.
I must agree with the "dirty template disappointment" you felt, I'm no good at all when it comes to design. But I always ran into the same experience of trying to cramp components into the limited design elements the template offers. As such I'm very glad I had the support of a great designer, even though he jumped ship and the design will be made from scratch in the coming months.
Scope re-definition is never unwise. Especially with projects that take this long. You could say this was a moment of reflection for you two. I wouldn't be surprised a lot of startups release a version seriously pivoted from the initial idea they started with.
I hope it works out, I'm following you so I will be patiently waiting for what you come up with.
This comment was deleted 7 years ago