Story Points are nebulous units of measure. They are not tied to a specific units such as Hours, Man-Hours, Days, or Sprints. Story Points should compare the relative complexity of one Task/Product Backlog Item (PBI) to another. Story Points will help quantify the amount of work. Again, Story Points quantify work.
If your team is just getting started with Story Point estimation, it’s important to talk about the RELATIVITY of one task to another. You’ll want to start by coming up with a baseline. A baseline is simply picking a task and assigning it a value. It’s been my experience to use Days to help establish a baseline with the team. So, choose a few Tasks or PBI’s and use estimates tied to days and then quickly break from the idea of days and continue estimating based on the idea of, ‘is this next task easier, more difficult, or about the same as the existing tasks that have estimates’. Since you’ve kicked off the estimation session with days, it’s easy for the team to fall back into thinking about the estimates in comparison with days, but you need to break that line of thinking. Continue estimating newly refined Backlog Items using the relative technique. If you need to create a burn-down or release plan, start with a reasonable estimate to how many Story Points the team can complete in one sprint. This is called the Velocity – the average number of points completed per Sprint. If you’re looking for a tool to help the team with estimation, check out http://estimated.mobi which is available for iPhone, Android Phones/Tablets, and on the Web.
