Our foundational approach was inspired by our experience with Pivotal Labs in the early 2010s. During this time, we recognized the need for a structured approach to planning work on user stories for each sprint—a process we now refer to as the Implementation Plan.

But what is it exactly? How detailed should an implementation plan be? And how do you handle differing client opinions? In this article, we’ll tackle these questions head-on and guide you through creating an implementation plan that truly delivers.

What is an Implementation Plan?

An implementation plan is a detailed and specific plan written in a checklist format, meticulously crafted by developers before they begin working on each user story. This plan serves as a mini roadmap, ensuring that every aspect of the task is thought through and accounted for before any code is written.

In essence, the implementation plan is a step-by-step guide for executing each task, created by engineers for themselves or other developers on the team. It breaks down the user story into manageable actions, helping to prevent any overlooked details and providing a clear path forward.

Engineers often resist adding extra steps to their routine processes, especially when it comes to planning. It’s easy to see planning as unnecessary overhead. However, I believe that the implementation plan provides significant advantages:

1. It forces the team to deeply understand the requirements of each task, leading to more accurate time estimates for implementation.
2. It prompts developers to think critically about the task before diving into the code. That can help to reduce the likelihood of mistakes and rework.

Stay tuned, as I’ll share more about the benefits of this process later on.

How does this approach work?

Here’s how the process unfolds. First, we identify which user stories will be implemented in the upcoming sprint. The engineer’s task is to craft a detailed, step-by-step Implementation Plan for each one. This plan generally includes several key components:

1. The full path to the file: The engineer pinpoints the exact location of the file that requires modification, ensuring clarity and ease of access for the entire team.

2. Specific changes to be made: The plan outlines the exact changes needed in the code, providing clear instructions to avoid any ambiguity. 

For example: add ’user_id’ parameter to required params of ’api/shares_controller.rb’

3. The testing plan: This section may detail which files should be covered by tests and what data sets need to be verified, ensuring that nothing is overlooked.

To make reading and navigation easier, we structure the checklist by headings:

• Frontend;
• Backend;
• UI Library;
• Specs.

A few key points to keep in mind:

• During implementation, it’s not always necessary to strictly follow the order of steps laid out in the plan. It may be adjusted during development.
• The details of the plan are not static and can be modified as the implementation progresses.
• The person creating the implementation plan may not be the same person executing the steps outlined in it.
• For creating the checklist itself, you can use any tool that suits you. We usually work with the Smart Checklist add-on for Jira.

How detailed should the implementation plan be?

Remember that our primary objective is to structure and streamline the development process as much as possible.

In an ideal scenario, the implementation plan should detail every change required to implement the functionality. These instructions need to be clear and comprehensive enough for any engineer –regardless of their familiarity with the project – to understand and execute. The goal is for even new team members to be able to step in and start working on the user story without needing additional guidance or instructions.

For more complex tasks, the completion of the planning stage is marked by the absence of any remaining questions about the task’s requirements or uncertainties in its implementation. Each stage of the plan should clearly define:

• Which tools, technologies, and frameworks should be used for the task.
• Which sections of the codebase need to be altered and how these changes should be implemented.

Preventing blockers and misunderstandings

If any aspect of the plan remains unclear, our next step is to dive into the code itself. This allows us to understand more deeply how the current code works and what specific changes are needed. Without this level of detail in the plan, developers would have to perform similar exploratory work during the development phase, which could lead to delays or inconsistencies.

In the first checklist example, tasks are organized by areas like Backend, Frontend, and FeatureSpec, with specific steps and modifications outlined for each. This detailed breakdown ensures that every developer has clear instructions, reducing ambiguity and keeping the project on track.

The second checklist focuses on more complex backend logic, such as data migrations. By specifying these steps in advance, the plan addresses potential challenges proactively, minimising unexpected issues and ensuring a smooth development process.

When the implementation details are uncertain—such as which framework to adopt or which specific component of the application needs to be modified—the plan may need to include an initial phase of experimentation. In these cases, we often set a time limit for this experimental phase, such as one day. This allows the engineer to explore different approaches, clarify uncertainties, and gather the necessary information without extending the project timeline unnecessarily.

How to structure the planning process for projects

Before starting an iteration, we conduct an implementation planning meeting (IPM), where we plan and estimate tasks for the next two weeks.

It’s most effective to create the implementation plan before estimating tasks for the sprint. On Monday, we begin with a list of tasks for the new sprint. Throughout the day, we study, analyze, and discuss them with the client, ensuring that each planned task will have a real impact.

Why does this approach work?

• In-Depth Understanding: Delving into each user story’s details before development helps you see the big picture, clarify all requirements, and anticipate potential questions or solutions, saving you time later.
• Complexity Assessment: By assessing the complexity of each user story, you can more accurately estimate the necessary time and resources, ensuring better planning.
• Pre-Planning Details: Planning implementation details in advance minimizes additional questions for clients or product managers, streamlining the iteration and conserving resources.

Specifics of planning for different types of tasks

Small and obvious tasks

unnecessary, especially when everything appears clear. However, even for seemingly simple tasks, having a checklist in place offers several key advantages:

• You can easily delegate the task to other engineers, particularly those who are new to the project.
• It provides a clear overview of all the implementation steps, allowing the product manager to understand and validate the estimated effort.
• It confirms that the task is as simple as it seems and doesn’t hide any unforeseen dependencies.

In large projects, experience often reveals that tasks initially deemed simple can quickly become more complicated. If the task is indeed as straightforward as it appears, drafting an implementation plan will be quick and painless. A brief code review and outline ensure everything is on track and eliminate any surprises.

Tasks with some level of uncertainty

When parts of a task are unclear, it’s smart to run a few quick experiments before diving into full implementation planning.

For instance, you might:

1. Write some test code to explore a potential solution.
2. Open the web server or database console to inspect key queries.

This approach helps uncover any roadblocks and clarifies your next steps. Since you’ll likely be doing similar work during the actual implementation, this time spent experimenting is far from wasted—it sets you up for a smoother process later.

Completely unclear tasks

Whether it’s figuring out which part of the application to modify or deciding which framework to use, sometimes tasks can feel daunting because you don’t know where to start.

The solution? Experiment. Dive into the code, see how things function, and start brainstorming possible approaches. For the parts that make sense, create checklists. This process often brings much-needed clarity.

And if you still haven’t made headway after a couple of hours of planning, it’s a good idea to talk to your manager and propose taking an extra day or two for a spike (a more in-depth exploration of the task).

In these cases, the implementation plan is key in highlighting the need for further investigation and understanding the areas of uncertainty. Planning ahead like this helps manage risks and ultimately saves time when development begins.

Using implementation plans across different teams

At Railsware, we’ve had the privilege of working with teams from all corners of the globe, each bringing their own unique approach to tackling tasks. Early on, we noticed something interesting: no matter the team, the way they interacted with the implementation plan could either make or break a project.

In one instance, a small team started with a solid plan but made a few seemingly minor deviations along the way. What started as tiny tweaks quickly snowballed into delays and confusion, leaving everyone scrambling to get back on track.

On the flip side, we’ve seen teams that follow the plan closely, adapting only when absolutely necessary, and delivering tasks smoothly and efficiently.

These experiences taught us that the plan is more than just a checklist—it’s a mini roadmap. And when teams respect that roadmap while staying flexible enough to adjust when needed, execution becomes far more streamlined.

It’s not just about sticking to the plan, but knowing when and how to pivot, keeping the project moving forward without losing sight of the bigger picture.

Common obstacles to watch out for

Lack of consistency among new engineers

When a new team member joins a project, they often bring a high level of enthusiasm for creating detailed plans. This approach helps them quickly integrate into the process and track progress effectively. However, as they become more familiar with the project’s intricacies, their adherence to detailed planning may wane.

Over time, the checklists tend to become less detailed, and eventually, the engineer may stop creating them altogether. With increased confidence, engineers might start estimating tasks “on the fly.” This can lead to issues where a task initially estimated at two points remains incomplete weeks later.

Teams avoiding detailed task planning

Some teams prefer to minimize planning before implementation, either by not planning in enough detail or by avoiding it altogether. This approach can lead to several issues:

• Inaccurate Task Estimation: Tasks may be estimated poorly, resulting in outcomes that differ significantly from expectations.
• Inefficient Task Execution: Tasks may take more time or be completed less effectively than planned.
• Missed Alternative Solutions: Potentially effective alternative solutions are not considered.

Pros and Cons of implementation plans

I’ve outlined the benefits of creating Implementation Plans and the difficulties faced without proper planning. Let’s summarize:

Pros:

A checklist-based implementation plan offers a clear structure for task execution and progress tracking. A detailed action plan saves time and optimizes the development process by:

• Exploring Options: Reviewing different options and scenarios before coding begins.
• Providing a Complete Picture: Offering a comprehensive view from the start of the work. 
• Facilitating Synchronization: Simplifying coordination with team members and external experts. 
• Task Delegation: Allowing for effective delegation of tasks to other engineers.

Cons:

• Continuous Improvement: The plan is never perfect and requires ongoing refinement and discussion, which can be time-consuming.
• Client Buy-in: On client projects, it can be challenging to convince clients that a full day of planning is more beneficial than coding.
• Delayed Results: The benefits of changes in processes may not be immediately visible and may require several sprints to assess effectiveness.
• Psychological Factor: Belief in the value of detailed planning is crucial. Sometimes, it’s necessary to set aside confidence in one’s project knowledge and ability to estimate tasks intuitively.

Wrapping up

Planning might not be the most glamorous part of development, but it’s the backbone of smooth execution. Start small, stay flexible, and keep improving. You’ll find that even a simple checklist can be the difference between a quick task and a frustrating delay.

But this is just a glimpse into how we work. Want to see how effective planning can transform your projects? Dive deeper into our products and services—where efficiency meets innovation. 

And if you’re looking for your next career move, we’ve got exciting opportunities waiting. Ready to plan for something bigger? Check out our vacancies and join the team!