Anyone working for the software development industry, especially those who are part of Scrum and Agile teams, are undoubtedly familiar with the term “Story Points”. However, it seems there are no clear guidelines on how to use them or how to make estimations.
For the uninitiated, a Story Point is a unit of measurement used in Agile project management and development to rate the difficulty of developing a given user story. Simply put, a Story Point represents a number that assesses the difficulty level of the story. Difficulty levels may be identified by considering factors such as the risks, complexities, and repetitions involved in a specific task.
What is a User Story?
A term commonly used in software development and product management; a user story is a tool used in Agile software development to define a software feature from the end-user’s point of view. It aims to define a specific type of user, identify what they want in a specific (software) product, and explain why. In other words, a user story gives a concrete and simplified description of a specific requirement or need.
Through user stories, Agile and Scrum teams acquire a unified understanding of the user need for testing and development.
How Do You Estimate User Story Points?
Story Point approximation is done during the Product Backlog Grooming Sessions by the team responsible for the actual development and testing work. Here are some of the guide questions that can help you:
- How much work is needed?
- How complex is the work?
- What are the technical abilities and capacities of the team?
- What are the risks involved?
- What do we need before we can start?
- What do we need in order to finish?
- What could go wrong?
Each Story Point signals a normal distribution of time but it is starkly different from work hours. Hence, estimation does not equal to hours, days or weeks, needed to complete the project.
The product development team should arrive with a baseline story that they or the user stories could use to come up with an estimation. By estimating story points, the team assigns a point value to each story.
Common Tips and Tricks to Help Write User Story Points
In essence, the act of estimating user story points helps improve teamwork. Its end goal is to come up with an agreement between and among team members working on a specific project on which goals they want to achieve and on how they can accomplish these goals.
Points are usually based on the following scaling techniques:
- T-Shirt Sizing (X-Small, Small, Medium, Large, Extra-Large)
This method is categorized as a relative estimation technique. Its name and the idea of the way shirt sizes are indicated in the US. Instead of numbers, the development team assesses whether the story is extra-small, small, medium, large, extra-large, or double extra-large.
- Fibonacci sequence: 1,2,3,5,8,13,21
The Fibonacci sequence is a series of numbers, where the next number is the sum of the two numbers it precedes. If the development team decides to use this method, they will have to determine a baseline for each story point. Click here if you want to know more about improving business processes.
- The Planning Poker Method
This trick is a bit fun but nonetheless a fast way of reaching a team consensus of a story point for each item.
Here’s how to do it:
- Each team member receives a set of cards, with each card representing a number in the Fibonacci sequence.
- A backlog item is raised for discussion and the team can ask questions and clarify features.
- After the questions and clarifications have been settled, each team member privately selects the card that most accurately reflects their story point estimate.
- When all cards have been selected, the estimators reveal their cards at the same time.
If a consensus is reached, the team has to move on to the next backlog item. If the estimates vary, the leaders discuss until they arrive at a consensus.
Tip: Facilitators should show a complete matrix for the team to use as a reference. This ensures better consistency.
- The Rock, Paper, Scissors Method
This method capitalizes on the already familiar rules of the game. It’s a less formal way to measure difficulty and also sparks competitiveness within the team.
- The team should agree on a specific meaning for each hand symbol to match a specific work scale.
- The product owner discusses the customer details/ buyer persona to the team, explaining how it fits the overall goal.
- The team discusses the work item.
- Once the team is ready to decide, the facilitator signals and the developers and testers individually show the hand signal they chose to represent, according to their estimates.
- The group discusses their choice to come up with a consensus.
- The Affinity Grouping Method
A highly collaborative activity, this method works by creating and cluster ideas based on their likeness. This method gives your team the chance to gather data and organize them into categories and relationships.
- The facilitator shows a board indicating the agreed estimation scale across the top and lanes for the work items.
- The product owner discusses and explains the first work item.
- The developers and testers engage in an open discussion about the work item and how it will be implemented.
- After agreeing to the “hows”, the team then decide under which category to put the item on the board.
- The team proceeds with the other work items and repeats the process until they’ve covered everything.
- The product owner decides whether to accept the team’s input by initiating a discussion with them.
Additional Tips to Keep in Mind
Set a limit to each Story point. If the task or backlog scores more than the limit, it should be divided into smaller items. In the same manner, any item that reached a score lower than 1 should be joined in a similar task.
Involve other members of the team. Ever heard of the saying, “the more, the merrier?” Inviting a fresh pair of eyes or additional heads to the brainstorming session will provide you with new perspectives on the work required to accomplish each user story.
Give a rough estimate for items deeper in the backlog. Not everything will be smooth sailing, and there will be delays for sure. Do not ignore tasks that have long been placed in the backburner and give a fresh estimation for each.
Learn from past estimates. Many Agile tools are enabled to track Story Points, making estimations a bit easier. Check these tools to see whether your team’s user points estimation was accurate, and try to understand why or why not.
Estimate your team’s capacity and “velocity”. After working together for some time, and despite Story Points being a relative estimation method, you will have an idea on how fast (or slow) your team can finish particular tasks.
For instance, if your team usually gets 2 story points done daily, that counts to 20 points within a two-week work. This is defined as team velocity, and this can be very useful for user story mapping and sprint planning.
An important process in product management, Story Points estimation allows individual team members with different skill sets and working speed to agree on how to go through with specific tasks to complete a project, taking into consideration their differing productivity levels, among other internal and external risks.