We changed our privacy policy. Read more.
32

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

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


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


20

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


19

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


19

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

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

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


14

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


13

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


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

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

in your practice, do you use the aforementioned disaggregation? Why or why not? I encourage teams to focus on estimating consistency rather than on having a complicated estimating approach. There are a number of reasons for this, including: Complicated estimates encourage people to believe that their estimates are more accurate and when they prove to be ...


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

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


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

The definition of done should be something that your team can do. Having external dependencies in a definition of done is a nightmare. If you want to test your story thoroughly, which is great, you need to have a resource on your team that can do that. Your team is supposed to deliver a final increment of the product. Delivering an increment that is not ...


9

I would walk the team through the Story splitting flowchart. Often someone has an idea how to split it, utilising the full team to split is often better than just trying to split it by yourself. Split during the planning or refinement sessions. An split here could be something like: Login with manual user creation, value is that you can test with real ...


9

The official answer to the problem is: There is no fixed numbers. If it makes more sense to have a big story be 100 points, go for it. If it makes more sense to have stories that are 1/2 point, use that. Use both if you have to. However, for your problem, you may want to look at your 1-point-stories though. Are those actually stories and what is your ...


9

You've encountered two important facts about planning: 1) Priority and value are not the same thing. You have a number next to each story. If those numbers do not have the property that 10 stories with the number 1 next to them are worth more than 1 story with the number 5 next to it, then the number next to each story does not represent value, at least not ...


9

Theoretically, yes, you could use a burndown chart to estimate when all of the work in the Product Backlog would be completed. However, in practice and as you are seeing, it doesn't always work out. Using a burndown chart to estimate completion relies on a few assumptions, such as that the Product Backlog is well-understood and is generally static. However, ...


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