Using an Agile Scrum approach to hit your business goals and scale up the company.

Written by: Alex Korolkov, Head of Delivery in Product Engineering

Abstract

• Doing the right things at the right time
• Doing wrong things within the window of opportunity
• Doing the right things at the wrong time

Making mistakes is crucial to learning and development. Without stumbling, you will continue to hit a glass ceiling in your professional growth. This framework which I will explain is aimed at reducing bad impact, allowing faster failures, and increasing the chances of doing the right things at the right time.

The problem

To do the right thing at the right time, you need a formal definition of “right” for both.

But first, we need to admit, accept, approve, and personally commit to these three statements:

1. A product backlog is always infinite and unknown.
2. A technical backlog is always infinite and known.
3. The quality of the code for a growing startup is always bad, and tech debt requires refactoring for every single service.
4. (Most importantly) All three statements will not change until the company grows to a certain point.

You may think of this hypothesis: if your code is good, refactoring is not required, the product backlog is known, and tech backlog is empty. However, are you still growing as an employee, as a department, and as a Company?

What will be the right thing to do? Depends on targets we want to hit. If you’re hungry, you need to eat ASAP. Otherwise, you will not be able to do anything very soon. What are you hungry for as a company?

Each B2C product company has almost the same set of vital KPIs (Key Performance Indicator), like DAU (Daily Active Users), LTV (Long Term Value), NPS (Net Promoter Score), churn (rate of customer attrition). From year to year, values might change depending on a Company’s strategy and external factors.

To get somewhere, first, you need to figure out where you are.

To set KPI targets, you need to get a baseline for each KPI you want to move. It may take up to one month to acquire a real-time data flow for measuring your KPIs, but this step is necessary. It would be best if you got the latest value for any KPI in real-time, at any time.

Once you have a baseline and an automated system that provides real-time KPI values for you, you may start planning your annual targets for a Company.

Things do get easier.

Each department will contribute to some of the Company’s KPIs and will have it’s own KPIs to improve the department’s performance and efficiency. Each department head will commit to moving the Company and Department KPIs with exact numbers set out for the year. Ownership of the KPI could be shared, but each split should be defined in advance to avoid collectivism and increase ownership.

Now, at a top-level, it’s clear what is the right thing to do. Set specific KPI owners and hit those numbers. But when is it the right time?

To tackle big numbers, you got to chew them one quarter at a time. Set aspirational quarterly targets for the first three quarters, leaving the last quarter as a buffer. For example: over the next 12 months we want to move KPI by 6 which now has a baseline of 3, i.e. from 3 to 9 — let’s put a target for quarter1 as 5, quarter2 as 7, and quarter3 as 9. We will keep quarter 4 as a buffer to help those annual KPI targets that were not achieved by quarter3.

Now we know the right time and the right thing to do. But still, 3 months is too tough to plan in a fast-paced business environment, especially if your product-engineering team is in the hundreds. Even if we spend lots of time planning, expect the plan to change and to reiterate your existing plans. Move forward incrementally and fail fast to make space for time to learn and fix the plan. So set 4 weeks as one increment, and prepare the next increment’s plan during the current increment.

Within each quarter, set 3 increments- one per month. In the first month, plan to hit 40% of your quarterly KPI, 40% in the second one, and 20% in the third one. Do set aside time as well for planning each next increment. You KPI tracker will look like:

KPI Planning with Baseline Example

The key thing is not to plan for Month 4, Month 5, etc. you should do it only when you have KPI values for Month 3, which is Q1 results.

What do we have now? From Company strategic goals and annual targets, we just aim to deliver the product backlog item which will move specific KPI to a pretty defined extent that is committed to by a specific owner for the next 4 weeks.

Piece of cake, right?

To move KPIs, we need to alter the product with technical and product items. But software development is an expensive activity to do, especially when backlogs are infinite.

Before sending a bunch of items to development, we need to use data to prove that each item has an actual impact on the KPI. So right after ideation, it would be good to run an experiment to prove that an item is capable of moving specific KPI in the right way. For Large to X-Large development items, it would be good to create a Minimum Viable Product (MVP) in case KPI assumptions were wrong. But both the Experiment and MVP should be considered as backlog items along with the full version of the item.

To be able to prioritise items in the joint product+tech backlog, engineers should roughly estimate each item’s size. It’s good to give relative TShirt sizes like S, M, L, XL, and Unknown size. The same approach may be used to quantify the impact, and we will have a 2x2 matrix that could be sorted into:

(Source: Edrawsoft)

We should split the backlog items into four equal amounts according to the 2x2 categories. To optimise efforts, pick “Low Effort — High Impact” items only. By the way, you may do this exercise recursively to narrow down the selection of items within the single category. For example: let’s imagine we have 1000 items in the joint backlog, we will pick 250, which are “Low Effort — High Impact”, and then we go again, split in four, and pick 62 “Low Effort — High Impact” items, and at the third round, we will have 15, which makes sense to pick into Increment backlog.

Each increment could be a Scrum Sprint itself, but we like to use two-week sprints. So each increment will have two classic Scrum Sprints.

(Source: Amazing Outcomes)

I will not cover classic Scrum processes here, but it would be good to remind Scrum Masters to backtrace a correlation between TShirt Sizing and accurate estimation in Story Points with a Scrum team during each retrospective for each delivered item.

Course correction

For every increment, sprint, week, and day do check your targets against your actual values for each KPI. Here come the RAG (Red, Amber, Green) indicators for each KPI. The rule is simple — if KPI is falling out of your control and you need help it’s Red if KPI is behind the target, but it’s manageable — Amber, if KPI is going according to the plan — it’s Green. If your indicators are mostly Green, you should reconsider your goal because your targets are not aspirational enough.

The whole idea of RAGs for KPIs — each colour is an indicator to act, and there is no colour indicating that you can sit back and relax.

Targets should be and will be revised, altered and replanned each quarter. This is the only way to keep things moving forward. But if you manage with numbers-driven delivery, you will have enough time to hit your annual goals and be agile at the same time.

Thank you for reading, and good luck!

About the author: Alex is the Head of Delivery at Circles.Life. He drives the product delivery from end to end is passionate about number driven performance, managing new country launches, as well as feature delivery for existing countries. He is leads the project management team and ensures that things happen on time with top product quality.