“Our backlog is the pit of death; where top-level insights with ZERO empirical evidence rots, and the entire scrum team gives 0 f*cks”
“Let’s release 5 bug fixes and 3 new features each month and wish that growth shall bequeath us”
“Product management is like project management without the deadline, and I get flamed for everything that’s on fire”
“Agile is bullshit: gave more reason for management to randomly throw things into the mix”
“Those developers should stop turning things on and off” “Management are throwing out pointless jargons like broken records” Drawn from personal experiences
It wouldn’t be a surprise that you’ve experienced some or most of them. Both the development team and the business team are on constantly blaming each other for being a total doorknob, a roadblock on their unicorn growth trajectory.
Despite those dialogues being uncomfortably true, there are teams where everyone really wants to experience growth, but it seems like nothing is in place to enable them to do so.
Wouldn’t it be nice if there was a better way out?
After being named as the “tech team’s whisper” with multiple teams, I would like to share the framework that I use to deliver focus while being the bridge between business and development.
Reading prep
But before you read on, I’m assuming that you are already familiar with leading-lagging indicator analysis, OKR methodology, and Scrum methodology. If not, do not fear, here are some great reading materials and inspirations to help you catch up before you take a deeper dive.
Leading-lagging indicator
OKR methodology
- Felipe Castro — OKR vs KPI
- Rick Klau — How Google sets goals OKR
- Google reWork: Set goals with OKRs
- Great OKR examples and templates
- Free OKR tool for team < 4
Scrum methodology
- Takeshi Yoshida — a-pretty-good-summary-of-lean-agile-scrum
- Product Plan — Backlog grooming
- Scrum.org
- ThePerfectBA — How to write good user stories using [3 key] components
What is the problem?
With the pressure of solving a billion-dollar problem, with the budget of a Jollibee family deal budget, and everything in the company being on fire, most teams could only prioritize their time and effort in a knee-jerk reaction, based on how close it is to the deadline.
With the majority of the company behaving in such, the real important issues are being shunted away, and the effort was never justified. As a result, a list of unbearable nightmares that drives even the best people insane:
- Lack of sense of real meaningful progress and direction
- Disconnection between business goals and technical objectives
- Think of solutions before understanding the question
- 0 synergies between departments and functional groups
- PM tools are nothing but a messy dumpster fire
- Forced uncompleted release at the random schedule
- Lack of accountable high-level management decisions
You might think that sounds about right about most companies, but these symptoms might cause the following problems:
- Failed to attract/retain top-tier talents
- Deplete of team morale, hence low working efficiency and effectiveness
- Waste of time and effort
- Fail to experience growth
There must be a better way
If fact, there is.
Many smart people have been sharing insights and brilliant ways to help teams focus and deliver real growth. However, after articles and podcasts, it always felt like they are not that practical.
Turns out, OKR planning and scrum do go well together, and surprisingly they do share some similarities between the two frameworks.
Both frameworks do have a high expectation of the autonomy of the team to provide enough data points and information to be effective and rely on the team to come up with effective solutions. However, it does come with a few indispensable perks:
- Accountable responsibilities — actable items are no longer just dangling around the corners of the teams’ mouth
- Micromanagement-free — present the team with a problem/question instead of a solution, and let those who know their shit do what they are good at
- A clear sense of contribution towards progress — no more walking in the dark, every single task and feature is now traceable back to the company’s objective
- A clear focus for every team to contribute — no more knee-jerk planning and reaction to every small changes
- Highly transparent targets and focuses — different functional units are no longer working on their own without collaboration, no more hindsight grieving
And to benefit from the great perks mentioned, here is the step-by-step breakdown.
- Step 1. Lagging and leading indicators analysis
- Step 2. OKR planning
- Step 3. Sprint grooming / Release planning
- Step 4. Sprint planning
Most companies do not lack “high-level strategies” or any day-to-day operational optimization. From LinkedIn posts, and Medium articles, to Spotify podcasts, we are flooded with high-level strategies that companies treat like the magic growth spell that will fix everything.
The actual key that companies lack, is the “translation” between the strategies and the tactics.
“How do we do the right thing with the right question”
Step 1. Lagging and leading indicators analysis
Priority is the key to growth; because there isn’t enough time to do everything.
Trusting the power of one, focus, and make it count. Before getting the entire company all riled up in a “brainstorming meeting” hoping that some of the ideas will strike gold, the first thing is to understand the problem and be transparent about it.
To diagnose the problem with speed without sacrificing the accuracy of the finding, I discovered the lagging and leading indicator was the best starting point. The simplicity that it brings to structure the scope of the focus is quite favorable.
In layman’s term, the lagging and leading indicator is the reason-result relationship between different KPIs within the company in the form of a tree diagram.
Each company has its own key performance indicators structure, depending on the industries and size of the company. For example, “MRR and churn” for SaaS companies, and “inventory turnover” for an F&B company. Nevertheless, you can bet that almost every indicator depends on one another.
This analysis is quite similar to what E-commerce companies do, which is the conversion funnel analysis. The purpose of this exercise is to investigate where the bottleneck is, and what to focus on.
One of the challenges that I came across was to find “growth” within the company, along with fixing everything else that was on fire while at it. The first thing the team came up with was hiring a new UX designer in order to be able to develop better features that will potentially attract more users.
No doubt better features and nicer design will bring more users on board. However, practicality speaking, is better design really on the top of the list? Is it justifiable to introduce a full-time designer when there are better options to solve the same problem? Is there any other place in the business that requires more attention that the team is not aware of?
Under the common objective of increasing revenue for 2020, the team discovered that shopping cart conversion is the current growth bottleneck.
The investment into maintenance optimization won’t be enough to justify the ROI. However the market is rapidly expanding due to recent trends, and the better the business converts, the better can the team justify new features and development work.
Step 2. OKR planning
Now that we’ve really reduced the problem down to the focal point, knowing the “Why” and “what” , we yet to find out the “how”. “who” or “when”. But before we start brainstorming for ideas, the next step is to identify the “acceptance criteria” for the year-long project that we call improvement.
Since the only income under this company is the revenue that was generated from the App, we can safely say that 100% of the increase directly contributes and reflects to the company’s revenue growth.
After a simple whiff of my magical Asian Math power, our team agrees that a 100% increase in revenue is a good indicator of growth, and the board is more than happy to get behind this objective.
This is the time when brainstorms make the most sense. No more blockchain technology bs, no more “AI-machine learning” that’s just “if-else” statements under the hood.
With the help of OKR planning, the team broke down the “what” into “hows” that are relatable and traceable. After some competitor research and revisiting all the user interviews that were sitting in the team’s Google Drive, these suggestions make the most sense.
There are chances where 1 task contributes to multiple key results, such as the hypothesis that having social logins is one of the reasons why the conversion rate is low. The objective of the OKR task breakdown isn’t really to find out how to isolate contributions, but to bring focus to the problem on hand.
Step 3. Sprint grooming / Release planning
Now that the team has aligned its resources and focus, it’s time to understand what the to-do list looks like. This is where Epics, Stories, and Sprints come into the picture.
Epics act like tasks during OKR planning: being the pillars that determine the success or failure of the corresponding objective. Then the work should be broken down to contextually reasonable tasks for the team to execute. The less ambiguous it is, the more focused the team will be.
Once the epic (key tasks) and stories (check off list) are prepared in the product backlog, we are ready to plan for our releases.
This part is actually the only part where Product management and project management are similar, where releases are like the milestone of an endless project. A mark of achievement if you will. Different from endless iterations, the milestone has an expiry date.
The reason why release planning is important is to allow collaboration with different teams on a common goal. The development team can’t build products without letting their users know, we’re helping the marketing team to prepare the go-to-market and release strategy is crucial to growth as well.
Step 4. Sprint planning
At sprint planning, the progress of the suicide squad is closely monitored and prioritized. The objective of sprint planning is to keep the development velocity constant and enable the team to focus on deep work.
With the help of tools like Jira, each story is assigned to a member of the team along with story points, regardless of which Epic or which release it belongs to. Not only that takes away all the pressure of planning from the developers, but it also enables the team to gain momentum and freedom in managing their own work in terms of effectiveness.
Because development work is not always well-scoped and easy to explain: bugs and features can have dependencies as complicated and deeply woven as the royal family in the old days. It is only reasonable to anticipate enough resources and wiggle room for the development to be complete, depending on the urgency, pivoting and rescoping might also happen as well.
Last but not least
At last, I’d like to thank Ivo Wu, Pan Hang, and Lap Chow for sharing their wealth of experience at the beginning of my Scrum journey at Tink Labs and inspiring me to come up with this framework.
This article was featured on UX Collective on Dec 26, 2019
