I want to share this great idea about estimating that came from the excellent Mazz Mosley. Instead of worrying about estimating in hours or days, estimate in story points as follows:
1: This is trivial. I know exactly the code I would write if I went back to my desk right now.
2: This is quite easy. I know roughly what I'd have to do. I might have to look one or two things up.
3: This is a bit complex. I might have to refresh my memory on a few things and there are a couple of unknowns.
5: This is big. I have only a rough idea of how I'd do this.
8+: I don't know how to do this.
I've written 8+ rather than the more standard 8, 13, 21 etc because in our team we had an additional rule – if it's 8+ then the story is too big and you need to break it down a bit more. Maybe have a timeboxed spike? Then you will have more information for the next planning meeting.
It doesn't matter how much time each point ends up being (and this will vary from team to team); after a few sprints of estimating like this the velocity will become meaningful and you can use it for predicting how much work you'll get through in future sprints.
If you’d like to be notified when I publish a new post, and possibly receive occasional announcements, sign up to my mailing list: