Beyond Sprints: A Scalable Milestone-Based Planning Model for Midsize Companies

Imagine a scenario. A software startup company, featuring 3 development teams and utilizing a Scrum framework, starts working on something promising and significant: AI integration to their existing product solution. They decide that the next quarter will focus on developing an AI that aims to deliver the minimum necessary toolset for their clients. They define a backlog and stuff it with features and priorities. Teams Eagle, Tiger, and Lion pull features from the backlog for their sprints.

This is where problems start. Team Eagle discovers that the feature they pulled depends on the feature that Team Tiger has pulled. They decide to wait until Team Tiger has completed development. Simultaneously, Team Lion’s work is shuddered to a halt when they realize they don’t have enough members with a sufficient skillset in the domain area. Lion must learn it from scratch and waste time on catching up. For all three teams, Eagle, Tiger, and Lion, the majority of features remain in the backlog. Complex and tedious, these neglected features gather dust in the backlog as teams prioritize those that will meet deadlines. The work on them will only start after an additional decomposition and the manager's pitch. In the best case scenario, a company spends 60%-70% of time on features and the rest on figuring out planning.

This scenario isn’t rare but a pattern that often plagues growing tech companies. For many years, Scrum has been a popular framework to organize and execute software development. The process is pretty straightforward: define and prioritize a backlog, break down the release cycle into iterations, and pull the important items in each iteration from the top of the list for team execution. Team members select work they’d like to do from the iteration tasks based on their preferences. Sounds simple and easy to follow. However, there are some nuances:

1. Scrum is designed to work perfectly for only one team. When more teams are involved, the process doesn’t scale well. The backlog grows massive. Work items have many dependencies and are specific to particular modules and domain areas. Task allocation is based on the tightrope of juggling between priorities and particular team member preferences. Consequently, sprint planning is messy and time consuming.
2. Short term planning by sprints may answer the question of delivering particular features or use cases within the next weeks or a month. However, many projects require months or even quarters to deliver with no way to prioritize and track the progress for those projects in the scrum process. For teams, scrum is essential. From the strategy standpoint of the company and its clients, it’s chaos.
3. Sprints put boundaries on release timing, which does not necessarily fit the feature MVP size. This creates an artificial need to place barriers, such as feature flags for functionality that are deployed within the sprint but dormant until the feature is completed.

The Solution
Now let’s think about alternatives or potential improvements to this process.
Let’s craft a thought experiment with a few adjustments:

1. We remove the boundaries for sprint planning and replace it with the boundaries for company planning. A milestone that features a particular strategic goal (such as a key result or direction) and time constraints that match it (quarter, year, etc).
2. Instead of allowing teams to select tasks, we allow them to select their domain area and specialization. We then allocate those tasks between teams manually or, preferably, by developing a script or using the automated scheduling and planning app Deep Planner, which takes into account task estimates, priorities, dependencies, and team capacities.
3. Teams perform tasks based on their assignments and use a continuous delivery to commit their work. No more feature flags.
4. Upon changes in priorities or delays in implementation the remaining tasks on schedule are re-allocated based on the new conditions by maintaining the strategic milestone direction. It is important to let the teams finish their work on tasks in progress or replan them wisely to avoid disruptions in development and teams’ dissatisfaction.

With those adjustments Team Eagle will have work allocated before Team Tiger completes the blocker. Lion will never work on the task which they lack skillset. Instead, it will be assigned to the team that is better suited for it. All tasks from the backlog will be allocated efficiently and will use all of the teams’ potential.

In my work as a Product Owner, I practiced this approach multiple times and found that it shows very encouraging results. Our planning time and the related communication has decreased by 70% with almost 90% backlog completion by the end of the milestone. My team has a clear vision of priorities, agency over the work they prefer to accomplish, and less anxiety and confusion over the features we will be capable of delivering by the deadline—very important for us and clients. We can still be flexible and predictable and use all of our teams’ resources wisely.

I want to emphasize that this approach only becomes effective when using automated tools that enable quick and effective planning and adjustments. Use Deep Planner to:

1. Quickly create a blueprint of a plan using backlog and team configuration
2. Adjust plans and re-plan items that were delayed or de-prioritized in seconds
3. Provide real-time visibility for roadmap and current team priorities for developers and stakeholders

I also highly recommend Git and Azure DevOps for continuous delivery.

Try it and share your experience!