A common criticism of story points is that the meaning of a story point will differ among teams. In this post I want to describe how can we establish a common definition of a story point across multiple teams within an organization. The best way to estabish a common baseline…

…axis and can show story points or ideal days on the vertical. It is updated once per sprint to show the team's net progress that sprint. A team's net progress is the amount of work they finished net of any changes in scope. So a team that completes 30 points…

…about the relationship between story points and hours. People who ask are usually looking for me to say something like “one story point = 8.3 hours.” Well, that just isn't the case (especially since I made up 8.3 hours). Let's see what the real relationship is between the agile point…

…will be delivered. Putting story points on product backlog items during sprint planning is simply too late for those benefits to accrue. There are other problems with assigning story points during sprint planning but assigning them that late does not allow the product owner to take advantage of the new…

…Do Scrum Without … Story Points? Can you do Scrum without story points? Absolutely! Story points are a useful way for team members to agree on an estimate. They get around a common problem: A senior team member thinks something will take one day, a junior team member thinks two…

…means that the user story or product backlog item meets a set of team-established criteria as to whether the story is ready for a sprint. These criteria are typically things like small enough to fit in a sprint, has acceptance criteria, and so on. You can think of a definition…

…to an old User Story and wondered, “what was I thinking?” On today’s episode, Mike Cohn, walks us through how and why he recently revisited and updated 200 Real Life User Story Examples from his past projects and updated a resource for you! Listen in as Mike and Brian share…

…user stories. Each user story has been estimated, most in the range of 3-13 points. Would the following approach be reasonable: Grab a random sample of 40 stories. Break each of those stories into tasks and estimate the tasks. From the task estimates come up with an average number of…

…talking about estimating with story points, I’m often asked: Why should a team estimate at all? Specifically, why should a team estimate its product backlog items? I can think of four good reasons to estimate: credibility, deeper thinking, prioritization, and insight. Estimates Create Credibility with Stakeholders The most compelling reason…

…of a given user story. They'll often claim they are something like 80 or 90 percent done and feel they should therefore get some of the credit for the story. Sorry to break it to you, Scrum teams, but coming close counts in horseshoes, not in velocity measures. My simple…

…Recommend Hours Rather than Story Points I recommend using hours for these calculations because most teams do not put story points on their defects. However, if your team does estimate defects in story points, you can use points for these calculations. I’ll proceed from here, though, sticking with hours. Nothing…

…by however many percentage points. And my bonus is tied to that. The more I can increase it, the more I get a bonus. Well, it's kind of like if you go to a team and tell them, hey, can you do more story points? They can certainly game that…

You’re probably aware that story points are meant to reflect the total effort to implement a user story or any product backlog item. I’m often asked whether a team can determine the total number of story points for an item by summing the number of points needed to program it,…

…that is estimating in story points ever re-estimate? This is a question I'm commonly asked and would like to address here. Most people have a natural feeling that re-estimating is somehow wrong but they can't quite say why. I'll encourage those individuals to stick to their hunches, and hopefully I…