Many teams struggle with estimating in software development. They have to take into account many factors and make realistic appraisals. Product Owners must make estimations that guide the team’s workflow. Of course, most Product Owners try their utmost to estimate with precision. But often estimates fall short. Teams and Product Owners whose estimates prove untrue should not have to work massive overtime or suffer adversity. Estimates are exactly that, an educated guess about how much time and how many resources a project will need. So how do we make Agile estimates accurate?
User Stories are one tool Agile gives us to keep our estimates accurate. User Stories allow teams to describe the development process in simple terms. Teams write User Stories with plain language written from the end user’s perspective. User Stories describe a feature or function in the software development project. Teams work together to write User Stories. Each member offers their expertise about how long a feature or function will take to create.
Read more in our article about User Stories and difference with Use cases.
What are Story Points?
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.
How do we calculate Story Points in Agile?
To estimate User Story Points, teams consider the following factors:
The Story’s complexity
The capacity and ability of the team
Risks
Uncertain aspects of the User Story
Story prerequisites
Amount of work need to complete the story
How do Story Points differ from hours?
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.
Step 1: Fibonacci Sequence numbers
The Fibonnaci sequence is a series of numbers where each number is the sum of the previous two numbers: 0, 1, 1, 2, 3, 5, 8, 13, 21. Many Agile teams modify this to 0.5, 1, 2, 3, 5, 8, 13, 21. Using the Fibonnaci sequence to estimate the User Story Points teams work fast and with great accuracy. They do not average their Story Points. Instead, they discuss the work ahead in depth. Teams use Fibonacci sequence numbers instead of linear 1, 2, 3, 4, 5, 6 sequences when they cannot estimate absolute values with precision. In determining Story Points it’s helpful to show the difference between values. We can see the difference between 8 and 13 more quickly than the difference between 8 and 9.
Step 2: Story Point Estimation Matrix
Agile teams use the Story Point estimation matrix to show the complexity, risks, uncertainty and difficulty of the User Story. The matrix allows teams to outline at a glance the concrete reality of a User Story, not only how long the work will take to complete. Story Point Estimation Matrixes usually take the form of a table.
Step 3: 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!
