Difference between story points and time estimates
Posted on May 16, 2018
Comparison between story points and time estimates is the same as comparison between complexity and length. It can provide a long and interesting conversation, but it does't really lead anywhere. So let's state this out once and for all:
Story points rate the relative complexity of work, considering for example amount of components, integrations or decisions to be made. It’s often estimated in a Fibonacci-like format: 1, 2, 3, 5, 8, 13, 21. Different teams estimate work on different scale, which means their velocity measurement is also different. Because of the relativity, story points are very effective for measuring the effort within fixed length sprints: Team's capability and skills to burn story points can change, but sprint length stays always the same.
Time estimates rate the fixed length of the work allocated to a developer. It's often measured in hours, work-days or work-weeks: 1 day is 8 hours, 1 week is 5 days. All teams estimate time quite much the same way although with small variations in definition of man-day. Within a sprint only the amount of the available resources can change. Because of the fixed nature, time-based effort estimates are effective to measure the actual remaining time of the work, but they cannot expose relative differences between sprints.
Story points do not replace time estimates. Story point estimation can be made already when content of the task is known but implementation not scheduled. In Scrum for example these are items on the product backlog waiting for the upcoming sprints. Time estimate can be made safely only after a named developer takes the ownership of the activity. That's because every developer has a different capability to complete the same task - one developer might do it in six hours, while other needs eight. But for both developers the amount of the story points is the same.