Agile is great, it makes the project flexible, allows for incremental development and allows for adding new features quickly.
However, it also allows for features to change quickly which can cause a headache to cope with the project's pace. In this article, I will explain how I approach new features to minimize that headache and successfully take the feature from a user story to production.
1. Understand the acceptance criteria:
This should always be the first step even before estimating the weight of the feature. The acceptance criteria should be clear from the planing phase. You must understand what business value the feature will add to the product. If that's not clear you can ask the stakeholders to explain. Usually, the stakeholders are the product team.
Ask about the business value and the acceptance criteria then write that down.
2. Prepare before starting the implementation:
It's crucial to have a preparation phase before starting to implement the feature. In this phase, you should check the code and investigate how this feature should be implemented. Often, you can find different approaches to implement the same feature. Assess all possible approaches, think of how easy/hard each approach is and how each approach might affect other functionality. If you're not sure which approach is better, you can always discuss with other team members.
Often during this phase, you will be aware of some corner cases that would be harder to fix if you would have chosen to dive directly into the implementation. You will also improve your initial approach by taking input from other team members. You might also need to ask more about how specific parts of the feature (ex. the state of a reservation in a reservation platform) should be set in order to align with the product.
In this phase, you should have clear steps of how to implement the feature (I like to write that down on the card itself). After this phase, it should be clear to whoever implements the feature (even if it's not you) what they need to do.
3. TDD to the rescue:
Now you're ready to start writing code. The best way to do so is by using Test Driven Development. Now you have the acceptance criteria and clear implementation steps which means you can easily write tests and implement the feature incrementally. This will also mean that any corner cases that might not be noticed in the preparation phase will be clear during writing tests before implementation. It will also give you another chance to make sure that you completely understand the feature. In general, TDD if implemented correctly will make your life easier. (I will write another post on how I use TDD)
4. Try the feature yourself before submitting it:
So you've finished the implementation but that's not enough to be sure that the feature works correctly. You have to try the feature yourself before submitting it to reduce the chance that the feature will be returned back to you with bugs. Try it and verify that it works correctly and that it passes the acceptance criteria.
5. Write any environment changes that need to be done:
Now that the feature works correctly, you need to write down any changes required to be done in the environment. For example, if you have created a new environment variable, write it down on the card. If you have changed any configurations in the project or in a third-party project, write that down. Try to be as precise as possible. This will ensure that the feature will not fail because of the different environments.
6. Submit the feature:
Now you can finally submit the feature to the Quality Assurance or the product team (depending on the process in your company). Whoever is responsible for accepting the feature now has all what they need to make it work correctly and the chances of the feature being buggy is greatly reduced.
Conclusion:
The agile process has its pros but it also adds some overhead to you as an engineer. However, with good preparation and some changes to your approach, you can greatly reduce the overhead and hence, make the process smoother and more efficient. It might be tempting to dive into the code directly but the cost of bugs becomes a lot greater if you don't prepare well.
Top comments (0)