Episode #125 of the Stack Overflow podcast is here. We talk Tilde Club and mechanical keyboards. Listen now
87

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.


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


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


18

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


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

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

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


17

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


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


15

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


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

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

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


11

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


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

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

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


10

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


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


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


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