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?
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.
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.”
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
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.
I’m no expert on the story points game, for me I like to think of sprint velocity point totals as a panel show quiz host game where the points don’t matter and the prizes are all imaginary. Please do not follow this link QI - Wikipedia , it explains what I mean by points not mattering in the way we think they do.
I’m with @brian_seg on the whole mixed experiences, I’ve been in a team where our lead made this work, and been in teams where points were used wrongly. I look up to the people who grasp the ideas in the initial link to the blog by Darren Downey, and turn them into team happiness. Because it’s a thing that requires constant engagement, and is not easy. There is always one person on the team who thinks it’s all a waste of time, and best to just do the work, and one other person on the team who never quite estimates helpfully. Assigning points generically, and not as a function of timespan is most valuable, because we all know that the domain expert can do it in one day, but Tommy will take 2 or 3 to do it. It’s about being realistic and making it easier to shift tasks between people byt sizing generically - aka T-shirting. … And then you always get people like me on the team who play devils advocate when it’s not my job to.
Any team that compares it’s points to those of another team is missing the point, don’t go there. Breaking down the 8 into a 5, and then into smaller and smaller chunks, the ability to design in your head the steps needed means everyone needs to read the stories in their spare time, before coming to the meeting. I also find that having tasks that are not actually integration-testable becomes hard for the tester in the team to help with. Another thing to consider in the breakdowns.
I find the biggest failure in my team, at the moment is breaking down into things that can be done in just 2 person-days. (Remember points are not equivalent to days, it just helps to talk about days.) Far too often getting tickets that hang over into the next sprint as big bangs. The idea of never having more than ‘n’ stories in progress at any time might be what drives this upsizing of stories trend, but it’s a lie to use bigger stories rather than multiple small ones in flight and thus limit the board traffic. This has been inspiring, reading the inputs above, and at least getting some confirmation that I do understand some of it. Even if, I feel that my team is not doing awesomely right now.