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

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

…and how to use Story Points in estimating. Overview To estimate or not to estimate. There are many different views on the matter. It’s important then to start with why. Why would we spend time estimating in the first place? What is the benefit of that effort? Do all Agile…

Planning Poker® is a consensus-based estimating technique. Agile teams around the world use Planning Poker to estimate their product backlogs. Planning Poker can be used with story points, ideal days, or any other estimating unit.

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

…on the original, larger story. No. Part of the reason for splitting the stories is to understand them better. Team members discuss the story with the product owner. As a product owner clarifies a user story, the team will know more about the work they are to do. That improved…

…help solve some pain points. What were those pain points and what are these common struggles that you're seeing? Brian Milner (11:19) Yeah. Yeah, completely fair question, right? I mean, why didn't we do one on sprint planning? Or why didn't we do one on daily scrums or whatever, right?…

…value” on each user story. They usually do this for either or both of two reasons: to be able to measure the amount of “business value” delivered to the organization, usually graphing this sprint by sprint to be able to prioritize user stories by comparing the business value of each…

…wrong (like obsessing over story point math or demoing a copyright update in a sprint review). Along the way, they introduce the newly available Working on a Scrum Team public course and explain why it’s designed for entire teams, not just isolated roles. Whether you're new to Agile or knee-deep…

…discuss the common pain points and conflicts that can disrupt professional relationships and share effective strategies for creating a more cohesive and supportive coaching environment. Listeners will gain valuable insights into recognizing and leveraging personal and collective strengths and weaknesses, ensuring that Agile coaches not only preach transformative practices but…

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

…Hours worked Number of story points per person Burndown charts Number of defects fixed per iteration And many more Some of these might be worth tracking; others might not be. A fully transparent team would make all of this data visible. But transparency extends beyond metrics and can include conversations…

…will complete approximately 240 story points of work.” At the end of each iteration, an agile team assesses its position. However, there are many forces at work, and we need to consider each. First, and ideally most significant, is the amount of progress made by the team. Second is that…

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

…6. How to Estimate Story Points with Multiple Teams You say toe-may-to, I say toe-mah-to. Your team says five points, my team says eight points. Here’s how to establish a common story point baseline that can be used by multiple teams on the same project. 5. Time Pressure Improves Productivity…