Should Developers Write Software Implementation Plans?
How does one evaluate the result of work performed by a professional software development company? We at Railsware believe that one can judge it by the quality and the commercial success of the final product.
The “great product” outcome does not solely depend on software development skills, but also involves the whole range of processes and approaches a team leverages along the way.
Proper planning stands at the forefront of a high-quality product, providing a team with an opportunity to come up with and execute the best technology solution possible.
So, in this article, I will describe the software implementation plan, a concept that contributes to the planning stage of new feature development and takes place before actual implementation.
However, let’s be honest: People are usually reluctant to experiment by adding an extra step to a daily workflow without having any proof that the latter will benefit their work. Here’s why they should give it a try.
What Is an Implementation Plan?
A software implementation plan is a detailed checklist that is put together before the start of the user story implementation. In other words, it’s step-by-step instructions compiled by an engineer for either himself/herself or any other engineer to use in order to execute a task.
First of all, practicing implementation planning ensures that your team will:
- Dive deeper into every user story and learn how to make precise resource estimations
- Get a document with a clear structure, which makes execution faster and easier
- Have the chance to think through the task before starting to code it
But that’s not a complete list of benefits. Keep reading to find out more.
How We Perform Implementation Planning
So, the whole process looks as follows. We start with choosing user stories for the next sprint. After that, an engineer is asked to create a step-by-step implementation plan to complete a specific user story.
The implementation plan usually includes:
- A complete file path
- The aspects that should be changed in the file (for example, `add param **student_id** to strong parameters of **api/v1/shares_controller.rb**`).
- In tests—an exact file or context that needs to be updated with new tests, indicating other areas that should be covered by them
Generally, we try to avoid vague points like (“Add specs”) and instead be more specific about the tests that should be added.
To make an implementation plan easier to read, we tend to structure a checklist with subheaders split by subjects, like:
- Front End
- Back End
- Another Service
- User Interface Library
- Feature Spec
During the implementation, it’s not always necessary to follow the order of the initial plan, since it may change in the process of implementation.
Other important aspects that you should take into account are:
- Plans are dynamic and may be amended during the implementation
- The creation of an implementation plan and its execution may be performed by two different people
To document the implementation plan checklist, you may use any of these tools: Trello (inbuilt functionality), Clubhouse, or Smart Checklist for Jira add-on.
How Detailed Should the Plan Be and Why?
The existence of an implementation plan should give the task a definite level of certainty, making it much easier for an executor to comprehend, evaluate, and complete.
Among others, the core requirements for such a plan are:
- It has to include the necessary number of details to be easily understood by a person who hasn’t contributed to the creation of the plan. In other words, anyone on your team should be able to start performing the task based on your instructions and without additional consultations.
- Ideally, it should contain the full list of changes required to complete a story.
For more complex stories, an implementation plan can be considered “finished” once a task is free from any uncertainty.
However, I recommend taking only one day to prepare a plan.
We usually allocate this time for writing an implementation plan in order to:
- Make sure that it will be ready before the iteration starts
- Negate the risk of not meeting the iteration goals because of the extra time you needed to create the plan
As a result, having this time restriction motivates an engineer to dive deeper into the essence of the user story within a short period of time and document the findings as implementation plan action steps.
Applying Implementation Plans to Clients’ Projects
On my team, a single software development iteration usually lasts for two weeks. We hold a planning meeting before the start of the next sprint to synchronize on a list of user stories that we will work on. It is a good idea to have implementation plans ready before we estimate the stories for the upcoming iteration.
This approach can help a team:
- Develop a deeper understanding of user story requirements, taking into account even small details
- Ask questions and resolve uncertainty beforehand
- Gain insight into the complexity of user stories, which will help to make precise estimates later
- Investigate and brainstorm a few solution directions and variations, and pick the best one
Creating Plans for Different Types of Tasks
The type of task affects the way an engineer chooses to create an implementation plan. Before starting to draft it, one may differentiate tasks by the level of uncertainty present in them. This knowledge allows developers to apply the right approach to implementation planning, letting them come up with a clear guide to support software development activity.
Small and Obvious Tasks
When you are working on a small and obvious task, it seems apparent that there is no need for an implementation plan.
But if you still decide to take time and create a plan, you will be able to:
- Hand over this task to another engineer even if they are new to a project
- Explain in detail to a product manager all stages this task involves
It is worth noting that if the project you are working on is complex by nature, even the smallest and most obvious user story, being part of the larger task, will be 10 times more difficult than it appeared at first glance. And, if a project is straightforward, preparing a plan will be a super easy job anyway.
Therefore, to be confident, take a look at the code and write a plan.
Tasks With Some Level of Uncertainty
If you see that some aspects of a task are unclear, it is always a good idea to experiment before writing plans.
For example, you can:
- Write some code
- Fire up a webserver/SQL console, and make queries
This is when you will understand what is blocking your activity, as well as what needs to be done to proceed with the task. In addition, this is the same activity you would do anyway during the implementation itself.
Completely Unclear Tasks
Sometimes, it is completely unclear what an implementation process will look like, including what framework to use or which part of the app to update.
This is the right time to:
- Open the code and try to understand how it works
- Start writing code and experiment
After diving deeper into the topic, you will get a better understanding of the task and will be able to document checklists for those small things that became clear.
If after two to three hours of planning for one story you are still experiencing a high level of uncertainty, communicate this fact to a project manager (and other stakeholders) and ask for an extra one to two days to be allocated for a technical spike (which is a completely different story).
Once all unclear stories are written down, you will be certain that they were indeed unclear and will understand why.
The Consequences of Having no Implementation Plan
From time to time, I observe how different people treat an idea of using implementation plans as part of their workflow. Some of them are really excited about the detailed step-by-step instructions, while others are reluctant to use this approach at all.
As a result, ignoring software implementation planning brings the following consequences:
- The user story estimates are often inaccurate.
- Tasks are often completed in an inefficient way, or take longer than expected.
- Alternative solutions are not considered at all.
Translating the above points to the real world, we get a situation where developers estimate tasks based on nothing else but their first impression. In the end, a user story that was given two points cannot be delivered in two weeks.
Pros and Cons of Implementation Plans
Every approach has its own advantages and disadvantages, and implementation planning does not make an exception.
- This approach ensures a team can:
- Perform accurate estimations of user stories
- Understand all complexities
- Spot any roadblocks at the planning stage and reduce the tech debt
- Share the knowledge with each other
- An implementation plan documented as a checklist provides:
- A clear structure for a task
- An opportunity to track progress
- Providing a detailed action plan saves time and optimizes the whole development process by:
- Allowing you to consider all possible options and scenarios before coding
- Showing a full picture from the very start
- Letting you easily synchronize with people on your team, as well as external experts
- Allowing you to delegate any task to another team member with ease
It is important to remember that an implementation plan is never totally perfect. It requires constant improvement. And it takes time to create.
- That’s why, if you are working for a client, it will be difficult to explain and convince them to let the team spend the whole day on planning and not coding.
- You will not see the benefits right away. Remember that “practice makes perfect” and you should be ready to make mistakes until you start leveraging advantages from the approach.
- You will have to fight your ego, which surely says something like, “I am a ninja; my mind is as clear as any plan, so I will nail it in no time without any aid!” and acknowledge that you are not a ninja.
Getting Started With Software Implementation Plans
If you are convinced, I will leave this “getting started” advice so that you can start drafting implementation plans right away:
- Start practicing by creating plans for simple user stories first.
- Let other engineers “read” your plan and let you know whether it was detailed enough.
- Experiment with implementation plan structures and find the one your teammates will easily understand at all times.
- Make estimations based on your plan and then compare them against the real results.
- Learn to stick to the plan and be flexible about it at the same time so you can change it when required.
- Stop working on the plan when, after studying it, an executor feels no uncertainty about the task.
- Keep learning and remember that practice makes perfect!
I hope you found this article useful, and I’m excited to find out what you think about implementation plans, whether you apply them at your work, and just any other great experiences you can share!