Why GitScrum uses Fibonacci series for effort estimation?
Traditional software teams give estimates in a time format: days, weeks, months. Many agile teams, however, have transitioned to story points. Story points rate the relative effort of work in a Fibonacci-like format: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. It may sound counter-intuitive, but that abstraction is actually helpful because it pushes the team to make tougher decisions around the difficulty of work. Here are few reasons to use story points:
- – Dates don’t account for the non-project related work that inevitably creeps into our days: emails, meetings, and interviews that a team member may be involved in.
- – Dates have an emotional attachment to them. Relative estimation removes the emotional attachment.
- – Once you agree on the relative effort of each story point value, you can assign points quickly without much debate.
Before assigning a story point (a number from the series), consider the following factors when assessing the user story:
Consider following factors while estimating stories
Complexity : Consider the complexity of the story.
Risk : Consider the team’s inexperience with developing this story.
Implementation : Consider the implementation factors.
Deployment : Consider the deployment requirements.
Interdependencies : Consider other outside issues.
GitScrum uses the fibonacci sequence as standard for task efforts.
So why use points?
Because humans are bad at estimating effort, especially when complexity increases. In software development large features have hidden complexities which don’t become apparent until one is “in the weeds”. Every team is different. The purpose of using story points is to agree on estimates in order to most effectively plan and execute product development (sprints, user stories, tasks, etc.).