31

No Fibonacci Required While many agile practitioners have embraced a modified or unmodified Fibonacci sequence for story-point estimation, neither story points nor user stories are actually requirements of the Scrum methodology. Even if you embrace the practice of estimating with story-points and user stories, you can use any relative-sizing tools you want....


23

TL;DR Much of Scrum's value to an organization is in creating transparency. 100% agreement isn't the real point of planning poker; the goal is actually to narrow the cone of uncertainty around feature estimates as much as possible, and to make the level of effort and potential project risks of each story visible to stakeholders through their chosen proxy, ...


22

TL; DR Story points represent consensus within the team. The goal of estimating story points is not to provide the largest or smallest estimate, but to accurately reflect the effort required by the entire team to meet the "definition of done." Lewis Carroll Does Scrum Consider a story like: As a practitioner of Extreme Dentistry, I want to know how ...


20

When estimating user stories, everyone should be estimating the complete effort it will take the team to get the story to Done. So, the back-end dev should not just estimate the effort it will take him to do his part, but his estimate must also include the effort for the front-end, the design and all testing (and similar for the other team members). The ...


19

TL;DR Should velocity increase with time? The simplistic answer is that a project's velocity should only increase until the team has developed a stable, predictable cadence that can be maintained over time. There are a few caveats, of course, but it's a solid rule of thumb. Targeting an indefinite upward trend on velocity is a "project smell" that the ...


19

The only certain answer is: sometime before the story is added into the sprint. After that the story point estimate doesn't add much value. Common times that Scrum teams estimate stories: Backlog Refinement: In backlog refinement the team looks one or two sprints out to see what is coming up and prepares these stories to be brought into a sprint. ...


18

One main reason is to not have debates/estimates like: 19,20, 21, 23 Story Points. In agile estimation is usually about comparing relative size, it's clear that 1 Story Point is significantly smaller than 10 Story Points, but 10 SP vs 9 SP is not much different. You want to make sure that bigger numbers are rough estimates and you're not sending to your ...


18

Story Points Estimation and Hours Estimation have different purposes. We use Story Points during Product Backlog Refinement. Story Points are good for high-level planning. When we make an estimation in Story Points we talk about the productivity of the whole team. During high-level planning, only the productivity of the whole team is what matters. Story ...


17

Consumed Story Points: An Agile Anti-Pattern "Consumed points" are a sort of burn-down metric that some practitioners use to track progress of a story against its original estimates. It's intended to show percentage of work completed, estimate overruns, or to reduce the need for collaborative communication about story status. In my coaching practice the ...


16

Research stories (called Spikes in Agile terms), should be: used sparingly kept short always be time-boxed Should we assign a time box (so many hours) for research stories or a regular point estimate? Regular point estimate cannot be used mainly due to following reasons: story points give out a measure of business value points are used to calculate ...


16

Working software over comprehensive documentation. In general, I'd say that it just gets fixed and considered part of the work needed to complete the story. When you found the bug, you added a failing test to document it prior to fixing it, right? Right? Thats more than enough documentation for most use cases and doing anything more is useless overhead. (...


16

Ask yourselves this one question. Is there any possible way to do anything less, and still deliver value? If yes, write that smaller thing down. Then, ask yourselves again. Is there any possible way to do anything less, and still deliver value? If yes, write that smaller thing down. Repeat until the answer is: No. It's simply not possible to ...


15

Story points are a relative measure of effort rather than an absolute one. However, each member of the team should have the same understanding of the size of a points estimate. A common understanding is achieved when the team estimates repeatedly together and when they agree common baseline stories against which to measure. This is really no different to ...


14

TL; DR Should we assign a time box (so many hours) for research stories or a regular point estimate? You should do both. A spike (or "spiked story") requires both a time-box and a level-of-effort estimate, and is always counted as work. Spikes Are Just Special User Stories As one source states: Like other stories, spikes are put in the backlog, ...


14

In order to make the burndown chart useful to the Product Owner (or the customer or the user or another stakeholder), then burning down based on stories is going to be the better option. Since a story is supposed to represent something that is useful and meaningful to the stakeholder, so knowing how many have been completed with respect to your definition of ...


12

You can't be faulted for being confused. It is very common for organizations to try and directly match story points to a real-world measurement. This exactly defeats the purposed of using story points (and why I dislike Poker Planning for estimating). A Story Point in simple terms is a number that tells the team how hard the story is. Hard could be related ...


12

TL;DR Velocity is simply a proxy for measuring team capacity over time, and shouldn't be used for historical time accounting. Always estimate based on the current level-of-effort and complexity, and this will naturally result in incomplete stories being reflected in velocity as drags on capacity. Stories Shouldn't Carry History Don't treat stories as ...


12

Perhaps a more accurate way to put it would be that story point estimates are imprecise. If you have a 5 and a 3, that may or may not be the same size as an 8. To make this less confusing, let's start with a non-numeric scale like T-Shirt sizes. XS, S, M, L, XL and so on. We can agree pretty easily that a small and a medium t-shirt do not get you a large t-...


12

Let's be serious, people don't usually care how you do estimates. What they care about is how much it takes and/or how much it costs. Time and money. That's what they want. The estimates is just something that helps you answer those questions. It doesn't matter what you use for estimations as long as people can get back a time or money value. It can be ...


11

TL;DR For agile projects, a basic formula for estimating budget is: (totalStoryPoints / velocity * teamHoursPerSprint) + nonLaborCosts = budgetEstimate The results should be reported as an estimated range using statistical confidence intervals or a "high, low, average" method. Estimate Budget Using Iterations The "secret" to estimating agile budgets is ...


11

Typically, yes. The amount of estimated work in the Sprint represents what the Development Team believes it can accomplish during that Sprint. If new work comes up, it's not like the Team suddenly becomes able to accomplish more work. So if you are adding work in, take work out. Unless, of course, for whatever reason the Team decides it does suddenly have ...


11

Two things jump out at me. First, the end result of a Spike is not a shippable product. Spikes are used to learn, and do research. The end result is an answer to a question or finding some information or gaining knowledge in a given area. That doesn't mean that there's not an output associated with a Spike, but it's almost certainly not a shippable product. ...


10

Although probably not an intended feature, one of the benefits of using points from a manager's perspective is that tasks are measured by complexity rather than by time, which allows you to easily see who on the team works faster than everyone else. For example, you know that it takes person A 2 hours to do something, but takes 10 hours for person B (for a ...


10

TL; DR Story points measure effort; hours measure time. They are not interchangeable. You're going to be better off estimating man-hours, ideal hours, or calendar days from the beginning. Scrum may not be the right fit for you, either. Kanban or Lean might be a better approach given your IT Governance constraints. Story Points Don't Fit Your Organization ...


10

The answer is really simple and really complex: Simple Answer: In Scrum you don't Complex Answers: If you know the extra tasks before the sprint starts and the team decides that it's necessary to do them, then just do them and lower the forecast. Common courtesy suggests that you tell the PO why you included the extra task. If you know the extra tasks ...


10

Summary To calculate velocity when using non-numeric relative sizing, you first need to map your story sizes to numeric values. I provide a working example of how to do this with tee shirt sizes, and then show how to calculate the mean velocity of some shirt-based Sprints. I also provide some of my thoughts on this as an agile technique, and some ...


9

Mike Cohn in Agile Estimating and Planning describes estimation using story points vs ideal days in Chapters 4-5, then compares them in Chapter 8. Regarding research: There is credible evidence that we are better at estimating “this is like that” than we are at estimating the absolute size of things (Lederer 1998; Vicinanza 1991). The sources of these ...


9

trying to wrap my head around this question, so forgive me if I go off base. I'm going to tackle this assuming your billing as a team. I'm going to also assume a designer is a UI person. The team has a velocity, not the individuals. So your sprint planning needs to be focused on what the entire team can manage in the sprint. If your developers are your ...


9

Based on previous experience with lots of different approaches, I would agree with your last paragraph - showing anything except true value delivered (tracking tasks, hours, points etc.) often leads to sprints where a lot of items are almost done and very little value is created. You could also look into ways to break the items up into smaller items (not ...


9

Below is my answer to the question What to do with estimation of incomplete story? on Software Engineering Stack Exchange. Although the question is worded slightly differently, it is asking essentially the same things. Firstly, what happens with those user stories? Do you just carry them over into the next sprint? It depends. If no other story has a ...


Only top voted, non community-wiki answers of a minimum length are eligible