Getting started with story point estimation

hi guys welcome to the first session of being agile and in this session we are going to get started with story point estimation I think this is the most important topic that scrum team wants to know about about story points and why we should use it I will make a separate video out of this the basics I think you can also find a lot of videos on YouTube for that but we've I found there are less a video on how to actually get started with it so I'm gonna start this first session with this what I found the major problem with most of the scrum team is they want to actually start with a story point estimation they want to transform from hours estimation to story point but they actually don't know how to kind of do this so if you are also facing the same problem then this video may be right for you let's assume that we have a product backlog like this so a product backlog consists of different user stories added by a product owner based upon their priorities that creates a business value for their product let's assume all these user stories are refined as well as prioritized so to get started with the story point estimation the first thing you need to do is from your backlog you you need to decide what are the user stories that you are thinking of putting on the first sprint so it doesn't have to be accurate but this isn't an gut feeling that you have that these are the user stories that you guys think will complete in that the first two weeks friends among those user stories what you need to do is you need to first pick the user stories which is the smallest in size so this is this is a user stories that you think is smaller in terms of sites as well as complexity so from our backlog let's pick user story be as smallest in size now I have created seven columns for this example you can use any number of columns you want but to make the simple I will be using only seven columns so that it will be much more easier for you guys to understand this approach let's assume that you two story B is smaller in size in terms of size and complexity according to our project requirement so the next step you do is you pick another user story let's say the story a then you relatively compare this user story with user story be in terms of a fork story point estimation is all about relatively estimating so basically we when we when we compare user story a would be let's say we found user story a is comparatively larger in size and complexity then you destroy B so we just drag this too far column we will use similar kind of approach for all or the user stories so let's say you destroy D let's assume this is okay this is be smaller than user story B let's put this in first column then there is you the story to see let's assume this user story is bigger than user story a but not that much bigger so we will put this in borderline for now now moving to user story e this can be assumed as bigger than user story a again this is an example so then there's you the story if okay I see uses Trudy if it's bigger than you the story a but I think it's smaller than you just three now I can do like this maybe use the story is much more bigger than its users to DF now if you see we have all the entry user story that we thought would be part of Sprint the first sprint but we found we find over here you just to Ricci which is in the borderline so what you can do is you can see like maybe this user story is much more bigger than user story a but not that bigger as you just you just ref so maybe within that users to DF timeframe this user story can be completed then you can put over there otherwise what you can also do is maybe this user story is marginally bigger but not as big as user story F in terms of size and complexity so then you can put over here in the third column so the idea the idea is to kind of order all these user stories so that it matches some amount of complexity and size so user story D is relatively lesser work in terms of e for required users to D is much more work and all these efforts are decided as a function of size volume uncertainty in complexity now the next step is to have all this column with some numbers with some story points with some units so for that what we can do is we can use a term called Fibonacci series you people use T search size but I think people not a serious mo is the most effective one so what we need to do is we just have all the Fibonacci number in each column order so this is first column this is second column I'm just putting numbers initially when we started we just kind of ordered but now I'm just putting numbers and each user story point so let's do like this so if you see all user stories had some numbers see initially we did not even have any story points units added to this we just kind of relatively compared ages user stories and put that in order now for each column we are putting some numbers so this is how exactly you start with the first sprint or the any sprint that where you want to start with story point estimation and now you can consider okay you just rarity is is the size of story point one you just should it be inside the piece to user story a and C is three point three user story F is five and user story e is eight so then you start with first sprint like that now at the end of the Sprint you found that all these user stories were done within the same before that you estimated but you just release it took much more time than user story a you can then let's say assume that it's a story seat took much more time than user story F and maybe further more than user story e according to your definition of done so what we do so what you can do is you can put this user story as 13 now this is this is the thing that we are doing at the end of the Sprint we are doing this to make sure we map our effort to correct story points at the end of the Sprint now you move the Sprint to now you have to finish the stories that you thinking of doing on the story points now you a few things that you already have is you have and tentative idea of what is one story point and what is two story points what is 3 5 8 13 and maybe even more also you will have some idea about velocity how much story point was completed in that sprint so well estimating story points for other user stories you just have to now relatively compare the previous sprint story points and give them some unit value so let's assume there is another user story user story kay you just compare with the story be a whichever you destroy you think like this matches that's the Jim in this case use the story kate's same amount of you for that it took for you to study a so we just put that this is a three story points you just treat it probably was he's bigger than you the story key and maybe similar size at story point II so now you've already have an idea about how to add story points to each user stories user study are maybe a similar effort edge user story see so we can put as 13 story points as we move with few more Sprint's then you will already know the the way of mapping the numbers story points units with user stories so maybe in fourth or fifth spring you already have idea that the two story points is of this size and complexity edge story point will bits this size and complexity so this this exercise will help you to kind of get started with story points to actually man this this will this will be really benefit for the developers because they will now they have intend this tendency to work with hours but then they will kind of get an idea eventually to estimate and story points that's it for now if you have any question you can put that in comment and I will try to answer those accordingly thank you you