Difficulty Scales – Story Points, 1–6 Rating, and Other Methods in the World of React Native

Once we’ve wrapped our heads around the psychological side of estimation and set up the right technical foundation, it’s time to move on to one of the key concepts in IT project estimation – the difficulty scale. This scale makes it much easier for developers, project managers, and clients to quickly gauge how complex a given task really is and get a rough idea of how long it might take. On top of that, difficulty scales let us track team velocity, which in turn helps make future estimates more accurate. In practice, there are plenty of abstract units used to measure task difficulty – and each team usually picks the one that works best for them.

Why, then, do we use abstract units instead of hours?

Estimating in hours creates the illusion that we know exactly how long a task will take. It’s a false sense of precision that ignores context, unexpected problems, or cross-platform differences. On top of that, every developer has a different pace — what takes one person 2 hours might take another 6. The real problem is that hourly estimates easily turn into promises to the business side. If we say something will take 3 to 5 hours, a client might expect results after just 2.5. That kind of mismatch quickly damages trust and strains the relationship between developers and stakeholders, since such estimates are often inaccurate. From a Project Manager’s perspective, hourly estimates also complicate sprint planning and roadmapping, because they fail to capture the relative difficulty of tasks.

Along the way, you might also come across the terms absolute and relative task complexity. Absolute complexity is simply a time-based estimate — “This will take 2 hours.” Relative complexity, on the other hand, uses abstract units (like Story Points), which lets us say, “This task is roughly twice as difficult as that one.” Research shows that teams reach consensus faster when comparing tasks relatively (“Is this more like a login, or more like implementing payments?”). As a result, the estimates become more stable and less affected by individual differences.

With that explained, let’s move on to the most commonly used difficulty scale.

1. Story Points

Story Points are one of the key elements of the SCRUM methodology. They are abstract units of measure used to estimate work, taking into account both the complexity and the effort required to complete a user story. Thanks to Story Points:

• We can compare the relative difficulty of tasks - for example, a 2 SP task is roughly twice as challenging as a 1 SP task.,
• We avoid estimating in hours, which allows us to focus on the relative comparison of tasks instead,
• The estimate covers not just time, but also technical complexity, risk, and uncertainty.

Another major advantage of using Story Points is the ability to measure team velocity, which makes sprint planning and forecasting delivered value much easier.

Fibonacci numbers are most commonly used to assign Story Points (1, 2, 3, 5, 8, 13…). This is because it’s easier for a team to decide whether a task deserves 8 SP or just 5 SP, rather than precisely comparing, say, 6 SP to 5 SP - a way to limit the illusion of precision. The increasing values in the Fibonacci sequence also reflect the fact that the larger a task is, the more uncertainty there is, making it harder to estimate its exact complexity. In small teams, using this approach also sparks useful discussions, such as: “Why did you assign 8 SP to this task? I think 3 SP would be enough.”

How do Story Points reflect uncertainty?

Small tasks, usually rated 1-3 SP, are relatively predictable, with low risk. Medium tasks, rated 5-8 SP, come with some unknowns - they might involve integrations, cross-platform differences, or require extra analysis. Large tasks, 13 SP and above, carry high uncertainty; they need deeper analysis and discussion, and sometimes must be broken down into smaller pieces to be estimated reliably.

2. Alternative Methods for Assessing Task Difficulty

2.1 Linear 1–6 Scale

In the beginning, teams often start with a linear scale to make it easier to get going, and later move on to Story Points and the Fibonacci sequence. In this method, the team uses simple values: 1, 2, 3, 4, 5, 6, where:

• 1 represents a very small and simple task,
• 6 represents a very large, difficult, and risky task.

The advantage of the linear scale is its low entry barrier for newcomers - it’s just easy to understand. Explaining it to a client is also straightforward: “6 is the hardest task, 1 is the easiest.” Additionally, for us - Poles - it feels natural because it resembles the school grading scale.

Unfortunately, the linear scale carries a strong illusion of precision and doesn’t highlight uncertainty for larger tasks as well. By contrast, the Fibonacci sequence shows a clear jump between a 3 SP task and a 13 SP task, naturally encouraging breaking down bigger tasks into smaller pieces. The linear scale also often leads to over-“mathematization” of estimates and disputes over details - developers find it easier to argue whether a task should be 5 SP or 8 SP than whether it should be 3 or 4 SP.

2.2 T-shirt sizes

Another easy-to-grasp scale is the t-shirt size scale: XS, S, M, L, XL (sometimes XXL). Each size corresponds to relative complexity and effort, without using numbers.

This scale is very intuitive, as everyone naturally understands the difference between an S and an XL, making it easy to introduce to both new and experienced teams. It avoids the illusion of precision because it doesn’t rely on numbers - but that’s also it’s biggest drawback. Without numbers, it’s harder to measure team velocity, and the sizes themselves are less precise for sprint planning.

It’s great for comparing and prioritizing tasks, but it’s harder to build a concrete sprint plan around it.

3. Story Points for React Native – Examples

1-2 SP: Simple changes

• changing text,
• changing text color,
• minor style tweaks (e.g., increasing paddingHorizontal on a screen),
• adding/replacing an icon on an existing button,
• swapping the endpoint in an existing API call.

3–5 SP: Standard features

• a new screen with a basic form and validation (e.g., your pet’s data)
• a screen with a list of available guests fetched from an API, including basic loading/error states
• adding local storage (AsyncStorage, MMKV) for basic data
• integrating with UI libraries
• creating simple navigation
• adding a splash screen

8–13 SP: Complex features

• multi-step or otherwise complex forms with validation and error handling
• offline-online data synchronization using TanStack Query + MMKV persistence
• integration with Google Maps, Stripe, Firebase, Push Notifications (device registration, token handling, click reactions)
• advanced navigation
• handling deep links
• complex animations requiring React Native Reanimated / React Native Gesture Handler

21+ SP: Huge tasks meant for decomposition

• an order system with cart, checkout, and payments
• migrating to a large new library (upgrade Apollo / React Navigation, etc.)
• full offline-first support with mutation queues and retry logic
• advanced QR/Barcode scanning system with API integration
• integrating multiple services at once (e.g., Google/Apple/Facebook login + backend)

4. 1–6 Scale for React Native – Examples

1: Simple UI/Text changes

• changing a button color
• changing text color
• replacing an icon
• fixing a typo
• adding margin in styles

2: Basic forms, simple components

• adding a simple login form with TextInput + Button
• login form validation
• creating a UserAvatar component with an image and username
• creating a simple static list using FlatList

3: API integration, navigation

• fetching data from an API using Axios/Fetch
• displaying a product list from the backend using FlatList with pagination
• setting up React Navigation and adding product details with parameters in navigation.navigate() to open the details screen

4: Complex logic, state management

• using TanStack Query/Apollo for caching and data synchronization
• offline-first handling with MMKV and NetInfo
• implementing optimistic updates
• nested forms with conditional validation
• integrating Redux/Zustand for global state
• custom hooks managing business logic

5: Native module integration, cross-platform problem-solving

• connecting SDKs for payments (e.g., Stripe, Adyen) that require native configuration
• creating custom native modules
• integrating push notifications using Firebase Cloud Messaging and APNs
• debugging differences between iOS and Android
• fixing platform-specific issues

6: Architectural changes, app performance improvements

• migrating to React Native New Architecture (Fabric + TurboModules)
• refactoring the entire state management
• implementing modular architecture
• list optimizations
• code splitting
• profiling and fixing memory leaks
• setting up CI/CD using Bitrise/EAS

5. Czynniki zwiększające złożoność

Besides the task scales themselves (1-6, Story Points), there are factors that can significantly increase implementation complexity. You can think of them as difficulty multipliers. Some of these factors were already hinted at in the examples for the different scales.

One of the biggest factors increasing complexity in mobile app development with React Native (though a similar phenomenon occurs in Flutter) are the differences between iOS and Android. Both platforms have their own way of handling permissions, significant differences in appearance and behavior, and often completely different APIs. What works “out of the box” on Android may require extra configuration on iOS or, worse, might not be possible at all.

Another significant factor that increases complexity is integration with external systems. Many developers have lost sleep over integrating payment SDKs or implementing login via OAuth/SSO. This category also includes integrations with hardware or backends that lack a stable and well-documented API.

When developing a mobile app, we need to keep scalability in mind. That’s why performance is another key factor that can increase complexity. Why? Because there’s no single universal method for optimization. What feels smooth to the user often requires, on our side, things like: optimizing lists, ensuring animations run at 60 FPS, managing memory (e.g., image caching, avoiding memory leaks), handling offline-first functionality with optimistic updates and data synchronization, as well as implementing lazy loading and code splitting for heavy screens.

But that’s not all. It’s 2025, the age of AI, where data leaks and fraud are happening more frequently. That’s why data security is another factor that increases complexity. It requires special attention when storing tokens, encrypting data, securing communications, handling sensitive information, and safely storing tokens in .env files.

All of this means that a task that might initially seem like a 3 SP job could actually require 21 SP. For example, implementing a login feature can involve at least three of the complexity-increasing factors mentioned earlier.

6. How Decomposition Affects Estimation – The Same Task Across Different Scales

To show how decomposition affects scales and Story Points, let me give you one example - the “Order List” - approached in two different ways.

Version 1 (without decomposition)

Description: Create an order list screen with API integration, handle pagination, allow changing order status, offline-first mode, and push notifications.

Based on the examples mentioned earlier in this article, we can estimate this task as: - Scale: 5-6 (we have API integration, offline logic, native modules) - Story Points: 13+ (high risk, many dependencies, one large module to deliver)

What are the problems with this task? It’s hard to estimate. The scope is very broad and touches on complex, time-consuming issues. Additionally, there’s a high risk of delays due to, for example, API blocking or Firebase issues.

Version 2 (after decomposition)

Let’s break the task into smaller subtasks.

Task 1 – Displaying the order list

Scale: 2 SP: 2

Result: clickable UI, progress is visible

Task 2 – API integration + pagination

Scale: 3 SP: 5

Result: access to real data and a working list

Task 3 – Changing order status (optimistic updates)

Scale: 4 SP: 5-8

Result: interactivity, order management, initial offline-first handling

Task 4 - Offline first mode (persist + sync)

Scale: 5 SP: 8

Result: The order list works without internet, remembers what the user had in the list.

Task 5 - Push notifications

Scale: 5 SP: 8

Result: Users receive updates about order changes

This example shows that decomposition lowers the rating of individual elements - instead of one large, high-risk task, we have several smaller tasks with lower risk. This makes sprint planning easier, allows developers to show progress faster (e.g., displaying the list fetched from the API), and reduces the risk of blockers, since the remaining tasks can be worked on in parallel, for example while waiting for the backend to be ready.

7. Summary

The goal of this article was to explain what difficulty scales are and how to use them, with real-world examples. The 1–6 scale, Story Points, and task decomposition are primarily tools for technically assessing tasks and planning team work. When communicating with business stakeholders or non-technical people, it’s not always necessary to dive into implementation details. What’s important is to emphasize that the scale used for estimation doesn’t translate directly into hours — time estimates are a separate matter. From a developer’s perspective, it doesn’t make sense to explain, for example: “This task is 8 SP because we need to use TanStack Query, implement offline-first, persistence, sync, and optimistic updates.” It’s better to say: “This task is large because it requires integration with multiple systems and must work smoothly even without internet, so we treat it as a bigger task that will take more than one sprint.” Task decomposition also improves communication - instead of one big “it will take two months” task, we can show progress in smaller milestones. All of this helps clearly convey to the business what they will get, when, and with what level of risk.