…proponent of estimating in story points. (You can get a full overview of how to use story points from reading What Are Story Points.) In all of my training and writing about story points, user stories, planning poker, and agile estimating, I’ve been quite adamant that story points are about…

…teams were using task points to estimate their sprint backlog items in conjunction with story points for the product backlog items. This was intriguing. By then, I had already become a proponent of story points—I’ve since become even much more of a proponent because of the advantages that story points…

Story points are a unit of measure for expressing an estimate of the overall effort that will be required to fully implement a product backlog item or any other piece of work. When we estimate with story points, we assign a point value to each item. The raw values we…

…have separate definitions of story points? One viewer wanted to know how to combine multiple team plans if each team is using a different currency. To answer the question, Brian took a step back to ask whether rolling up all the team plans was even necessary. Sometimes it’s easy to…

…huge fan of using story points for estimating the product backlog. However, I also recommend estimating the sprint backlog in hours rather than in points. Why this seeming contradiction? I've previously blogged on the reasons why I recommend using different estimation units (points and hours) for the different backlogs. But…

…cost risk. Teams Think Story Points Are Just Complexity I mention this because I find too many teams who think that story points should be based on the complexity of the user story or feature rather than the effort to develop it. Such teams often re-label “story points” as “complexity…

If story points are an estimate of the time (effort) involved in doing something, why not just estimate directly in hours or days? Why use points at all? There are multiple good reasons to estimate product backlog items in story points, and I cover them fully in the Agile Estimating…

…velocity told a different story. The cause of this sudden and dramatic increase was story-point inflation. Or, more generally, estimate inflation, because the problem can happen with estimating units other than just story points. Estimate inflation is when the estimates assigned to product backlog items (usually a user stories) increase…

After working with story points for a bit, teams often realize they can calculate the team’s cost per point. The team’s product owner can use this cost per point to make decisions. For example, suppose a team’s cost per point is $2,000. Their product owner could then estimate that a…

…let me put some points on each car. I'll start with the least desirable car and put a 1 on it, a 2 on the next car, etc. That reorders our list so with points on each car we get: Tata Nano Toyota Camry Toyota Prius Aston Martin Vanquish Porsche…

…the work. What About Story Points and Velocity? You may have noticed that in the process so far, there has been no role for story points or velocity. Although I still recommend that product backlog items be given quick, high-level estimates in story points, neither story points nor velocity play…

When estimating with story points, most teams use a predefined set of values that doesn’t include every possible number. For example, teams commonly use powers of two (1, 2, 4, 8, 16,...) or a Fibonacci sequence (1, 2, 3, 5, 8, 13, …) By intentionally leaving some numbers out of…

…planning with use case points. Similar in concept to function points, use case points measure the size of an application. Once we know the approximate size of an application, we can derive an expected duration for the project if we also know (or can estimate) the team’s rate of progress.…

…is another type of story: the complex story. Complex stories are ones that cannot be split. They are inherently large or complex and there are no subparts to be pulled into separate stories. Even with a complex story, you don’t want to let the story linger open for three, four…