📚 GET OUR FREE AGILE BOOKLET WORTH 39$ oelean.com/agile-booklet/

@9gager87

5 ай бұрын

This link is not available

All your videos on agile are awesome. I had been struggling to understand agile, watched a few videos and read a few blogs, but nothing was as crisp and efficient as your videos. Finally I have a good understanding of how this works. Thanks a ton!!

@OeLean

3 жыл бұрын

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

This is such a great example. Your way of explaining things really resonates with me. Thank you!

Thank you so much for this short and clear explanation of estimating user stories using story points.

My sincere thanks to you for this professional explanation.

This was a very understandable and succinct explanation. TY.

A great video! Clear and easy to understand

Very concise and useful! Thank you so much!

Simply and beautifully explained. Thank you.

Great explanation, but in the end it's still manpower that management cares about, not effort/complexity. The VP of IT cannot say "the feature is delayed by 13 story points" management wants to know about $ = hours.

Such a great video. Thank you for helping me understand how this works.

Very easy way of teaching, thanks

This is awesome . Loved it.

well explained , yet remains simple

Great overview, thank you!

So valuable, I love your videos, very good, detailed yet simple explanation. Only question is, if product owner asks when can a certain task/user story be ready ? How do we use estimation to respond to them?

Such great examples, thank you!

Excellent video

very nicely presented

You are awesome ,explained so beautifully , God bless you. 😀

Great explanation... I have a one query I hope you can clarify.My question is what are the points should consider while giving story points as a tester

Nice explanation thanks

Excellent!

good and simple

Very clean explanation, I'm glad that I understood concept well, but concentrate on slang... Some of the world's unble to understand... Just use basic pronunciation... Keep it up... Guys

Your all videos are really interesting

@kamal-hg5jg

3 жыл бұрын

I always love it. It’s analytical

please make a video on -" how will you estimate a story if you are very much uncertain about a story what it does and how complex it will be in future?"

It was great. Thx

Thank you so much ! It was very helpful to me :)

great!

Relative estimation creates two problem in my opinion. Firstly it is really difficult to create a forward looking plan if we don’t have absolute value of each task and secondly if you have third party supplier then it will be difficult to understand where supplier resources spending time.

Thank you

thank u for ur effort, is it logic to mix using relative and absolute estimation in the same project?

👍👍❤

Nagustohan ko ang ,story point mo.

Great video! Why is there a value in, for instance, a tester giving a story point estimation to a complex development task? wouldn’t that tester be in capable of adding true input to the fields of complexity, uncertainty, or amount, if they know nothing about the task at hand Besides how it works and what it should look like in the end?

@InfoLunix

2 жыл бұрын

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.

I love ur explanation, but imagine implementing scrum on a new team it's hard to estimate tasks for the first sprints is there any hint ?

I like the video

4:10 took me out el oh el....great video!

Nice explanation about the story points, one quick query here, Story estimation is performed in story planning ceremony or refinement?

@OeLean

2 жыл бұрын

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

Best video yet after watching 6.

How to handle such situation or scenario where team members are consistently estimating user stories not correctly. Let's take an example there are 1 user story which are simple can be done in 2-5 hrs but still team members are estimating it for say 2 days or so by saying buffer time in that we have experience members as well. How to approach as a SM also how to handle PO and other stakeholders in such case if it is consistently happening for few sprints.

@OeLean

3 жыл бұрын

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

@user-cu4bk2gm6q

2 жыл бұрын

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.

@ajibolaibrahim4425

9 ай бұрын

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

If it's 13 Story points, it is recommended to break it up into smaller user stories, isn't fvaf right ?

@OeLean

3 жыл бұрын

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 :)

@reubenstephen1721

3 жыл бұрын

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.

@OeLean

3 жыл бұрын

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

Rather than using story points to estimate, consider COSMIC, which has been shown to more uniformly correlate with effort and which you could even use as a framework for adding items to your backlog. I've created a somewhat fun, and somewhat polished relatively quick introduction: kzread.info/dash/bejne/enlq19Nml8i4Z6Q.html

There is no tester roles in scrum !!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

T

Why do you guys always use heavily accented commentary?

Excellent !