…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…

…people understand and explain story points. It's not currently available but you can register here to find out when it's next released. Today’s post introduces the final installment in a free series of training videos tackling common problems teams face when estimating with story points. The training will be available…

…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…

…deadline. Mistake #2: Equating story points to hours The second mistake is when an organization tries to create consistency and predictability by insisting that a uniform definition of story points be adopted by all teams. A popular (but incorrect) way to do this is to force all teams to use…

…face when estimating with story points. The training will be available until Wednesday, April 21 at 9 p.m. Pacific. So far in this series of training videos we’ve looked at: Video #1: Equating Points to Hours Video #2: Getting Hung Up on Perfect Estimates And in this final video I…

…time allocated for putting story point estimates on any user stories that have not yet been estimated. No, I don't think this is a good idea. Keep in mind that we put estimates on product backlog items (which I recommend be user stories) so that: the product backlog can be…

…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…

…a portion of the story? First, Be Sure the Item Is Still Important When a product backlog item is not finished at the end of an agile sprint, it should first technically be put back onto the product backlog. Work never moves automatically from one sprint to the next. I’m…

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…

…as part of whichever story is implemented first. Assuming that this work is non-trivial, the estimates given to these stories will be influenced by which will be implemented first. In deciding how to estimate these and how to handle the common work between them, I suggest there are two guiding…

…develop this particular user story, but I think it will take twice as long as that other user story. As another example that's closer to home, I think pruning the trees in my yard will take twice as long as mowing the lawn. In the figure below, item B in…

…zero-point card? Remember that story points are used to estimate the effort involved in delivering a product backlog item. A zero-point estimate simply indicates that delivering that item does not require “any” effort. That is usually an exaggeration. The product backlog item will take some effort but usually so little…

…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…

…item estimated at 3 story points, days, or whatever units you use, is typically a higher priority than it would be if it were estimated at 100. To say this isn’t the case would mean that you always order the best wine on the wine list or drive the best…

…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…