How Professional (React) Developer Teams Plan & Estimate Features

Johannes KettmannPublished on 

To plan their features professional teams use processes with multiple roles involved. They ideate, design, plan, estimate, and prioritize features before they start the implementation. They split large features into small chunks that can be tackled by multiple devs in parallel.

Sounds reasonable. But without job experience, you probably don’t have a clue what that looks like in real life. The goal of this article is to expose you to a typical feature planning process. One that you’ll likely encounter on your first job.

  • First, we’ll cover a bit of theory about a typical product team and the planning process.
  • Later we’ll apply the learnings to two examples. At least the parts that you’ll likely be involved in as a Junior developer.

The examples are based on user stories and designs. This way you can see the process applied in a realistic scenario and practice it yourself.

My advice is to read at least the theory part on this page before watching the video below. The explanations here are admittedly better than in the video.

If you want to get hands-on practice in a professional environment sign up for the upcoming React Job Simulator.

Note: The descriptions here are based on my experience working with a handful of teams. The exact process and responsibilities differ from team to team. But the overall picture should be similar in many companies.

A Typical Product Team

Before we dive into the planning process we should understand what a typical product team looks like. What kind of roles are involved? What are their responsibilities?

These are the people that a frontend developer works with on a daily basis:

Note: this is written from the perspective of a developer. Some things are simplified and technically not accurate (e.g. Product Manager and Product Owner may not be the same role). There might also be other roles involved like QA engineers. Still this should paint a similar picture to what a new developer encounters in their first job.

The Product Manager (or Product Owner in Scrum terminology): there’s typically one PM for a team of developers. They basically ensure that the devs have something to work on (apart from refactoring the codebase).

  • They gather feature requests and requirements.
  • They write tasks in the form of user stories (more on that later).
  • They prioritize features and tasks together with upper management.

In essence, Product Managers are the bridge between the outer world (e.g. upper management or other departments) and the developers.

The Designer: there’s typically one designer for a team of developers. Often they even work with multiple teams. Their responsibilities are creating UI designs (obviously) but they might also be involved in user research (e.g. as UX designers).

The Developers: for every Product Manager or Designer there are typically multiple developers. In most cases, the development is the bottleneck of building a product. Their responsibility is to implement new features, fix bugs, maintain and improve the system, but also to participate in plannings and estimations of upcoming features.

Which leads us to the next chapter.

The Feature Planning Process

Here is a bit of background information about how a feature makes its way from ideation to being deployed to production. This is a bit theoretical but we’ll see two hands-on examples later on.

Feature Requests, Stories & Designs

The whole process starts with a request for a new feature. This request might come from within the team, the business people, another department (like the marketing department), or the company’s users.

The Product Manager gathers the requirements for the feature, works with the designer to create the UI, and writes user stories. Often one or more developers are also involved in this process to understand technical feasibility early on.

A User Story is a type of task that describes (part of a) feature from the perspective of a user. It doesn’t contain much technical information but explains the purpose of the ticket. Multiple stories might be grouped together as an Epic which describes the complete feature.

A common template for a user story is this: “As a ... I want ... so that ...”

An example: “As a user I want to use a navigation bar so that I can easily visit all the important parts of the application”.


Once the Product Manager decides that the feature and user stories are in a presentable state they discuss them with the developers in a so-called backlog refinement or backlog grooming.

This is a meeting where the whole team meets and everyone has a chance to ask questions and raise concerns about potential implementation issues. For example, a part of the feature might look simple but could be very complicated to implement. Often the PM and designer aren’t aware of that. The team can discuss the issue and either find a simpler solution or split the story into smaller chunks.

Once all questions are cleared it’s time to estimate the effort.


Management needs to make projections. When will a feature be ready? When should our customers expect it? What does our roadmap look like? Usually, estimations are used to make these projections. And the easiest and most obvious way to estimate is to ask a developer: “How long does it take to build this?”

Nothing a developer hates more...

Experience shows, that this leads to vastly underestimated timelines. So smart people tried to decouple estimates from time by assigning complexity points to stories. Developers basically say: “This task sounds complicated. I give it an 8.” or “This is simple. It’s a 1”.

These numbers are called Storypoints.

They don’t have any inherent meaning but over time the team usually aligns on what each number represents.

The idea is that you can observe how many points a team can accomplish in a certain timeframe (often a 2-week Sprint). This is called velocity. And the average velocity over a couple of Sprints can then be used by management to get a time estimate for a feature.

Many teams use numbers from the Fibonacci series (1, 2, 3, 5, 8, 13, 21...). The theory is that the more complex a task the more inaccurate its estimate. The increasing gaps between the Storypoints represent this inaccuracy.

Now, this sounds all great in theory. But the numeric nature of Storypoints often leads to misuse. Typical signs are:

  • The Storypoint estimate is transformed into a time estimate. Example: “This story has 1 point so it should take half a day.”
  • Storypoint estimates are turned against the dev team: “You gave this feature 60 points in total so you have a deadline of 4 weeks” or “This team needs to increase its velocity.” or worse “Team A is much more performant than Team B because of its higher velocity.”

Most importantly though, research shows that you can simply count the number of stories instead of the Storypoints and basically get the same estimate. So the whole estimation effort might be a waste of time.

Nevertheless, most teams make use of Storypoint estimations. So if you want to start a career as a developer you’re likely to encounter them sooner rather than later.

Technical Planning

This meeting is optional. It might also take place before the estimations.

Once the user stories are estimated the developers gather again to discuss the technical details. Remember, a user story is written from the user’s perspective and typically doesn’t contain a lot of technical information.

Much of the technical discussion should already have happened before the estimation. So if required the devs simply break each user story into multiple technical tasks that make sense from their perspective. These could include things like adding a column to a Database table, updating the API, or adding a component to the UI library.

Implementation, QA & Deployment

At this point, the user stories are ready for development. The developers pick them up one by one and implement them. Somebody tests the implementation. Ideally, the feature is covered with automated tests to prevent future regressions. And finally, the feature is deployed to production so the users can benefit from it.

We won’t go into details here since this article focuses on the planning process.

The Board

All the tasks are visualized on a board. Below is an example of a Kanban-style board with multiple columns. The user stories start at the very left in the backlog. Once they are refined and estimated they can be moved to the Todo column. Now developers can pick a task and move it to the next columns depending on its implementation status.

You don't feel "job-ready" yet?
Working on a full-scale production React app is so different from personal projects. Especially without professional experience.
Believe me! I've been there. That's why I created a program that exposes you to
  • a production-grade code base
  • realistic tasks & workflows
  • high-end tooling setup
  • professional designs.

Example 1: Planning a simple Sidebar Navigation

All this theory can be a bit boring and hard to understand. So let’s continue with two hands-on examples. We’ll start with a simple component.

User Story

The first user story of the upcoming React Job Simulator is the sidebar navigation. Here is a screenshot of the ticket from the board above:

You can see the actual User Story, the design, and a list of Acceptance Criteria (also AC). The exact ticket format varies from team to team. The AC don’t include many technical details but describe the functionality from the perspective of a user. Here they basically describe the behavior of the design in words.


During the refinement session, the team goes through the User Story, the design, and the proposed Acceptance Criteria.

Please have a look yourself. Are there inconsistencies in the design? Anything unclear from the ticket description? Anything wrong or missing from the AC? Anything you’d like to change?

Here is what I found


The user story is pretty clear so we move on to estimate the user story. As a reminder, every developer picks a number of the Fibonacci series (1, 2, 3, 5, 8, 13, 21) where 1 is a very simple task. Let’s say changing a text or color could be a 1.

Here is a chance for you to practice: Think of a number that represents the complexity of this user story before you read on. No worries, there’s no right or wrong at this point.

My estimate and explanation

Technical Planning

From my perspective, we don’t need to split this user story into multiple technical tasks. We might create a task each for desktop and mobile design due to the different behavior. But I’d leave it as a single user story.

Example 2: Planning a complex interactive page

The sidebar navigation was pretty straightforward. Now let’s have a look at a more complex user story from my upcoming React Job Simulator. Here is a screenshot of the issues page design:

Alright, there are a lot more complex components and interactive elements in this design. A look at the board shows that the Product Manager created two user stories:

Let’s take the “Issue List” as an example here.

User Story

Here is a screenshot of the user story:


Again, please have a look yourself. Are there inconsistencies in the design? Anything unclear from the ticket description? Anything wrong or missing from the AC? Anything you’d like to change?

Here is what I found


It’s time for the estimation. Pick a Storypoint (1, 2, 3, 5, 8, 13, or 21) where 1 is a simple task like changing a text or color.

Here is mine

Technical Planning

This user story is obviously a bit more complex. I’d say it makes sense to split it into multiple tasks for the developers. There are some advantages to having multiple smaller tasks:

  1. The Pull Requests don’t become that big and thus are easier to review.
  2. Multiple developers can start implementing the feature in parallel (if the tasks don’t depend on each other too much).

So let’s start breaking the user story up. As a reminder here are the design and the acceptance criteria from the story:

Think about the different tasks that you would create. How can you split the story into small self-contained tasks? How can you allow multiple devs to work in parallel?

Here are the tasks that I created
You don't feel "job-ready" yet?
Working on a full-scale production React app is so different from personal projects. Especially without professional experience.
Believe me! I've been there. That's why I created a program that exposes you to
  • a production-grade code base
  • realistic tasks & workflows
  • high-end tooling setup
  • professional designs.