Before the start of each quarter or year, companies do much the same thing: executives and product owners gather, draw colorful roadmaps and approve a strategy for the months ahead. Usually such a “perfect plan” looks very slender:
- superproducts or superfieatures (for which bonuses are given);
- improvements (let’s make pleasant things to business and users);
- architectural tasks (so that existing system does not fall apart, + import substitution);
- technical debt (last year not everything was fixed, the same expected for this year).
Tasks formulated in large blocks are evaluated and placed on the release calendar. The plan includes a time reserve of 10-15% for defects and unforeseen expenses.
The plans have been approved, the budgets for them have been laid down. Time passes and the plan is affected by:
- Regulatory tasks. They are always “nailed.” They cannot be moved, otherwise – fines or work stoppage.
- “Long promised.” Business reminds that the feature was promised “last year.”
- Problems with integrations. Subcontractors do not have time, they have to make temporary decisions – “crutches” that strengthen technical debt.
- New introductory from business. The market has changed, priorities have changed – “we must urgently do.”
- Critical sales defects. The team goes into fire mode.
The plan is bursting at the seams, the deadlines are on fire, the team is in the emergency mode. This is due to two problems of strategic planning:
- We cannot predict everything for the year ahead.
- We cannot lay too high a percentage of risk costs – a business needs a result, and that is why it is ready to pay development teams.
How to rectify the situation? The necessary tools are in the arsenal of system analysts – this is decomposition and prioritization. Their skillful use helps to return controllability.
Planning sets the vector of movement and the key “what and when we want to do,” the analyst answers the question “how do we do this without going crazy when everything goes wrong.”
What is decomposition
Decomposition is the process of sequentially splitting a complex, multi-part problem into smaller, atomic and understandable units of work that can be sprinted, evaluated, implemented in a limited time and immediately demonstrate the result. To use a metaphor, this is the art of “slicing an elephant.” Why is it needed?
First, to eliminate uncertainty. Any task at the start of the project is presented as a “black box.” Until we look inside and understand what it consists of, we cannot give a realistic estimate of the timing. Decomposition opens this box, showing all the pitfalls, hidden dependencies and technical difficulties.
Secondly, to create predictability. A plan consisting of dozens of small tasks is much more accurate than a plan of two or three large ones. You can track progress in stages: “task A is ready, task B is at work, task C is still in the backlog.” This provides transparency for management and business.
Thirdly, for flexibility and maneuverability. When an urgent task appears in the middle of the sprint (the same “regulator”), the team working with monolithic features faces a choice: throw everything and disrupt the delivery time or ignore the urgent request. A team practicing decomposition can easily replace one small task with another, keeping the overall rhythm of deliveries.
Finally, decomposition helps in the distribution of work. The smaller and more independent the tasks, the easier it is to distribute them among different team members, accelerating overall development.
A plenty of decomposition methods has been invented and described, and the choice of a specific tool depends on what stage of planning we are at and what size “pieces” we need.
At the stage of strategic (annual) planning, when we are dealing with vague wishes from the business “do us well,” methods come to the fore that help to see the overall picture and assess the realism of the deadlines at an upper level. User Story Mapping is indispensable here, allowing to build a user path and determine MVP, and Impact Mapping, which connects functionality with business goals. These methods help create a hierarchy of what is to be done without delving into technical details.
When we go down to the level of quarterly or release planning, the tasks become more specific, and structural methods are used. Functional or object decomposition (especially in conjunction with DDD) allows to split large features into modules and services, determine their boundaries and interactions. At this stage, it is important to lay the foundation for the architecture and understand which components will be developed in parallel.
Finally, at the sprint planning level, when we work with specific user stories, we need maximum detail. It uses Use Cases to develop use cases, BDD scripts to formalize requirements through examples, and, of course, decomposition of exceptional scenarios, allowing not to forget about error handling, drop protection and data consistency. This is usually 80% of the code that is not visible to the user, but is critical to system reliability. If you do not plan them in advance, they will still appear, but already in fire mode.
What is prioritization
Prioritization is the process of determining the relative importance of tasks for choosing the order in which to perform them in resource-constrained environments.
If decomposition answers the question “what does the task consist of,” then prioritization answers the question “what to do right now and what never.” This is a natural continuation of the work: having cut the “elephant” into manageable pieces, you need to understand in what order to submit them so that the team does not choke, and the business does not starve to death in anticipation of the promised releases.
As with decomposition, prioritization methods evolve with the planning horizon. At the strategic level (year, quarter), high-quality frameworks like MoSCoW work, which help to separate grains from chaff: what must be included in the release (Must have), what is important, but will wait (Should), what would be nice (Could), and what we deliberately cut (Won’t have).
RICE (Reach, Impact, Confidence, Effort) is also useful here; it allows to weigh mathematically the value of features against labor costs, especially when you need to compare heterogeneous tasks – for example, “new payment integration” and “refactoring the old module.”
At the tactical level (upcoming sprints), more operational methods come into play, closely related to task flow control. Weighted Shortest Job First (WSJF) from the SAFe methodology works here, helping choose tasks that provide maximum value in the minimum time, which is critical in conditions of burning deadlines.
Prioritization becomes the art of compromises: “The regulator flew in – what are we throwing out of the plan in order to preserve the resource?” Here we return to decomposition again: only finely chopped tasks give room for maneuver, allowing to replace “buns” from the Could category with urgent Must without destroying the product frame. Thus, prioritization is a constant process that balances between business expectations and the real capabilities of the team.
When to do all this?
The deadlines are on fire, the team, on each daily, sadly replies “we don’t have time, but you are planning.” In these situations, the most effective thing is to stop, think over a plan, and outline steps.
Agile practitioners generally came up with a special ceremony – PBR (Product Backlog Refinement) – time for the continuous process of “combing” the backlog, which is often underestimated. Within the framework of regular (usually weekly) sessions, the team jointly goes through the backlog tasks, clarifies the details, reassesses them taking into account new information and, most importantly, checks whether the tasks are decomposed well enough to be taken into the next sprint. PBR allows to identify pitfalls even before the task has gone into development, reducing the risk of surprises in the middle of the sprint.
Who should do all this? The product owner knows “what the business needs,” but often does not understand the technical complexity of implementation. Technical leader knows “how to do it,” but often only at the top level, his task is to monitor the architecture, there is no time for little things. The manager monitors resources and deadlines, but does not delve into the essence of the requirements. A system analyst only owns a holistic picture: on the one hand, he is aware of the needs of the business, on the other, he understands the architecture and limitations of the system, sees hidden dependencies, keeps in mind user scenarios with all their exceptions. It is the analyst who is able to “cut” the feature so that it retains business value, but at the same time is technically feasible in a tight time frame.
So, the main thing to remember:
- It is impossible to plan perfectly. Reality will always make adjustments in the form of regulation, problems of adjacents and sudden wishlist.
- Decomposition helps maneuver. The finer the tasks are cut, the easier it is to rearrange them in places without breaking the release.
- Prioritization helps not to hide our heads in the sand, but to choose consciously what we do or do not do in this sprint.
- Regular PBR is profitable. It is better to spend a day “combing” a backlog than a month extinguishing fires.
Mastering different decomposition methods allows the analyst to be flexible and work with the team to apply the right tool at every stage of the task life cycle, ensuring that the plan is not only smart, but also realistic.
By Tatyana Dolgina, Lead Systems Analyst IT_ONE