How do you use story points?

(Heather) #1

I saw a blog post shared this week by @dar_dar called Why I Hate Story Points. I get why people hate story points (particularly when they’re used for the wrong reasons). Darryn mentions one of those reasons in his post

What usually happens is they are used to determine a team’s velocity.
A sprint goal suddenly becomes lets get 20 story points done this sprint, not let’s deliver stories that have business value.

I see some comparisons between it and the discussion in Estimating effort on a story. It seems to come back to “Why are you estimating?” or “What are you using story points for?”. Depending on the answers to this, do you really want to spend so much time on estimating the effort? As mentioned in the blog

Adding up the amount of time spent guessing these numbers will show you how much time we are wasting on this exercise.

Maybe in your situation, spending time guessing these numbers is worth it. Do you consider it guessing or are your team fairly accurate when estimating?

Have you tried the method Darryn suggests? Has it worked? Do you agree with the method he’s used?

(Vishal Dutt) #2

In Agile development, story points are the unit of measurement to estimates the overall effort that will be required to adequately implement a product backlog item. When assessing the relative size of user stories, team members are supposed to estimate the size of a user story as being 1, 2, 3, 5, 8, 13 and so on. The reason behind of using Fibonacci sequence is to reflect the built-in uncertainty in estimating larger items.

Generally, while providing story points following factors are taken into consideration:

Complexity involved
Business value
Risks involved
Amount of work supposed to be done
Dependencies

Software testing companies prefers using this process as it helps them to measure their velocity. Suppose, if a team has three completed sprints of 32, 30, and 43 story points, then their velocity at that point is established at 35 story points [(32+30+43)/3].

Hope the above information is useful and you can also get back in case need more information.

(Brian) #3

I have been in teams where story points have been used effectively. I have also been in teams where they haven’t. Here are a few things which helped make story points (and planning poker) a valuable tool.

First, we didn’t use them to determine velocity. Instead, the story points were a tool to tell the planners how much time the team estimated for new functionality. After the estimate was made and the plan was created, the story points served as a relative gauge of “is there a problem here?” For example, if we estimated that a point would take a day to make, and we are still working on it three days after we start on the story, we knew there was a problem (even if the developer said nothing, which was rarely the case) and we could give extra help to the person working on that story, if needed.

Second, we were a team who worked together for years. This meant that we knew not only our system, but how we worked on the system. This meant that, in general, our estimates were very accurate. Since nearly everyone was a domain expert, we were also good at resizing stories so that nearly every story was 5 points or less. We determined early in the product lifecycle that guesses of more than 2 days are just that… guesses. Since some functions cost more than 2 days and could not be reduced, we capped the estimates at 5. If anyone guessed more than 5 for a specific sprint, we would open the floor for discussion.

Third, we discussed each story before and after estimating. This was, perhaps, the most valuable tool in our estimating process. If a team member told us that he planned on doing X, Y and Z, the rest of the team could ask, “But have you considered U and V?” Or the we could remind them, “But you have to consider seemingly unrelated function F.” By talking about each point, the design of each story became better. There are other ways to do this, but framing the discussion in estimations worked well for us at the time.

Additionally, the estimates were not used as a team performance metric. Nobody was marked off for not meeting the estimates. Thus, our team wasn’t living in fear of not meeting the goal of “X story points this sprint.”

(Gem) #4

I’ve seen it done a few different ways. In agency it’s ‘our resource equates to X story points at X story points per day per person, so we should try to fit this many story points into the sprint’ which is not great due to the inherent uncertainty in story points.

I’ve also seen it done in a way to highlight if stories are too large. If the story is over 5 story points it’s a bit of a flag to see if we can break it down in anyway. A lot of the time it can, sometimes it can’t. It’s more of an indication than an estimation.

Currently we tend to do teeshirt sizes to vaguely estimate a story and make sure we’re on the same page with how much work we think a story is. We’re not consistent about using story points but velocity and being able to look at how much time a piece of work is something we’re looking at in the new year

(Lisa) #5

The teams I’ve worked on have never found velocity useful. What is important is a cadence. On average, how many stories do we get done every week? That helps the business plan ahead a few months.

IME the important part of planning meetings is the discussion about each story. Is the story the right size? I’ve found it best when we have fairly consistent size stories that each takes a couple of days to complete, including all testing activities. If a story is bigger than that, it needs to be sliced up more. And more importantly - does everyone share the same understanding of each feature and story? Techniques like story mapping (for the feature level) and example mapping (for the story level) help structure conversations and make sure we ask all the important questions, understand the rules and examples, have an idea of some scenarios to guide development.

Because our product is an online project tracking tool that is built around using velocity for automatic planning of each iteration, it’s a bit tricky to do “#NoEstimates”. So what some teams do is to decide if the story is one point or zero points. If it is more than one point, we don’t estimate it - it goes back in the backlog for more work, whether it’s missing specifications or needs slicing up. That way, we do have a “velocity”, which is the count of stories, which works well for our cadence and planning. And everyone outside the team who likes estimating is happy.