How to consider Story Point in Scrum?
I am new to the community and really read some topics here, they are all helpful. And I am lucky passed PSM I & II base upon my working experience and understanding of Scrum.
But, this is special, "Story Point". When I am reading Scrum Guide by Ken and was certifying PSM, no one mentions story point but velocity and value, definitely I like the trend, value-trend. But back the terminology, velocity, I still feel confused how to evaluate the terminology, which measurable metric or perspective maybe? I cannot recall the questions in exam, but little bit, like "a team velocity like 55, and now down to 50 or 45..." We have the number exactly, how does it come out? Appreciate any answer and comment to help me on it, thank you all.
I still feel confused how to evaluate the terminology, which measurable metric or perspective maybe?
As long as the Developers have a satisfactory ability to figure out how much work they can take on in a Sprint, does it really matter how they do it?
Story points and velocity are not a part of the Scrum framework. They are complimentary practices that have come from other agile methods, primarily Extreme Programming.
Story points are starting to fall out of favor - see this article by the originator of story points, Ron Jeffries or these videos (1, 2) by PSTs Ryan Ripley and Todd Miller.
For teams still using story points, velocity is a way to measure how much work gets done each Sprint and can be used to forecast future Sprints, with the idea that (assuming no significant changes to capacity or way of working) the next Sprint will be like the past Sprint. If a team was able to complete 50 story points, then they can look at their story point estimations of work and make sure that the Product Backlog Items associated with the Sprint Goal are less than 50 story points.
As @Thomas said, Story Points have no direct tie to Scrum. I'm glad that he shared that article by Ron Jeffries because it is one I share often in these conversations.
Story Points are estimates. Estimates are guesses. Guesses are made based upon information you have at the time you make the guess. How you could ever predict performance based upon such information has always confounded me.
The word "velocity" appears exactly ZERO times in the current Scrum Guide. In my opinion, it is a misguided practice that people use to try and prove that work is getting done. When Story Points are used to create the measure, you are just measuring how many times you are able to complete something that you made a guess at. The guess has no relevance to the amount of work that is actually done. If you want to use metrics that can help with predictability, I suggest following the ideas of Daniel S Vacanti in Actionable Agile Metrics for Predictability.
I also advocate that those metrics never be shared with anyone outside of the immediate team that generated them. They are meaningless to anyone else. If someone wants to know if a Scrum Team is being successful or productive, look at the value of the increments that are being delivered to the stakeholders.
Thanks all the replies, personally I know story point is not part of Scrum, at least does not direct relate to. And thanks Thomas, Ron's article does help.
@Daniel, yep, "velocity" does not appear in Scrum Guide. The example I gave is the exam question, but sorry I cannot remember it clearly, either in PSM ream exam or maybe Udemy preq question.
But we still could see forecast in Guide.
"Various practices exist to forecast progress, like burn-downs, burn-ups, or cumulative flows. While proven useful, these do not replace the importance of empiricism." - Page 8, Scrum Guide
Forecast in chart means we still need number to look into, otherwise how we can show it? This is what confused me a little bit.
There are numbers that can be used. For example using throughput and cycle time can help. They are based upon actual time taken to move an item from one state to another. They do not require any type of guessing. Cumulative flow is another that uses actual values. It indicates the time it takes to flow through your entire workflow and helps you identify if there are places in the flow where items tend to stall or take longer. All of those are covered in the book I suggested.
Burn-down/up charts can be used on an item basis and do not have to use Story Points. Burning-down the number of items that are in the Sprint can help you see the flow of your work through the timebox.
Using metrics that can help you become predictable will help you to become able to do some forecasting. Forecasting on guesses (i.e. Story Points) is not real useful. Take the example of a weather forecast. Years ago, people did weather forecasts based upon their best guess at what would be happening over the next few days/weeks. As data gathering started and people were able to analyze past data patterns, weather forecasts have started to get more accurate.
As mentioned Velocity is a metric used in Scrum that is a measurement of the amount of work that is completed by a team during a sprint, It refers to the number of user stories completed in a single sprint.
Velocity is not really a metric required in Scrum. A lot of people use it though.
Story pointing has 2 parts: estimating and conversations. The conversation side is super useful. The estimation part should be for comparing the complexity/unknown/riskyness of PBIs (backlog items <> stories always) and not for trying to forecasting into the product backlog. There are plenty of studies that show points <> time very well at all. Flow metrics as per the PSK class are MUCH better.