I think story points conceptually can work, but I always ask teams using story points how they are validating that there is a relationship between size and how long it takes to do something. Too often teams use story points blindly and just assume they are providing reliable information. A simple distribution chart of cycle time by story size will show you very quickly if there is a strong or weak relationship. Another point I make on story points is that they are not necessarily a measure of how much work a team can complete in a sprint. Technically story points measure how many points you close in a sprint. There is a distinct difference. A sprint velocity includes stories that have carried over from previous sprints. Teams need to understand the percentage of points that are started and completed in the same sprint in order to truly understand how much they can actually complete in a single sprint. Finally, story points still have a significant amount of subjectivity in them. On top of it they are an effort driven estimation technique. With most stories effort accounts for only a portion of the total cycle time and often that portion is not the majority of the time. Given all of that I think the deck is stacked against most teams using story points successfully. I am not advocating for using effort hours either. I believe a far more effective approach is to use historical cycle times. It significantly reduces the subjectivity and allows teams to account for the non-effort driven aspects of a story. I’m addition cycle times can easily be plugged into models for estimating larger amounts of work thus reducing time that would have been spent by the team sizing individual stories and likely providing a much more accurate forecast. Simply know the range of the number of stories to be delivered is enough to determine a forecasted completion range