How estimate the "features"

Why not encourage the Developers to use the evidence of work already Done and delivered? Even more importantly, this evidence should validate that the forecast of work on the Product Backlog is appropriate.

What is your definition of a feature? 

Typically roadmaps are not as granular and detailed at the Sprint level. I've seen them use quarters, and there's the Now - Next - Later roadmap that doesn't show dates. 

1. Expert Judgment: Bring together a team of experts, including developers, product managers, and domain experts. Discuss the features in detail and leverage the collective knowledge to estimate the effort required. This can be done through brainstorming sessions or collaborative discussions.
2. Analogous Estimation: Use historical data from similar projects to estimate the features. Compare the current project's features with features from past projects, taking into account similarities and differences. This method is based on the assumption that similar work will require a similar amount of effort.
3. Parametric Estimation: Develop mathematical models based on historical data or industry standards to estimate features. These models use parameters such as lines of code, function points, or other metrics to predict effort. Parametric estimation can be more systematic but requires accurate historical data.
4. Three-Point Estimation: Use three estimates for each feature: the best-case scenario, worst-case scenario, and most likely scenario. Calculate the average of these three estimates to arrive at a more realistic and risk-adjusted estimate. This method is often used in conjunction with PERT (Program Evaluation and Review Technique).
5. Story Points (Agile): In Agile methodologies, teams often use story points to estimate the complexity of user stories or features. Story points are a relative measure of effort and complexity rather than a precise time estimate. The team assigns points based on their understanding of the effort involved.
6. Planning Poker (Agile): A collaborative and gamified approach used in Agile teams. Team members discuss and estimate features using a deck of cards with values representing different levels of effort. This approach encourages team collaboration and helps identify differences in understanding.
7. Function Points: A method that quantifies the functionality provided by software in terms of measurable attributes. It considers inputs, outputs, inquiries, files, and interfaces. Function points can be used to estimate the effort required based on the complexity and size of the features.
8. Use Case Points: Similar to function points but specifically tailored for estimating based on use cases. Use case points take into account factors such as actors, use cases, and transactions to estimate the effort required for a feature.

Hi,

a feature included a set of US (user story).
In the first sprint, we have all the US, so we could calculate the sum of the story points to get the complexity of the feature. But what about the other sprints?
My simplest idea would be to do some T shirt sizing. I've never seen a company that didn't make medium- or long-term forecasts to plan a budget. I'm surprised there's nothing in SCRUM for forecasting beyond a sprint.
Thank you Soniya for your ideas.

Scrum is silent on release forecasting but lots of complimentary practices exist and have been documented and written about in detail.

If your team has already delivered 'done' features in prior Sprints, search this site for 'probabilistic forecasting'. There are blog posts about it. It uses your team's data and probabilities and is the easiest way to go. You'll need a tool that shows throughput, cycle time, and can create a scatter plot, and has a Monte Carlo feature.

There's also Dan Vacanti's 'When Will It Be Done' book - highly recommended. It goes into depth on this.

Picked up a great quote from the PSPBM class - "Roadmap is a reflection of the product backlog, not the other way around". Roadmaps are not road plans.

Scrum is designed for complex problems where more is unknown than known. How do you predict the unknown? Can you predict now what you will prepare and eat for each meal for the next 6 months? Not likely. Why? We don't know what the future holds. There could be some market change that throws off your whole plan and forecast in the first week. Each Sprint could be very different from the Sprint before. The Product changes and evolves. The team's knowledge and experience evolves. Team composition may change. And so on...

Each estimation technique is really just a form of guessing. Use of numbers in our guessing may provide the illusion of precision, but has about the same potential for accuracy as high-level t-shirt guesses. Probabilistic forecasting gives us better numbers to reference based on past performance and is definitely worth exploring.

If you have a Scrum Team, you can determine the cost to operate that team by Sprint, week or whatever makes sense for you. This gives you a burn rate for that team. Your Product Vision and Product Goal supports where you intend to go with the product. What unrealized value or opportunity are you pursuing with this team in support of your vision and goal? Does it have the potential to make that Sprint cost worth it? Budget around that. This supports using each and every Sprint to maximize value and checking in to see if value continues to be delivered and if the path is still worth following (vs. working off of a plan made in the past). 

Hi, 

As we all know, if there are changes or adaptations as a project progresses, this can alter the schedule, but whether it's scrum or watterfall, the problem is the same, and the budget has to be renegotiated.  That's not the point.

Thank you Chris for your very interesting answers. I'm going to take a closer look at Monte Carlo solutions and probabilities, which seem more solid and promising than t shirt sizing. 
I'll keep you posted on the results with Monte Carlo and whether it really works.
 

As per knowledge, Estimating Features for a sprint  to create a roadmap involves breaking down each feature into smaller, manageable tasks . This can be done using techniques like story points, which assign a relative complexity to each task. By estimating the story points for each task, team can then determine how many tasks can be completed in a sprint, helping to create a roadmap for future sprints based on the team's capacity.