The secret to manage capacity
Lot of PMs face the situation just before PI planning while looking at the roadmap as to how much should be the functional feature v/s tech debt / support work mix and how to maintain a balance between them.
Below is something which has worked for me for quiet sometime and would like to share here. Obviously, since PM is more of an art rather than a science, there is no right or wrong method, but this is just one of the methods. As Ankit Gulati and Sumit Kumar Singh once told me that a PM is one who is a painter one day and a plumber the next day, you work on the most beautiful painting and also should be one who can roll up their sleeves and get their hands dirty.
The 70–20–10 rule.
70% functional features
This is the capacity reserved for new features that may have resulted from market research, competitive analysis, marketing inputs or part of the strategic roadmap. These are the features that add heavy muscle to the product. Usually, new code is written, new integrations are done and new user experience is usually the end result. The team is always upbeat in picking this up.
20% tech debt
This is the capacity reserved for tech debts which could have been accommodated in due course. Like library upgrade, platform version migrations, performance testing outcomes, security vulnerability fixes, basically anything which would result in code refactoring of fine tuning the “under the hood” stuff.
10% intermittent work
This is the capacity reserved for any last minute, mid PI surprises for which we are not ready and do not have visibility while we begin the PI.
We can usually begin with these guardrails in mind while doing planning.
And then the reality kicks in.
- The functional capacity overruns into consuming 5–10% more because that is usually the P1 for the team and as a PM you would also like new features to be added and the users getting value. The reasons vary from the front end design turning out more complex because you need the dropdown to behave only in THAT certain way or the database table which you would have imagined to have catered to the request needs one more join using a foreign key and the new stored procedure is needed. All these add incremental efforts and can have impact.
- The tech debts are often completed with 10–15% efforts because there is scope of reuse and repetitive tasks that usually get done sooner than planned. However, there are some landmines which can derail the plan. The trick to evade them is to sit with the engineering team and let them talk through the entire process and shepherd them towards identifying potential reuse areas.
- The intermittent work is your friend here. More often that not, the intermittent work would qualify as tech debt unless it is a P2 issue and the team needs to push out a hotfix in next 48 hours.
This is what my experience has been, would love to hear what you feel about it and how do you manage these situations.
