roadmap estimation

General

We use RICE for estimation.

Reach – how many users will be affected by the feature in a given time period. Impact – how feature improves user workflow: time saved, errors reduced. Confidence – how sure are we about Reach and Impact. Effort – how much work will this feature take.

Which features are to be estimated

We have different tickets:

• pure technical debt that is realy hard to cover under useful feature (uikit upgrade)
• bug fixes
• improvement requests of m and l sizes
• epics from roadmap
• design

1. Roadmap epics must be estimated using this approach. Issues within the epic are organized by milestones and are just done. "Nice to have" issues are not planned within the first epic and are supposed to be done as a version 2 of the initial epic. Version 2 has to be estimated separately.
2. We estimate bugs using RICE.
3. Technical debt is estimated using some "fake" numbers just not to bury such issues forever.
4. Improvement requests of m and l sizes are estimated using RICE. Might be linked to some epic milestone and implemented with the priority of this epic if applicable.
5. Design. Since we don't do design just for the sake of design - we always have feature requests to do design for, ux issues inherit RICE score from the parent feature
6. Issues of s size are just implemented in FIFO order using a rule that every developer has to have at least on s issue in a sprint

Reach

1. In genuine RICE this parameter is estimated in users / month. Users are categorized (cluster admin, db admin, app developers, on-call SRE) and are measured by category.
2. Estimate sounds like:
   1. "Faked save query results button was clicked by 100 unique users this month, so we guess reach = 100 app developers per month"
   2. "We see 200 cluster admin sessions daily, we guess this health check will be seen by all of them, so reach is 200 users per day"
3. I propose we consider every feature with medium reach by default and use reach:high label for features that are used in the most of user sessions. We use reach:low label for features that are going to be used by less than 5 users a week.
4. Start with one label - reach:low.

Impact

1. Might be measured as how feature will change affected users experience. Not by quantity but by quality. This "wow!" xeno often speaks about or evict button that helps oncall people to avoid cli usage.
2. Let's measure it as high, low or medium:
   1. High – will change the life, users who use this will like to tweet about it. Changes the way people were working. Like disk eviction or top queries from different tables.
      1. Increases uptime, prevents outages or dataloss
   2. Medium – people will like it like query settings dialog
      1. Saves admin hours, automates mundane tasks
      2. e.g. Manage column width
   3. Low – almost nothing will change, people who use it won't see - e.g. immediate column choice application
3. Technically using labels on issues is proposed. We can new impact:*.
4. On calculation step labels could be converted into numbers: impact:high - 3, impact:medium - 1.375, impact:low - .5
5. If Question: Is impact used to prioritize features that will help getting money?

Confidence

We can use sure, high, medium and low labels with the following meaning:

1. Sure means that we have estimated impact and reach by doing an experiment (reach is taken from metrika, impact is from sketch feature deploy, clickable prototype and we know users who were asking for this)
2. High means we have user requests (more than one) and we did a quick survey that was used to back reach and impact estimation. And we have metrika data
3. Medium - we have feature requests (more than one real user with a clear use-case, not just a message in chat or one-sentence issue). And we know competitors have similar things.
4. Low – we have no requests with verified use-cases (or request from one local team or request from one user internally no matter how persistent they are), we have no metrika data it's just our gut feeling. Or we were enforced to do it without respect.

Technically labels are proposed: rice:conf:high etc. On calculation step they are converted to 100,75,50,25 numbers.

We start calculation with one confidence - medium which is set by default.

Effort

Since this approach is going to affect epics we reuse size labels and compare epics with epics.

1. size/xl – requires backend development in more than one team (query processor and viewer back for instance). Requires a PoC for 1-2 sprints before committment and goal clarification. Requires design development. Involves completely new UI section creation that never existed. Or a huge redesign. A lot of uncertainty. Might take up to 12 sprints (half a q).
   1. Examples: AI assistant. Enterprise Manager.
2. size/l – backend development is needed in more than one team, coordination of teams is required. Design is needed, involves new UI forms. UX tests are required.
   1. Examples: Save queries as CSV, Long running operations, Database view redesign
3. default value is size/m – backend development is needed in one team, design is needed, UI development requires research. UI development Is not trivial, can't be done in one sprint
4. size/s – backend is ready or requires trivial change that doesn't involve "merging into stable" procedures and doesn't require new components, no migrations, no performance-critical paths are altered. Design can be done in a sprint or faster. UI development affects one existing form or was done many times before (add new scheme object type).

On calculation step labels are converted into number of days required: 1. size/xl: 1. 2 backend developers by 30 days = 60 2. 1 designed by 60 days = 30 3. 2 UI developers by 60 days = 120 4. 60 + 30 + 120 = 210 5. Let's add 50% for high risk tasks 2. size/l: 1. 1 backend developer by 30 days = 30 2. 1 UI developer by 60 days = 60 3. 1 designer for 30 days = 30 4. 30 + 60 + 30 = 120 3. size/m 1. backend developer by 30 days 2. UI developer for 30 days 3. Designer for 15 days 4. 30 + 30 + 15 = 75 4. size/s 1. backend developer for 15 days 2. UI developer for 15 days 3. Designer for 5 days 4. 15 + 15 + 5 = 35 5. size/xl – 15 days 6. size/l – 10 days 7. size/m - 5 days

RICE score

RICE score is calculated for each feature and then features are sorted in descending order by the score. Top features are supposed to bring the most value for the cheapest effort.

RICE Score Calculation

$$\text{RICE} = \frac{\text{Reach} \times \text{Impact} \times \text{Confidence}}{\text{Effort}}$$

Feedback label

Is needed to be considered

Roadmap label

Is needed to be considered