i get this question a lot should i estimate in hours or story points is it allowed to estimate in hours and mandates when using agile and scrum what are the pros and cons of each method well by the end of this video you'll have the answers to all these questions and you know exactly how the best method to estimate your future user stories let's start with the basics why do we estimate in the first place well the key reason behind hours story points is that we want to estimate work to know exactly how much work we can accomplish in a given time for most people and companies hours as being the preferred method of estimation for decades because time can easily be measured we can easily quantify time and time is accurate but for non-mechanical activities like software development where the outcome depends on many intangible factors skills environment mood energy general energy of a person information available motivation so many things affecting the performance of a person or a team estimations are hard to do and often off which begs the question if estimations are hard to do and off why are we estimating in the first place and if you're using agile scrum you have a product backlog a product backlog which contains all the items that you want to build for the customer and the product backlog is sorted in terms of priority for most important things valuable things for the customer on top so why not just pick each item let's start with the first one you pick the highest priority item the top item stop development once you're done you move on to the next you move on to the next until the whole complete product backlog completely done in production to customers why not do that well in theory this would work this would work really well but in practice stakeholders upper management even your product owner will insist that they want to see estimations they want to know they want to have a timeline they want to be the roadmap they want to have release dates milestones and for all these things they need estimations from the team and because of this estimations are important essential in the project if used correctly and by correctly i mean by the correct definition of an estimation is used an estimation is not a deadline not a target date it's a possibility it's simply a guess an estimation is a guess given all the information that we have right now we are guessing estimating that we would complete this given amount of work in this amount of time we are guessing how big an item is or how long an item would take to accomplish based on all the information that we currently have but i'm sure that you experience that a lot stakeholders upper management don't understand what estimations or they think that an estimation is a correct figure we can use the estimation to set a target date a release date which can't be changed so if you're experiencing this in your company with your team explain to management that is simply a guess you can use the google definition of an estimation it says but it's a guess we are guessing predicting based on the information that we have and explain that to your team also and the cool part with estimation is the more we work together as a team the more we know the product the more we know how to work together the better we are at estimating it we use estimations to build a road map set target dates milestones do budgeting set goals and have target days to communicate to customers and if estimations are all about possibilities guesses how easy is it to have a team of people from different backgrounds different skills experience how is it to have a common understanding to build an estimation with all these profiles in a given team it's not easy it's not easy at all and that's especially true if you're using hours i highly recommend that if you're using hours to estimate a given piece of work use a range from 5 to 10 hours if you have people in your team with different backgrounds skill level experience an estimation is a guess remember that is a possibility and people generally believe and we understand that but as soon as you give a figure in terms of hours five hours to complete a piece of work it builds sort of an expectation around these five hours and if a person doesn't complete that in five hours the trust is broken especially from stakeholders and upper management even though they understood but it's a guess if you give an hour to that estimation we sort of believe that you would complete that in five hours it doesn't make any sense but it's like that in the real world and if you feel that all these issues are important to you you want to avoid all these issues in agile scrum we usually estimate in storyboards or t-shirt size basically the same thing when we are estimating in hours we ask for question how long will it take to complete a piece of work and when estimating story points or t-shirt size we ask for question how big is it looks similar but reframing the question from time to measure of how big or how small is it game change if you want more details on how to estimate in story points t-shirt size you can watch this video right here i did a full breakdown which you can use a step-by-step guide which you can use to estimate all your future user stories i personally like estimating in story points and there's three main reasons key reasons for that first there's no link between experience skills when estimating let me give you an example simple example let's say i'm estimating in hours i'm gonna there's a piece of work i say that it's five hours for me to complete it some people might believe that other people can complete the same task in five hours but i have five years experience and the other person who will be working on that might have a few months of experience maybe the other person will take 10 hours and if while a person takes 10 hours upper management will be not be okay with that because i said it's going to take five hours we don't know that multiple people estimated work and we can deal with that when using story points storypoints eliminate this problem because it's a universal measure of estimating across the team everyone from different backgrounds different skill level experience needs to answer the question how big is it how complex is this task to do and we talk about this and we discuss and they agree on a figure if you're using story points like five if you're using t-shirt size it can be medium everyone has agreed it doesn't matter if the person estimating the work will do the work later because it doesn't matter the person estimating my work is the team not a single person and because we used a medium large extra small five eight if you're using story point it doesn't mean anything it's a guess at prediction it's simply based on the complexity and the size of something no one if you give that figure to management they can't tell you okay you need to meet that figure doesn't make any sense for them what's eight what's medium if you give hours it makes sense for them they can see the hours and they will make you abide to what you said this eliminates the problem when using story points estimating in story points is also a relative approach when estimating in hours we take a story this one is five hours next story this one is eight hours but when estimating story points let's say we have a story in sprint one which is a story and we said that the story would be three points in the next sprint if there's a story which is quite similar we already know that this story is three points because it's similar to the previous story what we completed three points we already know how much work is how big and complex is three points and if we have another story which is maybe we say that it's bigger we know that it's not a three it's bigger than it's three maybe it's an eight maybe it's a twenty maybe it's a ten we don't know but it's bigger everything is compared to each other instead of individually estimating stuff it's easier we see a story we see that it's bigger we compare that to something that we know we've completed which is smaller and we give a t-shirt size or story point it's really really simple to estimate this way compared to hours estimating in story points can also be used to peel the road map to set target days management upper management vervet we love this prediction these releases these target dates and we can easily do that using story points we have a concept called velocity for the pace of a team how many points are completed each and every sprint by the team we can have average velocity for three previous sprints let's save over three previous sprints simple example we completed the team worked on 10 story points per sprint the average for the three previous sprints 30 divided by 3 it's 10 story points simple example we already know that there's 20 story points remaining until the next release 20 divided by 10 that's our base we know that it's gonna take two sprints to complete all the things required for the next release remember it's a guess it's still a prediction but we can use these story points to predict things releases target days coming communicate days to customers and all that it's still possible same as for hours if you want more tips insights on agile scrum personal growth click on the video that stands out for most on the screen right now and i'll see you in a few seconds