Estimation and planning are critical to a successful project. Agile practices allow for a collaborative, fast, and flexible development process but it is important to identify and accurately estimate critical path tasks early in a project. Establishing a detailed backlog can be challenging enough when developing a greenfield application, however, the nature of microservice projects is such that these challenges become amplified. As the project progresses, new dependencies and challenges will continue to be discovered, making it difficult to estimate the complexity of tasks up front and to establish a reliable backlog. Therefore, a different approach is needed to manage these projects so that a predictable timeline can be established, shared, and planned for.
The Challenge of a Monolith Application
When you begin breaking down a monolith application, the constraints of the existing system and architecture have to be worked through. Often, the monolith is a culmination of generations of architectures, patterns, and approaches accumulated over years or even decades. As you begin to tease the system apart after identifying the service boundaries, broad application-wide dependencies will surface, which will have to be resolved. Typically, these dependencies are concentrated around the data model, domain model, and application-wide features.
Because of these characteristics, microservice projects require a significant amount of discovery and investigation, which is inherently difficult to estimate, leading to more ambiguity at the beginning of a project. This challenge is compounded when the monolith has grown beyond the point of any one person’s comprehension and is instead shared amongst many developers and domain experts.
Overcome The Ambiguity
So how can we address the unique challenges of tracking and estimating microservice projects, with the ultimate goal of determining a reliable timeline and project scope? At Headspring our approach is to focus on determining velocity and then using that data to estimate an appropriate project timeline. Here’s what that looked like for a recent project:
Get Started: Discovery and Deep Dive
Our team spent the first sprint digging into the existing codebase of the selected service boundary. The primary goal during this initial sprint was to analyze the dependencies within the service boundary, determine a plan for addressing these dependencies, and identify code which needed to be extracted or refactored to operate as an independent service. This effort resulted in a high-level backlog of both concrete development tasks and research tasks capturing areas which needed to be explored deeper.
Establish Velocity: Execute Tasks and Add Clarity
As the team progressed through the following two sprints they executed concrete work without estimating time or complexity. Additional granularity was added to the backlog, and more clarity was gained from the high-level research tasks previously identified. Throughout these sprints, the entire team participated in pruning and building out the backlog.
Use Velocity to Estimate The Backlog
After the two sprints were completed, five tickets of various relative complexity were selected and assigned appropriate story point values, which were to be used as benchmarks for estimations. The Fibonacci Sequence is one example of a system to use for estimation points.
The team then retroactively applied estimates, based on the completed benchmark tasks, to the work completed to date. The resulting data revealed a velocity for the average number of story points that could be completed in each of the two completed sprints. This measure was then used to estimate the remaining backlog of uncompleted work and to approximate a completion date for the microservice effort.
This approach has allowed us to establish realistic project timelines in the early stages of microservice projects. Focusing on establishing velocity and a benchmark, rather than detailed accurate estimates at the beginning of a microservice project, is an approach which can help balance a development teams need for flexibility and businesses need for a predictable project schedule.