TheBusyBrainFor a team new to agile software development, estimating user stories is not easy. The team is used to estimate tasks in hours and days, and know they’re never right anyways. So why bother? In agile, estimating user stories relative to each other using story points can give you a fact based idea about what will be done by when. But how can you do it?
Assign 1 Story Point For Fixing Typos
Usually, you start with the smallest story from the backlog. But how many story points it shall get? We are using PivotalTracker with a fibonacci scale for story points. In PivotalTracker the scale is 0, 1, 2, 3, 5, 8. For us, the smallest imaginable thing to change in our software is fixing a typo. This is what we would assign a 1. Now, we’ve got a reference point for our smallest user story from the backlog.
Assign 3 or 5 Story Points For Concrete Features
If we start from scratch, stories tend to be quite big. If you can tell exactly what needs to be done, you could give it a 3. If describing the story gets cloudy, but you still have a quite good idea what to do, give it a 5.
Assign 8 Story Points For “Epics”
If the story is completely abstract by now, give it 8 story points. 8 story points means: “This story is too big to really estimate it. It needs further investigation. Then we can break it down into a series of smaller stories”.
And What About 0 Story Points?
In PivotalTracker, chores (things which need to be done but do not create value for the user), have a simplified status flow. There is no “Accept” or “Reject” for them. If you’ve got to do bigger things which need testing, we use features as story type and assign them 0 story points. That way, the chores do not add to our velocity (exactly the way it should be: Clean up work should reduce your velocity, as you deliver less value for your users).
Estimation of user stories is always dependent on the team and the stuff to be done. The above guidelines have worked out for us in a couple of different scenarios. But your mileage will vary. What is your experience with estimating story points? Please tell us in the comments!
Agile Web Operations 
I do not agree with the ‘fix a typo for one story point’ way of thinking. Surely that is a chore/bug and worth zero points?
LikeLike
I think Matthias only wanted to give an example of a ‘1pt story’, but it really depends on your team’s practice of estimation. Typically something so trivial doesn’t even make it to PT. Important is that once you do start estimating like that, you refrain from making big adjustments later on. Use the benchmark and stick with it – only then is your velocity meaningful.
LikeLike
The reason I don’t like to use the Fibonacci scale of story points is that points need to be additive. The reason for having story points is so you can add them up. Then you get an idea of how many story points you can accomplish in an iteration. That’s velocity. And that’s the purpose of Tracker – to give you some idea of when a group of stories will get done. If your scale is just 1, 3, or 5, then I think the addability suffers. I.e., is three one-point stories anything like one three-point story?
LikeLike
I am “beta-testing” PT for my team, and so far I had come to terms with a 1-3-5 scale. I can see why the Fibonacci scale could be useful, yet I disagree with the idea of “something trivial not making it to PT”. What is the rationale behind using a tracking tool that you only use to track certain stories? In my humble opinion, you either track or you don’t, but I’m curious to hear more from you experienced users.
LikeLike
@Mark: I believe the “gaps” in the Fibonacci scale reflect the increasing inability to estimate a story the bigger it is. They do not make your points more or less additive than on a linear scale.
LikeLike
For us, everything makes it into PivotalTracker – even the typos. But also e.g. a text change to improve readability of your site could be a 1 pt story.
@Mark: Henning is exactly right about the “gaps” in Fibonacci. It’s really showing you that you can decide whether something is a 1 or a 2 (e.g. a typo vs adding a new form field with validation) but you cannot decide whether something is an 7 or 8 (remember: 8 could be epics like “mobile support”)
LikeLike
It looks like this article and point scale is not relevant any more for pivotal tracker? is this how pivotal tracker use to work?
LikeLike
Hi John, this point scale is still available, but is not the default one. You can change it in your project settings. See our post on how to get started with PivotalTracker.
LikeLike
So far we have never used any other scale then the default scale of PT. And we got along with it. Now that we have developed our own Tracker (because PT is not free anymore), we are just about to implement a variable scale. So, Google and this article gave me some good examples on how to do it different. Thx…
LikeLike