When exploring an idea or plotting to build a new product, the success of a project depends not only on the code that’s written but also on making sure we’re solving the right problem.
Before a single line of code is written, we first must establish what the requirements of our project are, what the expectations are, and also establish any constraints. This is where two concepts can combine to great effect – Kidlin’s Law and scoping.
Kidlin’s Law states: ‘If you write the problem down clearly, then the matter is half solved.’ It’s a simple principle, but software projects thrive on clarity, and we’re able to achieve this clarity through scoping. And so, by keeping this principle in mind, the knock-on effect further down the line can be enormous as it can help us avoid costly mistakes and align stakeholders from day one.
We believe in the principle so much, that we’ve made our own discovery framework – designed to help you clearly define an idea or problem – free for you to download.
So how can this help us during a scoping session?
Clarity in the problem creates a better scope “definition”.
Effective scoping helps us define the goals, features, and deliverables of a software project. In essence, it defines not only what will be built but just as importantly what will not be built, and this process can be aided by keeping Kidlin’s Law in mind throughout.
By writing down the problem, stakeholders are therefore forced to think about what they actually want. This then leads to a better-defined scope and more realistic expectations. Such clarity can lead to a whole host of benefits for the upcoming project because unclear requirements can lead to issues further down the line such as scope creep, missed deadlines, or building the wrong solution altogether.
Early Clarity = Reduced Rework
Early-stage clarity is also much more likely to result in reduced rework as the ‘half solved’ problem that Kidlin’s Law suggests will prevent rework, misunderstandings, and change requests as teams avoid building what they think is needed and instead build what’s actually required.
Communication
Scoping typically involves many stakeholders, developers, product owners, etc. A well-written, scoped problem that follows Kidlin’s Law ensures that there’s an understanding across all parties, and everyone is on the same page.
Planning and Estimation
It goes without saying, but you can’t estimate a timeline or allocate resources for an unclear, undefined problem. Explicitly defining the problem at hand helps developers and managers make realistic estimates for costs and timeframe predictions, which are important in scoping.
Software projects thrive on clarity. We would be sleepwalking into problems down the line if we aren’t clear on what it is we’re actually building. By keeping Kidlin’s Law in mind in our scoping sessions, teams are able to plan better, build more efficiently, and deliver a project that is solving the right problem. That’s why we always must seek clarity before code.