When you have already found the team for your software or hardware product development and all the requirements are ready, you're probably in the stage of planning the development process itself.
We described in our previous article some general principles of the workflow (what a sprint and backlog mean, who stakeholders and product owners are). Now, we are facing the question: How do you estimate the time and effort developers need to dedicate to specific feature development and your project in general?
The estimation will tell you how much money, effort, resources, and time product development will take. At Lemberg Solutions, we use Story Points to estimate development projects. Read more about estimation in the story points below to determine whether this method could suit your project.
What are story points?
A story point is a theoretical measure that shows the difficulty level of any work on a project. The complexity level is usually influenced by several story point estimation factors, such as the volume of work, complexity, and any risk or uncertainty that may occur.
For example, removing a particular UI element, like a button, is easy, while developing tablet support for a smartphone app requires much more effort.
The overall project estimation entirely depends on the scope of work you send to us, which can vary during the development. Also, the estimate will be affected if you give us unclear requirements, which causes uncertainty. In addition, if a feature involves modifying a piece of legacy code, the estimated value will also rise due to the potential risk.
You might agree that estimating some items as 97 and another as 98 (out of a maximum of 100 points) appears to be quite vague since a 1% increase in effort is not a tangible difference. We use the following typical values 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, and 100.
Advantages of story point estimation
Story point estimation entails discussing each function and its total cost between all team members. This approach helps reach a mutual understanding of the size of each function and its relative story point estimation - how much time and resources it requires to complete. Also, this estimation approach sets realistic expectations about the required time, resources, and budget to complete the project successfully.
You cannot use the sizes of stories defined for one project for other projects as each story has its specifics. We will discuss various techniques later in this article, but all of them have one aim to reach a unified result regarding each story.
How to estimate story points
To assign story points to each item in the backlog, we hold a meeting where all specialists working on your project get together.
The product owner picks an item from the product backlog (a list of all requirements that need to be done on the project). Our development team members ask multiple questions and discuss the picked part of the project to understand the implementation details. The deep discussion helps everyone see a different perspective of product development.
The next step is an estimation itself. We do it individually by choosing a card with a particular value that reflects the effort required to complete the work. It is called the planning poker or sprint poker Agile estimation technique. When all the members are ready with their story points — they reveal their cards simultaneously to see if the values match. If they do — the team picks another requirement from the backlog and goes through the same procedure. If not — the team takes more time to figure out a common estimate. There is no difference between middle and senior engineers, and everyone has to propose an estimation.
An important concept of assigning story points to items from the backlog is that the team members are not actually 'voting', and as a result, they will not elect an estimate that just simply gets the most votes. Instead, the team considers each team member's opinions. Therefore the reference of the specialist who is most familiar with the exact part of the work will impact the final decision.
Note: since story points are relative by nature, they are primarily related to the project context. Mobile projects will have 'smaller' story points compared to enterprise-level applications. The following Agile story point estimation template is suitable for small to mid-size mobile/web projects.
4 story points estimation methods in Agile
Despite the wide variety of Agile story point estimation tools and techniques, they have many similarities. We picked the four most popular estimations and would like to cover the peculiarities and processes of each estimation method. The main purpose of these techniques is to reach joint estimation results for each story within the engineering team.
1. Planning poker
Planning poker is one of the most frequently used Agile estimation techniques that help the team view the project priorities from different sides and decide on the final project estimation. Here is how it works. The project is split into a set of cards. Each card represents the feature of the future product, which requires a diverse amount of time and resources to be built. Then, each card is presented by the team member to discuss and approve its estimation. As all cards are concerned, the team gets the final project estimation.
2. T-shirt size estimation of story points Agile
This Agile estimation approach entails assigning each feature a specific size from XS to XL, where the size type is determined by the time and effort the team needs to complete the feature. After that, the project components are grouped by size, not the specifics of work which gives the team a general overview of the project and enables accurate estimates. However, the team must approve each item's size to set the right priorities and story points Scrum assessment.
3. Bucket system story point estimation in Agile
First, the dev team creates several numbered buckets, where each bucket stands for a particular feature or task in a project. The higher number, the more complex the development of the feature. Before putting the item into a bucket, the team discusses its complexity and potentially required resources to decide the correct number. When all items are divided, the project estimation is considered ready.
4. Affinity mapping system
The dev team structures the project items into groups according to their complexity and similarities based on their experience. As all items are distributed, the team discusses the results to decide if each project task corresponds to its level of complexity and required time and resources.
Besides the listed approaches, PMs may also use the dot-voting decision-making technique. They help select several most critical items (usually 2-3) during sprint retrospectives or planning. The dot voting story points Scrum estimation method is commonly used for small-size projects. A PM breaks a project into features, placing each on a general board. Then, all team members vote for the complexity and duration of each feature development by putting dot stickers on the relevant item on the board. The more dots the item gets, the more time and resources it takes to complete.
Let's practice
As a story points example, here's an estimation of a sample application. This app would allow the user to create an account and seek job possibilities with basic messaging functionality. All features contain several subtasks, each requiring a certain number of story points.
Summary
Overall, estimating your project with Story Points helps better meet your time expectations for future work. When all backlog tasks are calculated in terms of Story Points, we can determine how many sprints we will need to complete the project.
FAQ
What are story points?
Story points are conditional assessments that determine the complexity level of a specific part of the project.
The more complicated the sprint is, meaning it contains a vast scope of work and many potential risks, the more points it takes. The estimate depends on the time and effort the part of the project will take. The team can use a similar project as an example to evaluate the difficulty and required effort.
Benefits of using story points
Story points Scrum estimation gives complete flexibility. There is no need to re-estimate if any changes in sprint scope arise. If the complexity of work varies or some new tasks appear, you only need to add more story points to the general scope.
How to estimate story points?
First, the dev team collects all project requirements into a product backlog list. Then, the PM divides the items from the list into sprints, where each item is estimated in the story points depending on the difficulty and required effort. The sequence of building the features is discussed in the meeting with the team.
