↓Skip to main content

Sprint 0.5: Planning a New Service Build

·3 mins
Software architecture Project management
Table of Contents

The Sprint 0.5 Scenario #

I often come across new, greenfield backend projects or brownfield rewrites of an existing service (usually a monolith) into a new service architecture (usually microservice), and a new infrastructure (cloud migration). It’s common—and a best practice—to kick off such a project with a discovery phase, unless product requirements are already developed and well understood by the implementation team. The discovery phase is sometime called “Sprint 0”, though it’s often a much bigger time and effort investment than a common development sprint.

It’s also common to invest in some technical architecture and project planning during that discovery sprint. What I’ve observed in some projects is the technical planning in discovery is just enough for a modicum of work breakdown and estimation. Discovery typically delivers just enough design documentation for feature build tickets or story tasks. However, and especially for a greenfield build, all that planning leaves a host of implementation questions hanging.

Are we set on language, libraries, and web stack? Have we agreed on code formatters, linters, static checkers? What are we using for CI/CD? Do we have a devops plan, to write infrastructure code and bring up multiple environments? And so on.

Sometimes, when an experienced team implements in a familiar organization with established practices, these questions are mostly answered. More often, work such as this creates huge friction in the early sprints and divergence across teams working on different services. And even for the ready-to-roll team, it’s worth going through a checklist, look for upgrade opportunities.

The pressure to, “Get going with delivery”, can be heavy. But resist!…if there’s a load of these non-recurring tasks hanging unresolved. Get them scheduled in, with full visibility.

I call this Sprint 0.5 work: NRE that has to be done, is better done at the beginning, and creates friction, disorganization, and divergence complexity of not done up front.

Refine the Architecture, Revisit the Plan #

When discovery phase technical architecture, planning and estimation is done, I believe it’s worth coming back to at the end of Sprint 0.5. The team has a lot more “feel” for the implementation at this point and is likely to do a deeper dive into tickets and more accurate estimates.

Or, better yet, only do the top level architecture and project breakdown, with minimal t-shirt size accuracy estimation during discovery. Save the deep dive until the tech work of Sprint 0.5 is done.

Of course, commitment to stakeholders, budget and deadline pressure may make this untenable. But at least validate your discovery project plan and estimates. And if Sprint 0.5 estimates are significantly greater than those from discovery, well that’s another problem.

Sprint 0.5 Project Breakdown #

Here I offer a canonical work breakdown for a sprint 0.5. The epics breakdown are part of a more detailed breakdown in this Sprint 0.5 project breakdown Google sheet.

Epic                       Tasks                                                           
Service stack template(s)  
                           
                           
                           		Select language, libraries, web stack for service and serverless
implementations; build out a "cookiecutter" template project;   
add standardized test runner, coverage, linters, static         
checkers, and formatters.                                       
Continuous integration (CI)
                           
                           
                           		Decide on CI (Jenkins, GH Actions, BB Pipelines, Travis,        
CircleCI); setup servers and/or runners; containerize template  
service(s); add test, lint, format to CI; add Dockerfile, CI to 
templates                                                       
Cloud infrastructure       
                           
                           
                           		Build an environment in infrastructure with template service(s):
container strategy (orchestration, etc), networking, databases, 
proxies, load balancers; implement with infrastructure code and 
validate with env spinup                                        
Continuous deployment (CD) 
                           		Establish branch/release/env SDLC strategy; connect service     
builds with env deploys                                         
Logging & monitoring       
                           
                           		Setup logging, APM, trace in service stack and feed to central  
logging; setup service health checks; add anomaly alerting      
(Slack, SMS, Pagerduty)                                         
Service architecture       
                           		Design entities, APIs, async tasks, etc. for initial set of     
services, including registration/authentication                 
Planning & estimating      
                           		Use architecture level design for implementation stories,       
estimates, and scheduling                                       
Initial build: sprint 1,2,…
                           		At this point each service can drop a code template with CI/CD  
ready to go and start a sequence of delivery sprints            

A Sprint 0.5 Gantt Chart #

As a practical matter of efficiency, much of Sprint 0.5 can be split among software architects, developers, and devops staff, allowing work in parallel, as suggested below.

↑