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

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

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

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…

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

…to the number of story points (or ideal days) times the number of remaining sprints. If you have an average velocity of 20 and 6 sprints left, then this type of backlog should contain 120 points worth of work. Suppose the team finishes 24 points of work in a sprint.…

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

…face when estimating with story points. The training will be available until Wednesday, April 21 9 p.m. Pacific. To watch this video and find out when the next video is released, sign up here. In video one, I shared a sample of feedback we received about our coaching advice, designed…

…put some number of story points or ideal days on it as their estimate. To continue our example suppose they do the performance testing and any necessary tuning it reveals during sprint five. Well, in sprint six the team is adding some new features and here is where the second…

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

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

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

…someone else. Problem 5: Story Points Are a New Way to Estimate The idea of estimating in story points can definitely be a challenge for many team members. I can almost hear them thinking, “I have a hard estimating in days and now I have to estimate in an abstract…

…high-level estimates (usually in story points but possibly in ideal days) equals their average velocity. In capacity-driven sprint planning, a team selects one product backlog item at a time by roughly identifying and estimating the tasks that will be involved, and stopping when they feel the sprint is full. Velocity…