Story Points Standardize For One Software Engineer Team
The purpose for this article is: to share to everyone what is the current format that I am using with my team project for the Story Points Estimation.
What is the Story Point in the software development team?
Basically, Story Points are a way for Agile software development teams to estimate the relative complexity of tasks. We already know that they use a sequence like 1, 2, 3, 5, 8, etc., to assign tasks based on their complexity, with larger values indicating more complexity.
There are a few methods to help us estimate the story points correctly for the tasks that will work in future sprints. But, I will share that blog later when I have time :D.
The current format of Story Point that I am using at the moment?
Why do I write this post? For the current project that I’m working on at the moment, we have quite a lot of feature teams, and seems like we have different types of Story Points definitions between us. So, I guess that every software development team out there is the same, there is no standardization on that. That is why I decided to write this post to share what my team is doing so far.
So, from the above, we can see that each of the engineers in the team will take around 17 - 18 points for the average per sprint (Note: I’m giving an assumption for 2 weeks per sprint. So it might be a bit different from you guys timeline).
But, based on my experience, it’s kinda helping me and my team a lot when we are doing the Sprint Planning with the product team, they can actually based on this see what is the current workload from the software development team at that moment, to make the decision easier, to adjust the delivery timeline as well.