Story Points VS Hours. Why Story Points May Not Work For Your Project?
Story Points is one of the most famous attribute of Scrum. At the same time for some people it could be one of the most mysterious and challenging ways to estimate the project work.
Although Story Points is the first thing that comes to mind when we think about Scrum, is it really always the best choice?
Here are the 3 MAIN KEYS to define WHY Story points may not work for your project…
Everyone in IT heard of them and many people think this the the best estimation approach for the Scrum teams. However, not every team uses them. To kick it off, it would be nice to define if there are any cons for using story points and why story points may not be the best solution for your project.
To clear it up, Agile does not equal Story Points. Story points is a feature of Scrum. And Scrum is only one frameworks under the Agile methodology. What is more, the global attribute of Agile is flexibility, meaning, you are free to mix the methodologies to find the best suitable approach for your team and for your project. If you need more details, make sure to check this episode where I’m breaking down the most popular project management methodologies.
Now, if you still have concerns, let’s move on and the first thing we are going to discuss is why Story Points may not work on your project. To do this, let’s answer the following questions.
1. Are you leading a product team OR an outsource team?
Estimates are always about money. Therefore, if you are leading an outsource team, most likely your team is provided on the fixed price OR on a time and material basis.
Fixed price is definitely not something about Scrum , but about Waterfall. Again, make sure the check the episode about the project management methodologies.
If we talk about time and material agreement, in this case the name speaks for itself. We are estimating TIME for calculating the project cost.
Time is something contrarian to Story Points from the project estimates perspective.
BTW, if you would like me to create a video about differences between the Product and Outsource teams, let me know in comments!
If we choose using Story Points on such type of the project it is going to turn into a real headache. AS at the end of the day we will have to convert Points into hours to make the appropriate calculations for invoicing the client and it breaks the whole concept of using Story Points on projects.
Versus, if we talk about the salaried employees working in a product team who are not constrained in hours dedicated VS cost, Story Points could become a nice alternative.
2. Do you have a development team only, or do you manage other teams as well?
Your response is going to impact the number of Story Point types you are going to have.
As you know, a Story Point is an abstract task we estimate the project work against to. These means you cannot use the same story point type for the development, quality assurance and tech-writing teams. Can you imaging a tech writer who compares his work to writing a few lines of code? I don’t think so.
The value and the idea of the Story Point may very across the teams and this is something natural. If we will have a look at a tasty cake the team of the cooks will think how much effort it would take to cook it, the team of the waiters will decide on how many pieces of the cake they will be able to sell, and the team of the students will think of the amount of effort to eat it.
Same is with the product. Different teams are going to apply different type of skills to execute different type of work. Therefore, they are going to have different values to compare with.
3. How much conservative your stakeholders are?
Another aspect to consider when choosing to estimate in Story Points, is how much conservative your stakeholders are. Although Scrum was not born yesterday, still for some people it is complicated to realise how Story Points work.
As you know the most frequent questions you are asked by the client are “How much?” and “When?”
Using story points the response may not be enough straight forward. Again, converting Story Points into hours or days is not the best idea as it destroys the whole concept and causes additional pain in the neck.
However, if your stakeholders are openminded and easy-going, go ahead and offer using Story Points. Otherwise, working with standard estimates might be less painful.
To protect Story Points I would like to mention that story points do not prevent having milestones and delivery schedule. The difference is that we are going to build the schedule based not on actual hours, but based on the team capacity and performance.
We have defined that Story Points VS Hours would work best for the product development teams with progressive-thinking stakeholders.
If you would like to continue the Story Points topic, make sure to like this video . If I will see your likes, in the next episode we will talk how to estimate work in Story Points. Chat soon!