To estimate or not estimate, that’s the question

To estimate a project could be the most difficult task we may do as a developer. Think about it: Someone is asking you how long it would take to do something you don’t really know what it is.

‘You have to make a simple landing page.’
‘Yes, but how long is it (content)? Does it have a standard layout or a blowing mind one?
Does it have animations, parallax, videos? Is it responsive? How many breakpoints? Does it connect to any API or is it static info? Do I need to know any technology or just plain HTML?’

All these variables are only for a simple landing page, imagine when you need to make a full site, tool, a SPA, CMS or something bigger.
However, estimations are very important for business. Any stakeholder would invest in something he doesn’t know how long it will take to build it. So, talking about the unknown, we -developers- are the one closer to figure it out how long it will be ready on.

How can we do it?

If you think on estimate for a client, you need dates.

‘When will my landing page be online?’ ‘When could we launch the product on production?’

Besides, we need a date to plan a marketing campaign, ads, press releases, communication, etc.

So, close your eyes, take a deep breath and imagine when it will be ready…

Seriously, there are some methods or ideas already tested that are useful as inspiration. When you are making a project, the dates are fully needed. We started in July, we must finish in November. Your landing will be online by December.
So, traditional software teams give estimates in a time format: days, weeks, months. When agile methodology was implemented and projects become products, many agile teams have transitioned to story points.

Story points

Story points are unit of measure for expressing and estimating of the overall effort required to fully implement a story.

Why:

• Dates don’t account for the non-project related work that inevitably creeps into our days: emails, meetings, and interviews that a team member may be involved in.
• Dates have an emotional attachment to them. Relative estimation removes the emotional attachment.
• Each team will estimate work on a slightly different scale, which means their velocity (measured in points) will naturally be different. This, in turn, makes it impossible to play politics using velocity as a weapon.
• Once you agree on the relative effort of each story point value, you can assign points quickly without much debate. 
• Story points reward team members for solving problems based on difficulty, not time spent. This keeps team members focused on shipping value, not spending time. 

But this is useful because you are working on a product not a project. I understand product and project are quite different. A project starts and ends while a product is alive, it doesn’t have end time so you never know how it would change or what would end up being. For example, Facebook is more than 18 years old. When it started it was very different as it is today. It has lost many features on its way while others have survived. I almost sure that Mark Zuckerberg didn’t know what he wanted 18 years ago. He started something small, a product he could manage and this monster grew to become what it is now.

I think agile methodology and story points were very useful for developing new features transforming his small product on a big one. Mark didn’t need dates because Facebook was already online and it had a lot of users. Estimate, in this case, was more for management order. Was it really necessary?

Story points concept takes a lot of time. You need many meetings to define points for every task of the backlog. Many development time is lost on this methodology. So, what if we don’t spend time on estimations and we focus on development.

#NoEstimates

With this idea in mind, It was born a No-estimates project. This is a software development project in which the team does not provide estimates for how long or how much effort it will take to complete the project. Instead, the team focuses on delivering value to the customer as quickly as possible.

The basic idea, as I understand it, is that it is possible to do small chunks of work incrementally, leading as rapidly as possible to a desired shippable product, and that when you do that there is no need to do much of anything in the way of estimating stories or the project.

Here are some of the benefits of using a no-estimates approach:

• Focus on value: No-estimates projects focus on delivering value to the customer as quickly as possible. This is in contrast to traditional projects, which often focus on meeting deadlines and budgets.
• Reduced pressure: No-estimates projects can reduce pressure on the team to meet estimates. This can lead to a more positive and productive work environment.
• Increased flexibility: No-estimates projects are more flexible than traditional projects. This is because the team is not bound by specific estimates.

Here are some of the challenges of using a no-estimates approach:

• Setting expectations: It can be difficult to set expectations for stakeholders on a no-estimates project. This is because the team cannot provide specific estimates for how long or how much effort it will take to complete the project.
• Tracking progress: It can be difficult to track progress on a no-estimates project. This is because there are no specific estimates against which to compare actual progress.
• Managing risk: It can be difficult to manage risk on a no-estimates project. This is because the team cannot accurately predict how long or how much effort it will take to complete the project.

There are a number of different ways to manage a no-estimates project. One common approach is to use a Kanban board. Kanban boards are a visual way to track work and to ensure that the team is focused on the most important tasks.

Here are some tips for managing a no-estimates project:

• Set clear goals and priorities. It is important to have clear goals and priorities for the project. This will help to ensure that the team is focused on the most important tasks.
• Communicate regularly with stakeholders. It is important to communicate regularly with stakeholders about the progress of the project. This will help to set expectations and to identify any potential problems early on.
• Be flexible and adaptable. No-estimates projects are often complex and unpredictable. It is important to be flexible and adaptable in order to manage the project effectively.

Real world

Despite being two wonderful methods, they can only be used by agile methodology. But what happens when you are not using them. On one hand, agile is useful when you are working in a product, or complex or unknown. What happens if you need just an institutional site or a blog. On the other hand, at the beginning of a product you need a way to think about how long it will take besides the agile, the sprint and all of that. You need a plan where you try to imagine the beta will be in 6 month or a year. Could the MVP take a year or two? That kind of planning is necessary to make a business plan. How much do you need to invest? How much do you need to ask and where will you ask for it?

So, how can we estimate a project or an idea?
Everyone has his own method. This is what I always do.

1. Break down the project into smaller tasks. This will help you to more accurately estimate the amount of time required to complete each task.
2. Estimate the time required for each task based on your experience. If you have worked on similar projects in the past, you can use your experience to estimate the amount of time required for each task.
3. Add a buffer for unexpected events. It is always a good idea to add a buffer to your estimate to account for unexpected events, such as technical difficulties or scope creep.

Your plan will always fail. At the beginning you will fail a lot, but year by year you will get better. Remember: you must learn from your failures. Try to understand what causes delay, what you forgot to include, and what you missed. Every plan is a new class, don’t forget to get back to them when you have new estimations. And trust in your experience and your instincts.

May the force be with you!