Software development Teams use Story Points to explain the difficulty of a User Story. Story Points act as a quick shorthand for teams to see how challenging a story’s work will prove.  Teams base their Story Points on several factors. These factors include the complexity, effort and risk involved in a certain story. Agile teams estimate Story Points during User Story Mapping.

User Story Mapping is where teams create dynamic visual plans for the software development project. Agile teams don’t write out a linear list of backlog items Instead, the software development team outlines their User Stories with (virtual or actual) post-it notes or index cards. Story Mapping keeps teams focused on the actual needs of end-users.

So how do Story Points differ from estimation in hours? Why choose to estimate Story Points rather than by the hour? In traditional waterfall software development, teams estimated their time to finish a project in time. They would give a rough timeline of hours, days or weeks the project would take to complete. Agile teams have found that Story Points work better to explain the actual effort required to complete the work of a software development project.  Agile teams use Story Points to describe the complexity, effort and technical skill necessary to finish their work. Story Points keep teams focused on value and project completion, not on time spent  (productively or not).

Story Points help teams estimate the velocity at which they will work. This is useful for User Story Mapping and Sprint planning. Agile teams can check the number of Story Points and compare with their velocity so they ensure they do not under- or over- commit themselves.

Read more on the topic in the "What is scrum velocity and how do we calculate it?" article.

Agile teams take three steps to estimate Story Points. They use Fibonacci sequence numbers, the Story Point Estimation Matrix and Planning Poker. 

Teams use Planning Poker to agree on Story Point numbers for items on their Backlog. During the Sprint planning meeting, each team member receives a set of cards with the numbers of the Fibonacci sequence. The team then discusses Backlog items. Each team member then privately selects the number they believe represents the Story’s point value. All team members then reveal their cards to each other. This helps build consensus. It also helps team members to express themselves without influence from other team members. 

If the team agrees immediately, wonderful! If not, they should take a few minutes to discuss their choices so everyone can understand them.  By the end of Planning Poker the team should have their tasks laid out in order of priority. If a task is smaller than 0.5 the team can combine it with another task.

Here at Blocshop we take full advantage of Story Points to prioritize our work. We believe the power of Agile gives us an advantage when it comes to software development. We work fast and under budget because we plan and estimate fluently. If you’d like to learn more about how Blocshop can help you with your software development project, please do get in touch!