Story points are one possible way of estimating the complexity of work in an agile world. And despite the fact that their introduction in the team brings a lot of advantages, in some teams their introduction may not succeed. In such a case, Story points can unfortunately end up as just another named substitute for estimating in time units. But what should you decide? Where can we introduce Story points without problems, where do we need to wait for the right time with Story points, and where might it not make sense at all? In today’s article I want to share with you some experiences that I use.
Why bother with Story points?
While there are other ways to deal with estimates in agile teams today, in my opinion, Story points are worth using for many teams. In the teams I worked with, Story points most often led to the following benefits:
- More accurate estimates than in Man days
- They support teamwork and building better substitutability in the team
- They help to better understand the assignment across your entire team. Therefore, there is also the potential for less bugs in requirements and fewer unexpected surprises during development
T-shape and role specialization in the team
Before we go any further, let’s take a look together at role specialization in beginning teams. Many teams new to agile approaches often exhibit significant role specialization. A highly specialized team includes, for example, a back-end development expert, a front-end development expert, a database expert, a testing expert, and a requirements analysis expert. The members of this team are great at what they do, but they are not able to help each other. And so if you want to plan deliveries with your team, you must always plan the requirements for each specialist separately.
The situation is usually different in start-ups. In start-up companies, it is quite common that one person has to deal with tasks belonging to several different specializations at the same time. People have, for example, one main specialization in which they are the best, and several others in which they can cope in simpler situations. This distribution of people’s experiences is called a T-shape. Conversely, the initial state with complete specialization is called I-shape.
Why go for T-shape in a team? It will help you reduce your team’s external dependencies and simplify the work planning for your team. Your team is thus more efficient and its operation is actually cheaper. Your team will be more self-sufficient and will not have to wait for other teams to handle their requests. An additional bonus is that T-shape makes it easier for you to introduce Story points.
Another name for Man Days?
Well, that’s it. If your team still has strong role specialization and no T-shape at all, you’ll probably still need to plan each specialist separately each sprint to keep everyone busy in the sprint.
If you introduce the use of Story points at this point, people will probably mentally convert Story points back to units of time as they are used to. This actually verifies that the front-end developer in the team has enough work for the whole sprint and also other roles. The implementation of Story points in this case does not bring any value, and Story points are basically just Man days with a different name.
One estimate for the entire team
Although T-shape is ideal for Story points, you only need the basics to work with them. Story points are useful when the whole team can estimate request complexity with a single number. In order to do this, they must have at least a general understanding of how each request will be tested, how demanding the modification of the front-end and back-end will be, if the request will require any integration with surrounding systems. They also need to be aware of the difference between a relative and an absolute estimate.
This doesn’t imply that everyone must understand in detail the exact changes to the code. Specialization in the team still exists, but it is not as strict as it was in the past. It is enough that team members listen attentively to colleagues who discuss the tasks required within the requirement during refinement or planning.Based on information from colleagues, team members can then compare the request with another one they have already dealt with in the past. They can also estimate if tasks are of similar difficulty or if one is more challenging. If initial estimates don’t align within the team, discussing discrepancies can enhance understanding and prevent surprises in the sprint
Are we ready for Story points?
You are likely to be successful with the introduction of Story points if:
- There is at least partial substitability in your team. For example, if the team is in a hurry, a developer or analyst can help with testing or other activities that are not otherwise part of their role.
- Sometimes it’s enough that your team members are interested in what needs to be done to successfully deliver a complete request to the customer as a team. So they also pay attention when other colleagues talk about working on the request. So they don’t just act as a subcontractor on the team who doesn’t worry about what happens next to their creation. On the contrary, they consider the team’s goals as their own.
- The team understands how relative estimates work (thus knowing which requirement is completed across all trades).
- Ultimately, the team needs to understand the benefits. You have to know why you want to start guessing with Story points and it made sense to them.
If none of the above criteria are met, it might not be the right time to begin using Story Points. If you try to do this anyway, there is a significant risk that your team will mentally convert the value of Story points back to time. This method of estimation will not bring you results.
So how do you get started?
Have you checked the readiness of your team for the introduction of Story points? The following few tips can help you improve the effectiveness of your team and the teamwork of its members. Additionally, they will also make it easier for you to introduce Story Points if you choose to:
- Some of the simpler requests are taken by a developer other than the colleague who normally handles these requests. An experienced developer will introduce the functionality and code to a colleague and perform a code review for the colleague before completing the request.
- Explain to the team that this is only partial replaceability. You are not trying to build an army of universal soldiers. 😊
- If your team doesn’t have enough time for sprint testing, ask if an analyst or developer can assist with testing the request. Customers care about the completed requirement, not which team member delivered their contribution on time.
- Consider adding a developer or another role to the team temporarily, someone who incorporates T-shape skills and replaceability into their regular work, inspiring others in the process.
With the motivation of the team to try Story points, it often helped me to agree to introduce them first for the test. We have agreed that we will evaluate their use over time and possibly make changes. In the end, only one team decided to return with estimates back to Man days.
So, if you choose to employ Story points for estimation in your teams, I hope their introduction meets your expectations. And if you’ve had helpful experiences with implementing Story points, please share them with us!
Would you like to learn more about successfully implementing Story points? For example, you can use our Scrum in practice – real use and best practices training.