This link is not available

Thank you do much, these messages are giving more energy to produce even more videos. Thank you

I always love it. It’s analytical

Preferably in refinement sessions but it might happen sometimes that we need to review it in sprint planning

Tester estimation is for the testing process. They will estimate how simple/complex will be to test the feature. As testers, we need to create certain amount of test cases following different techniques before the actual testing.

Thank you for your comment Diksha, I think this is where it is important to break the link between Time and story points, The Scum master can ask the team to not think about time anymore and think about the complexity of the task (by using the fibonnacci sequence or Tshirt sizing), we do not necessiraly think about 2h or 2 days but we think about how complex is the task. if we are able to estimate the user stories in Story points instead of hours or days, then in the sprint planning, we will be able to see how many story points the team has accomplished in the previous sprint and that will be the amout of story points that we should take in for the upcoming sprint. Estimating user stories in time creates a lack of agreements between PO, SM and the team, and I highly recommend you start looking at how you can estimate your user stories using relative estimation

Dont mix story points and man days. Story points are have nothing to do with time. If you are going to estimate in time, just stick to time based estimation. The whole purpose of story points being invented is to tackle the problem with time based estimation where everyone will have different perspective, experiences, skillsets and so on. To keep it simple, you might remember that story points is always about 'comparison'. Imagine someone show you a table and ask you what do you think of it's size? Is it big, small, medium? By only give you 1 table and nothing to reference, can you estimate its size? No. When given two tables of different size, you can easily tell which is bigger and which is smaller... AND most importantly, EVERYONE will agree and have the same point of view, regardless who you are, your experience, your skillset, and so on. And the estimation is fast and simple, that's the purpose of story points. Unfortunately, many developers or people find it difficult to accept and loves to complicate things by introducing formulas or their own interpretation, which is you research about story points, the author himself was disappointed and don't recommend people to use story points because it was misused and cause more problems (e.g. use formulas to calculate story points and every developer has to learn this thing which is different in different projects and in the end, the translate to man days??? Why then in the first place, they don't just estimate in man days? Why go around in circles and convert back to man-days?) Story Points, if used correctly, is fast efficient and can easily be understood by anyone, that means by the customers, stake holders and estimation can be done on the spot during refinements very quickly. It promotes transparency and trust to the customers, stake holders. My team has been doing this estimations in front of the customers, and they were very happy with it because they were able to understand and see why it was scored this way. Furthermore, any new joiner in the project could participate in the estimation, regardless of their skillset, experience or knowledge on the project. If you're going to use story points, never translate or relate to time or man-days. There more to share on how this is done and why we use story points in numbers format instead of the 'size' like S, M, L, XL, etc.

​@@user-cu4bk2gm6q Thank you for this great point

The thing is that every team has its own understanding of what 13 story points mean, but in general I would say that if a story is 13sp maybe you can try it in one sprint and see if team is able to finish it, if not then of course 13sp should be split, in some cases some team are completely able to close a 13sp within a sprint and some are not, so I would say it depends on your team :)

One of the other things I struggle with is nowhere us an ideal scrum team size defined. A scrum call with more than 8 members presumably from attempting bring render a user story of a larger story point size, would not finish the scrum ceremony in 15 mins. Leading to either effort wastage or partial participation of the team.

What is in general said to be the best size for a scrum team is 7 +/- 2 which means anything between 5 and 9 is the best fit for a scrum team