This content originally appeared on DEV Community and was authored by thegreytangent
As a software engineer, we always underestimate the size and completion of the project. In this article I will discuss some tips on how to estimate a software project.
Let us give some analogy in order to fully understand the scenario.
Supposedly, my task is to transfer a bunch of cardboard boxes from the garage into the store room. When I looked at the task, I estimated that it would take a total of seven hours to transfer all the boxes. What I am doing is estimating only the duration avoiding the size estimation of the task.
For instance, I will try to estimate again , but this time, my estimation is based on computing the pile of cardboard boxes and its weight. So, let's estimate:
- They are 50 boxes.
- Each box has a weight of 30 kg.
- Transfer distance is 15 meters from garage to store room.
However, learning that information still is not enough. We need to know the average time of transfer of each box from the said location.
Based on my capacity, I can transfer each box 7 meters in one minute then rest for 15 seconds and move again 8 meters in one minute and 15 seconds, the total is 2 minutes and 30 seconds each box. Since we are estimating those numbers, we don’t give the exact number, instead to consider the margin of error. Therefore, the final estimation to transfer each box is 3 minutes. It takes me more or less two and half hours to transfer all 50 boxes from the garage to the store room.
What are Story Points?
Story points are units of measure for expressing an estimate of the overall effort required to fully implement a software feature or any other piece of work.
When the software engineer gives the points in each feature, don’t expect that those points are the same. This is commonly happening in software development, whereas two back end engineers that have the same skill set will have different story points in the same task. One reason for this is that the two of them have a different perception and process to accomplish those tasks. The goal here as a project manager is to collect all the story point of each engineer to make a future prediction of the accomplishment of their task.
Let us discuss how to use story points in the software development environment.
For instance, there are two software engineers named Bob and James. Bob is a NodeJS Developer that works in the backend and James is a ReactJS developer that works in the frontend. The project manager gives Bob and James the list of features and gives points for each feature and the most complicated feature points is 10.
Let us discuss the work given by two software engineers.
Bob rated the login by 5 points. If you ask bob, bob will tell you that is because when the teacher will login:
- He needs to filter the username and password.
- Check the username if has spaces in the first and last of the word and trim the words
- Check the username and password if it exists in the databases, etc.
Meanwhile, James’s rate 4 because:
- He needs to create two input boxes in the form,
- Validate the characters in the input box while the user is typing,
- If error detected it will display in the form interfaces what is something wrong.
Those tasks are not so hard for James but a little complicated for bob.
Let us proceed to the next use case “Teacher can add grades” features. This is more complicated in the backend because when adding grades there was another functionality trigger to it.
- Validate if grades are numeric.
- Grades should not be less than 60 and not greater than 100.
- Insert grades to database.
- Notify students of those grades already added.
There is some notification involved when adding grades that is the reason why bob rate 8 points in the backend. In the frontend, James gives 4 points because it's simple for James to create a form that validates the grades before submitted.
Now you already understand and see the benefits of story points. When you check other features that have an equal point in the previous, there is a possibility that the time and effort involved are the same. In the backend, login and add student are the same points rated by Bob. Therefore, you can estimate the time and effort to complete the task of Bob based on his previous story points. That’s how other companies estimate the overall effort and time in order to develop the application.
If you are a software engineer reading this you can now create an estimation or functionality rating (story points) of the features you are working on. And if you are a project manager I bet you already know this kind of strategy.
In estimating always remember:
In a good shoe, I wear size six, but a seven feels so good, I buy a size eight. - by Dolly Parton in Steel Manolias
Hope this article helps you understand the basics of story points. Let me know from the comment below if you have some suggestion or what technique you use to estimate your software project.
Thank you for reading and happy estimating. (-:
*Sources: *
Cohn, Mike. Agile Estimating and Planning. Prentice Hall PTR, 2012.
This content originally appeared on DEV Community and was authored by thegreytangent
thegreytangent | Sciencx (2022-05-01T03:31:48+00:00) Basic Guide in Estimating Project Size by Using Story Points. Retrieved from https://www.scien.cx/2022/05/01/basic-guide-in-estimating-project-size-by-using-story-points/
Please log in to upload a file.
There are no updates yet.
Click the Upload button above to add an update.