Transitioning to Story Points based estimation and planning from time based

About the past

I personally think and saw that many development companies use time based estimations when it comes to custom development and own product development. Classic question is, when can you deliver this? how how much time will this very-very small feature take to deliver? Omg, how many times did I experience this…? Now whats the problem here? Well… barely did the team deliver its promises and that tells a lot , of course. What is the core issue? Time-based estimates rely too much on individual perception, optimism, and unaccounted complexities and uncertainties. So, we decided to make a change: we transitioned to Story Points. That was the professional and next educated next step.

Why move to Story Points?

With Story Points we can measure the effort. Which is a relative estimation approach that focuses on complexity, the shear volume of the task and one more attribute which is overlooked too many times: uncertainty. Yes, for sure, you can expect smooth sailing and all that, but reality will hit harder than an NFL quarterback. Our question estimating an task became this: “How effort is this compared to our reference tasks?”. This allows us to:

• Reduce estimation bias caused by individual differences in speed and experience.
• Improve predictability by tracking velocity and planning based on historical data.
• Encourage collaborative estimation through Planning Poker and group discussions.

Planning poker is fun, we laughed a lot. Of course at first, its gonna take too much time, but its worth to put your company on track. You need to adapt this approach to your entire workflow.

Adapting to Story Points

Switching to Story Points wasn’t just a matter of changing how we estimate—it required adjustments across our entire planning process and workflows. Here’s what we did:

1. Adjusting our Notion.so setup

We use Notion.so for tracking and managing our projects (custom development and own product development too). Moving to Story Points meant updating our task templates, sprint boards, meeting templates and start setting the baseline for the relative estimations (how does an average 3 Story Points worth of task look like?).

2. Introducing Planning Poker

To improve estimation accuracy and team alignment, we adopted Planning Poker (what you can also incorporate into a task page template), where team members vote on Story Points for each task. First we discuss the task, the owner elaborates on what is the description and what the definition of done attributes are. Other members of the meeting can also ask questions and it turns into a discussion, that enriches the task’s understanding. And this is the time, when we take into consideration these 3 main things: complexity, volume and uncertainty. This practice helps identify differences in perception early, ensuring a shared understanding before and code writing starts.

3. More time spent on planning

We don’t want to overkill time spent on meetings, but it is the way, and still less in overall time consumption. Story Points forced us to spend more time refining tasks before estimation.

• More frequent backlog refinement meetings.
• Clearly defining the Definition of Done for every task.
• Ensuring better documentation and shared understanding.
• Cross sharing views on a task, which is like having a producer making your record. (you need external ears)

4. Standardizing our Story Points scale

To ensure consistency, we established a reference framework for our Story Points, where each have a task attached to a number, that tells us what that Story Point is like. You need to time to have a good average for that.

How Long Did the Transition Take?

Well this transition did not happen overnight, it took around 2-3 months (5-6 sprints). This time incorporates the entire Notion.so setup shift, all the project management adjustment, task templates, sprint management and its automations. You will also be able to check out our entire development company Notion template. We will put the template in Notion marketplace, so you can also check it and use it.

The Outcome so far

We’re still refining our process, but the early results are very promising and does not cost us big pains. It takes more time, but overall planning time adjustment is well under the time being lost on additional development hours, uncertainty hits and such. So we highly recommend this to all the development companies, it not only makes the estimation closer to reality, but also brings the people more together and you cannot put a price tag on that.

Next Steps: Optimizing our workflow even further

Now that we have Story Points in place, we are focusing on improving our velocity tracking and forecasting. We are able to measure how many Story points can we deliver in a sprint, we can also see, what the average is for the company. These are the next steps we want to take.

• Tracking our actual velocity over several sprints to improve our future estimates.
• Refining our Story Point reference tasks based on real-world development experiences.
• Integrating automation in Notion.so to streamline estimation and sprint planning.

Transitioning to Story Points was a significant shift, but it’s helping us build a more predictable and structured development process and also a better working team binding. If your team is struggling with inaccurate time-based estimates, this change might be worth considering!