In this blog I'll be guiding you through the process of creating a new feature for an existing application.
This step-by-step guide will be divided into 3 parts: Analysis, Implementation and Release. Each part will be treated in a separate blog post to make the information offered a bit easier to digest.
Our first part will explain the Analysis phase. In this post we will be spending most of our time listening, thinking and doing research to have a deeper understanding about what the goal is, and how we're going to achieve it. Let us dive right in!
Sit down and take your time to ingest the new feature's requirements. Don't ask too many questions. If you have questions it's better to take note of them and wait till your customer has told you the entire story. You will not have all information yet so your question will likely be premature and easily lead to confusion (on your part and the customer's). Your questions might answer themselves by the end of your customer's initial briefing. Once you've absorbed the requirements, take some time to reflect and ask those first questions that popped into your head if you believe they are still relevant by now.
After you got a good grasp on the requirements, take a moment to truly understand why this feature is being implemented. It's important to understand why these business decisions were made.
This step is often neglected or forgotten entirely but it is probably one of the most important ones of the whole process. It will help you see the future of the application. It will also make you think twice about how you should implement the feature. You can keep in mind new features that likely might follow, meaning you'll be able to design the feature in a scalable way as well as avoid over-engineering.
If you're implementing a new feature this means your application has an existence and other features will most likely follow later on. So scalability should be one of your main concerns, not only to stay friends with your future self, but to protect your application from decaying into a messy code swamp.
Now we're rolling, we know what we're going to build, and why we're building it. Next up: how? Take some time to explore some options, putting together a proof of concept is allowed at this stage. You need to be able to see the end of your solution.
Try get rid of as many unknowns as possible while answering as many questions as you can. If multiple options are applicable, compare them. List the up- and downsides of each and try eliminate your options one by one till you have only one left: the best solution.
If you can't narrow your options down to one, this usually means you still have some unknowns or questions. Take your time to write these down in preparation of Step 4.
After you've gone through all previous steps you should now have a comprehensive overview of the feature's requirements and any unanswered questions. Take some time to sit down with the product owner, ask your questions, and debate the options you have identified as candidate solutions.
When presenting your candidate solutions it's important to help your product owner make the right decision by pointing out relevant concerns to him. Give him insight on why option X might work better than option Y, explain to him why a certain requirement should be handled in a different way. It's your job at this point to make sure everyone is on the same page before you start the actual implementation.
This moment of feedback might yield so much new information you'll have to go back one step to modify your analysis or even start all over again. Repeat this process until you have a solid solution that makes both the product owner and yourself happy.
Analysis is all about listening, understanding, researching and asking questions. By the end of this process you should be able to answer any questions about the feature and know exactly how you're going to implement it.
This was just the start of our 3-part series on how to build a new feature in your application. Visit our next part: Implementation.