How do you use story points to estimate sprint backlog?

I disagree with this statement: "The scale should reflect the level of uncertainty and risk involved in each user story, not the actual time or effort." It should involve the estimated volume and complexity of work in addition to the uncertainty and risk. It is also important to note that the sizing is relative. It is a good practice to use a story as a 'yardstick' for comparison.

in my experience Fibonacci is the better scales to used. The effort is merge from risk, complexity, developer experience and desire. Meanwhile, story point scale needs comfortable environment team with DoD e DoR clarified for all members of team, after that the story point scale have more probably to work with more accuracy

Story points to reflect the efforts involved, complexity, dependencies, risk and uncertainty. So team can use any scale to determine the story with lest efforts, complexity, risk, dependencies etc and then do the relative estimation with other stories with all the team member (developers) involved to perform estimation. In estimation only actual developers who needs to develop the code to be involved not any management. Manager and SME can only provide guidance.

Story points originated in the XP community as relabeled time estimates in an attempt to stop management from treating an estimated delivery date (a point estimate for an underlying probability distribution) as a guaranteed delivery date. The experiment failed. Story points later become associated with relative sizing and proxy variables such as complexity. However, they are always positively correlated with time (effort). Based on their common use cases, packing sprints, and forecasting, they are additive (ratio-scaled numbers) and not ordinal numbers (such as T-shirt sizes). Ordinal numbers cannot be added (T-shirt sizes cannot be added). In both common use cases, the average-size story works well, hence counts work.

Choosing a story point scale that aligns with your team's understanding is the foundation of effective sprint planning. By focusing on complexity, ambiguity, and dependencies, rather than actual time or effort, you ensure more accurate estimations. This approach encourages a shared language for estimating work and facilitates smoother sprint execution.

User story estimation typically occurs at a backlog refinement session. While teams should avoid anchoring, they should also avoid waiting for unanimous agreement. Discussing misalignments of story point estimations during a planning poker session can help others acknowledge risks and unknowns and time-boxing can help avoid spending too much time trying to reach unanimous agreement on the estimate.

I totally agree the whole team ( actual developers and testers) to be involved. Other might provide guidance but my input is not them to join as they are not delivering the work or developing and performing testing,

Sprint velocity is a great way to determine what the team will deliver in the next sprint or average of the past sprint velocity will help to predict the capacity for the next increment. Just remember data can’t lie and be trusted.

I agree. Data never lies. Our performance is dictated by the quality of the user story, not how fast it is completed, although time is most definitely a factor.

The best way to forecast how many stories will be completed in the next sprint is empiricism. How many stories has the team completed on average over the last several sprints? If that's ten, forecast ten, keeping in mind it is an average, meaning sometimes you will be under and sometimes over. There is no need for points, the results are the same on a practical level. If historical throughput (velocity) is chaotic, then forecasting is waste, and the focus should be on stabilizing the team. Finish work in progress, then limit work in progress until the work is stabilized. Something to consider, there is one goal per sprint. The team objective is to achieve the goal, not put points on a board.

Capacity is a tricky dealio. Some love it, others… not so much. At least by understanding it and the intent, our teams can begin to become more predictable at delivering value - the true measure of any team. I wrote a blurb on this recently - check it out here: https://www.dhirubhai.net/posts/cyberlyons_agile-scrum-kanban-activity-7060284879736840192-i7Jp?utm_source=share&utm_medium=member_ios

Calculating sprint capacity is a crucial step in sprint planning. It takes into account the team's real-world availability, skills, and past performance. While assessing availability, it's prudent to consider a buffer for unplanned leaves and unexpected disruptions. This forward-thinking approach ensures that the sprint plan remains resilient, even in the face of unforeseen challenges, enabling the team to deliver consistently and meet their commitments.

Story points is a discovery tool not a delivery metric. By using it in execution side with velocity and burn downs etc.. Agilist’s have misused it and brought damage to its intent to such a level that even the creator of this tool is regretful of his own creation. LinkedIn’s needs to do better than curating such topics .

In certain cases, the selection of user stories for a sprint may not solely depend on their story points. Implementation order can also play a role. Prioritizing stories based on dependencies, logical sequencing, or achieving a specific milestone can be a strategic choice. While story points reflect complexity, the order of implementation can optimize the flow and delivery of value to end-users, aligning with project goals.

We built a story point pole of common/known tasks to make it easier to reference for relativistic estimates. This published pole also made it easier for separate scrum teams to be on approximately the same scale.

There are a number of pitfalls associated with story pointing: Inaccuracy: Story points are inherently inaccurate, as they are based on subjective estimates. This can lead to inaccurate velocity estimates, which can in turn lead to missed deadlines and scope creep. Over-reliance: Some teams rely too heavily on story points, and as a result, they may not adequately plan for unexpected challenges or changes. Lack of transparency: Story points can be difficult to understand for stakeholders who are not familiar with agile development. Time-consuming: Story pointing can be a time-consuming process, especially for large or complex projects. This can take away from time that could be spent on other tasks, such as development or testing.

Story points are not a Scrum requirement. Scrum does not mandate their use. Story points were abandoned by the community that created them. Your customers do not know what story points are, nor do they care. Never use story points when communicating with customers or stakeholders.