144

Using points is one version of what is often called "Relative sizing." For a very highly recommended initial perspective, check out this video and then come back. Most uses of story point estimation limit you to the lower end of the Fibonacci series: 1, 2, 3, 5, 8, 13 because the goal is to group things of similar overall size rather than to pursue a highly ...


83

Some teams also use powers of two, or have a scale like 1, 2, 5, 8, 20. The idea is that the larger the story is, the more uncertainty there is around it and the less accurate the estimate will be. Using the Fibonacci sequence helps teams to recognise this uncertainty, deliberately creating a lack of precision instead of wasting time trying to produce ...


46

I would add that having the scale non-linear helps with making decisions. It's much easier to say: it's more 8 than 5 than to say it's more 8 than 7.


37

I wouldn't say the points are better. This is a technique focused on a different aspect of estimation. It may turn out that your point estimation will suck more. Have that in mind. When estimating in hours you focus on answering the question "How long it may take us?". So basically it's more or less guessing, based on your previous experience. When ...


30

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


21

The essence of estimating in points is that it is based on relative sizing, whereas hour is an absolute measure. My 10 hours task could be your 5 hours task but we both would agree that creating a normal user registration page is smaller task as compared to creating a shopping cart module, so this approach reduces variability in estimates. Give points ...


20

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


19

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, ...


19

Try this simple exercise: What's the difference between stories with consecutive scores like 5 and 6? And that between 3 and 5 or 5 and 8 or 8 and 13 or 20? The fact that these 'buckets' are further apart imply that you are forced to make a choice between the less/more uncertain stories and choose which bucket is the most appropriate one. The human mind '...


18

It's all about abstracting away from a false reality. Points are better than hours because they force everyone involved, especially non technical stakeholders, to internalize that building your own software is not like shopping for features in a store. For better or for worse, business stakeholders almost always want to know "how much will each of my ...


17

In addition to the answer of Lunivore: Estimation can be done by using the Fibonacci sequence: 0, 1, 2, 3, 5, 8, 13, 21, 34, 55, 89, ... But the sequence we use most of the time is: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100 and ? 0 indicates a user story that doesn't take up any time at all. 0.5 indicates a task that is smaller then the smallest task ...


17

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. (...


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

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


16

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


16

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


16

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


15

As always there is no simple answer to this question. I would say that you should choose what works best for you. However as you say working with hours doesn't work for you. In my team it was the psychological aspect about working with points. When people are estimating in points they feel more comfortable, because there is no simple measure, that 1 point =...


15

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


14

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


13

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


11

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


11

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


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

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


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 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, ...


10

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


9

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


9

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


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