DEV Community: Anton Kleshchev

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

Anton Kleshchev — Wed, 12 Nov 2025 17:46:34 +0000

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:

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.
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.
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:

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).
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.
Teams perform tasks based on their assignments and use a continuous delivery to commit their work. No more feature flags.
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. I called it a Milestone-based Planning Framework. I 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:

Quickly create a blueprint of a plan using backlog and team configuration
Adjust plans and re-plan items that were delayed or de-prioritized in seconds
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!

Make Agile more Flexible

Anton Kleshchev — Thu, 22 Aug 2024 19:01:00 +0000

Introduction

We all know that Agile is a methodology designed to make project planning and implementation dynamic and flexible. Today we're creating a schedule for one set of features and tomorrow after reviewing a demo we can change it according to our adjusted needs and purposes. This sounds really great, however this has a price: the planning we perform needs to be constantly changed and maintained according to the needs and priorities of all parties: team leads, managers, corporate leaders and stakeholders. Often such hierarchy of product owners makes planning stiff and highly resource consuming and leads to hesitation in making radical and frequent changes to the company roadmap. Therefore there is a space to make this process a bit more flexible by introducing a clear continuous algorithm for the planning process.

The Algorithm of a Continuous Planning Process

I call this algorithm an "Evolutionary Timeboxing".
This algorithm can be used any time at any point whether it's in the middle of the sprint or the beginning of the quarter, in general at any time.
Let's go over the main steps:

Define planning horizon you want to plan for. This is similar to military where you can perform strategic (year+), operational (quarterly) or tactical (iteration or N weeks time span) planning.
Decompose the business requirements of the project(s) into system components for all levels (where it's necessary). Define an estimate, nature of work for all activities. Define clear dependencies between system components and dependencies on the components of other projects.
Define a timebox which is the target of your planning. Add or adjust the system components as deliverables for that timebox. Account for level of effort and available teams.
Adjust or define all other timeboxes for the current and all other layers according to the new changes. Keep all layers synchronized. Notify the teams accordingly.

By following this algorithm it's possible to maintain a continuous and very flexible process of planning which is clear and transparent to both stakeholders who require high level vision (i.e. strategic level), project and product managers (operational level) and regular developers (tactical level). Currently I'm working on automating the reshuffling part which should make the process even more easier.
Let me know what you think about and your general thoughts of this practice!

Should Senior Software Engineers do Project Management?

Anton Kleshchev — Tue, 20 Aug 2024 19:33:39 +0000

Hello everyone, this is my first post here which I wanted to start with a discussion which was the point of curiosity for me for many years of my work in IT. Here is the question: should senior software engineers do project management?
Let me give you some context here. My career path like many others started with coding only. Later it progressed to other levels where coding was becoming less and less of the main responsibility and in the end I had very little of it or not at all. Instead one of the main tasks of a senior technical lead person is to decompose business requirements into functional system components and provide an estimate and team recommendations to implement it. And this is where things start to be really interesting.
Think about it. The primary goal of any Product Manager is not just to understand the cost of the project but also the timeline of when it's going to be implemented. I had this question coming all the time from PMs and stakeholders. To build this timeline you need to be really well aware of technical specifications of the project, its dependencies and nature of work to be completed. Usually Project Managers don't have such insights so they ask developers to help with that. So major part of my work was building draft schedules and working on project design not just from technical but also from execution side of things. I even created an app which can automate this and hopefully help simplify this process in future (if you're interested you can check it out here ).
What do you think of this question? Should responsibilities of Tech Lead/Architect include partially the responsibilities of a Project Manager?