Story Point Estimation Guide for Agile Product Engineering Services
Now there are so many write-ups on the following topic, why add another one. With time the importance of Story Points has never faded away. Every year the importance doubles and this year with the increase in remote or work from home staff, the necessity of having a story point to work with multiple teams from different locations.
There are different sizes of projects and often a large project goes astray with no clear estimation. Estimation is hard for any certified product engineer, if not the most difficult — it is definitely one of the major aspects of their job. With that at stake in it no wonder that management to product engineers in prone to get their undies in a bunch. However, that is a myth. Agile estimation for any inshore or offshore product engineering company is just an estimate and not a blood-swear.
You need not extend your work to weekends to compensating for the under-estimation of a piece of work assigned. So, how in this remote working landscape you can save days to be at your own self and make an accurate agile estimation for the upcoming projects in your product engineering company.
What on earth is a Story Point?
A story point is nothing but an abstract measure of the effort required to implement the user story. In nutshell, it is a common number that tells the team about the difficulty level of the story. The difficulty level could relate to complexities, risks, and efforts involved.
In most of the cases in a product engineering company, a story point uses one of the following scales for sizing:
- 1, 2, 4, 8, 16
- X-SMall, Small, Medium, Large, Extra Large (Like for the Shirt Sizes)
- Fibonacci Number: 1, 2, 3, 5, 8, 13, 21
However, it is important to identify the story from the scales assigned to them. In order to that, every product engineering team required to find a baseline story. It does not require to be the smallest one, but the one with which every team can resonate with. Once the sizing is determined the user stories should be initiated by comparing them against the baseline.
Understanding the sizing in detail
Let us understand the importance of sizing:
- As it gives us as an overview of the scope of work
- Uses a number of multiple perspectives to determine the size of the work
- Clears out that we cannot be exact always
- Steer clear the false assumptions
It is always the agile delivery team or the scrum team that considers the sizing. Say, for example, you have been given a task traveling from Mumbai to Delhi. The duration of the journey depends on the mode of transport chosen. By flight, it will be 2 hours and by car, it will take 22 hours. If you decide to travel by car, then you need to stay aware of the driver’s experience. Duration is depended on multiple factors, but the distance is approx 1400kms which is constant. Now do the same thing here, just replace duration with size -
- The amount of work to do
- The complexity of the work
- Risks or uncertainty in doing the work
- Time to be taken
Is it possible to estimate the effort or duration in agile? Unlike traditional projects in a product engineering company it is dependent upon:
- Tools or Technology
- Domain Experience
- Skillset
Sizing process in detail
Story Points vs Hours
The traditional product engineering company and their certified product engineers give estimates in a time format: days, weeks, months. Most of the agile teams have transitioned to the story points. The story points to rate the relative effort of work in a Fibonacci-like format: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. Though it might seem counter-intuitive the abstraction is helpful as it pushes the team to make tougher decisions considering the difficulty of work. Here are some reasons to use the story points:
- Dates do not take into account the non-project related tasks that inevitably creep in the days. And that involves emails, meetings, and interviews.
- Dates get involved with the emotional attachments
- Each agile team member works on a slightly different scale which means the velocity will be naturally different.
- As soon as you agree on the relative effort of each story point value so that you can assign points quickly without much debate.
- Story points reward the agile team members to solve problems based on the difficulty, not on the time spent. This helps the team members on shipping value and not on spending time.
Heard of “Planning Poker”?
Agile teams start out with the story points and use the planner poker formula. At Blue Copper, planning poker is one of the common practices across the company. Our certified product engineers take an item from the backlog, discuss them briefly and the easy members will mentally formulate an estimate. Then everyone will be holding up the card with the number that reflects their estimated value. If everyone stays in agreement, then great.
Though estimation is one of the high-level activities. If the team is too far into the weeds, take a little breath, and then up-level the discussion.
Learn to estimate smarter
Any individual tasks should not take more than 16 hours of work. If you are using the story points, you may conclude that 20 points ins the upper limit. It is simply hard to estimate that individual work items are larger than that, which is like considering a high level of confidence. That confidence is specifically important for the items at the top of the backlog. When something is estimated it is especially important for items at the top of the backlog. When something is estimated above your team’s 16 hours or 20 points threshold that has a signal to break it down into more granular pieces and re-estimate.
Deep-seated in the backlog, those tasks require only a rough estimate. Buy the time the team actually begins to work on those items, the requirements may change and the application might certainly require the changes in place. So assigning prior estimates won’t be something very accurate. Do not waste your time estimating the work that is likely to shift. Just give the product owner a ballpark estimate so that he or she can use it to prioritize the product roadmap effectively.
Have the right people working together
For every product engineering company, it is essential to have a common baseline across the multiple teams, maybe one or more representatives from each team. How many people should be a part, will vary depending on the size and the number of teams working on the same project.
If you have hardly three teams consider every member of each team. But for more than three, consider only one or two people from each team, better to say only the senior members of the team.
Understand from your past estimates
Well, learnings from the past should be a major part of the current estimates. There are so many agile tools available in the market, use them to track the story points, that reflect and recalibrate the estimate in a lot easier fashion.
For example, pull up the last 5 user stories the team has delivered with the story point. Discuss each of them and had a similar level of effort. If not discuss, then why. Use that for future estimation discussions.
I know the discussion inside our agile product engineering services company, but it is not just us, this topic of Story Points is yet a hot topic today. So, we would love to know what is your thought and approach to it? What works and what does not? Share your experience in the comment box below.
