I've seen Story Points used in some of the more technical teams in my company, but have yet to come across them in my projects till recently, when I've taken up the responsibility as Product Manager as part of my role.
I've tried reading up on them, but don't fully understand. Would appreciate any insight from anyone with experience!
Story points vs. hours
Traditional software teams give estimates in a time format: days, weeks, months. Many agile teams, however, have transitioned to story points. Story points rate the relative effort of work in a Fibonacci-like format: 0, 0.5, 1, 2, 3, 5, 8, 13, 20, 40, 100. It may sound counter-intuitive, but that abstraction is actually helpful because it pushes the team to make tougher decisions around the difficulty of work. Here are few reasons to use story points:
Dates don’t account for the non-project related work that inevitably creeps into our days: emails, meetings, and interviews that a team member may be involved in.
Dates have an emotional attachment to them. Relative estimation removes the emotional attachment.
Each team will estimate work on a slightly different scale, which means their velocity (measured in points) will naturally be different. This, in turn, makes it impossible to play politics using velocity as a weapon.
Once you agree on the relative effort of each story point value, you can assign points quickly without much debate.
Story points reward team members for solving problems based on difficulty, not time spent. This keeps team members focused on shipping value, not spending time.
Story points and planning poker
Teams starting out with story points use an exercise called planning poker. At Atlassian, planning poker is a common practice across the company. The team will take an item from the backlog, discuss it briefly, and each member will mentally formulate an estimate. Then everyone holds up a card with the number that reflects their estimate. If everyone is in agreement, great! If not, take some time (but not too much time–just couple minutes) to understand the rationale behind different estimates. Remember though, estimation should be a high level activity. If the team is too far into the weeds, take a breath, and up-level the discussion.
The worst thing somebody can do, the first step to fail is to convert story points to hours. In fact, you do not need that because if you need to publish a date it is the date where your iterations ends. And if you need to think in hours then do not use story points, use other method to estimate. I know, this is the hard part of using methods more close to agile and that is where I agree a mindshift is needed. I can write a lot here, but go for "Agile estimating and plannig" book that belongs to Mike Cohn or go to his website: https://www.mountaingoatsoftware.com/blog Saving Changes...
In sprint planning meetings, when backlog is already groomed and prioritized then Scrum Master pickup one user story and ask developer how much time and effort it will take to complete this user story, let's developer says 2, then Scrum Master will ask tester/QA how long it takes to test it, let's say QA/tester says 1, then Scrum Master will assign this user story 3 points. Most commonly method used in Fibonacci method (1, 2, 3, 5, 8, 13....). Lets say if the developer says 8 then Scrum Master will tell BA (business analyst) to break this user story in 2 means this user story will consider as Epic. 8 points user story is hard to finish within sprint and specially when it has lots of dependencies and are complex.
Once first user story is sized then they move on next and so on.... till they reach the average velocity, average velocity is amount of work team can complete within sprint Saving Changes...