No points do not equate to time. Agile is not about time estimation it is about feature estimation.

I see a lot of "good explanation". For me it sounds anti pattern in Agile when the moment you used "time" in the video. Estimation is indeed a relative way of measuring something. Only in Agile, it's not about time, but effort and difficulty. It's easier to have this time in mind, but the whole goal of agile is to actually know if we are improving. Time doesn't actually tells is if we are improving. in a lot of cases, a relative very small ticket could take longer to work in because it's just takes more time. In my opinion, the moment we use the word "time" , there is a big chance you lost the team. If you have really mature teams, then maybe it will work, but most of the people who watch this video is to actually gain knowledge. So there can be improvement in the way estimating is done now. When you have teams who aren't yet in the maturity we want, this will cause people having the mindset on even if we explain it, the thought will result in time. And getting out of this anti pattern is very hard. It's a little the same with using story points + numbers. Especially when the mindset is still based on time, people want to compare time with the points. In the end the thought process will still end up in: "3 SP for a ticket that takes more or less 3 days". As before, with mature teams, this wouldn't be a problem, but for people who start or don't have the agile mindset and watch this video will have the understanding that time is still the way to estimate, even if it's relative.

To sophisticated. I wouldn't use this method in the real world.

Dude seriously, speak up.

Very nice explanation. I am trying to make videos on Agile, can you please tell me what software you used to make this illustration in the video

This is art. Thanks!

Best and most Bang for the bucks description for estimation.

For a completely different way of sizing, but one which is widely accepted, try COSMIC instead: kzbin.info/www/bejne/fnaZpqRjnMqFbaM

Quick correction: there is no project manager in Agile processes. Just the PO, the scrum Master and the development team.

This is very good stuff. This should be taught in grade school.

Super polished, great job. I hope to have come close with my intro to COSMIC, which has been shown to more uniformly correlate with effort than story points 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: kzbin.info/www/bejne/fnaZpqRjnMqFbaM

Very clear and concise. To the point

Fantastically explained.

Great but wish you wouldn't talk so slow. 😴

Nice to see some new faces, and new furniture

is there a chance you can upload reprocess kind of version for this video? its really hard to hear the voice. I would rather just rely on other online resources rather than sticking my life for this kind of video. Please make the video much better bye...

Nice and clear explanation, thanks!

Thank you so much. Great video

First of all customers buy the goals achieved from use not the physical aspects; secondly this approach will underestimate important critieria such as 'decoration and carpets'. For goodness sake, are you going to say build the roof and forget the carpets! In which case I am not interested in the offer thanks very much. I am sure this is useful for manufacturing but when you put a human in the loop you are dealing with systems that are different. Critically, customers are not hyper reductionists that can give points to a wall (unless you shove a questionnaire under their nose): this also is a functional view of value and omits that customers want goal achievement and interest from the outcome, it seems that only robots and engineers like hyper reductionism. Normal people couldnt care less for this. High value from a building without carpets and decoration LOL are you an engineer?

Thank you! Clear, concise, good value ... appreciated!

The only student here

Excellent and well paced explanation. Thanks!

Very well explained, this was the video i was looking for.....

Very nice video. What software do you use to create these videos?

Absolutely superb video! What an awesome explanation! Thank you!!

Best video on the topic, very clear. Thank you!!!

Tyvm. Found this vid on Latium Alpha! Go LATX! @Luculenus

SpardaMBG on #LATX watched! :)

story points are a measure of relative effort...not time

I really liked the idea of BFTB!! One quick question though: Since you measuring in BFTB and also measuring the first interaction against the items on that sprint, how can you quantify individual completion during that cycle? Meaning, how can you produce the Burndown chart if the measure is not put in days... just got that one confusion on my mind. But again, excelent way to measure value and time together to prioritize with both IT and business side.

Very clear, but hard to hear and very slow

That was truly awesome. I had difficulty understanding story points and used ideal hours. Your video cleared it up for me. Thanks. Great work Mr. Griffiths.

I really love this presentation, both what it shows, as well as the presentation method. I am already looking forward to having a bunch of stakeholders playing value poker with me - I believe they will be hestitant but absolutely understand what it is good for after having done it.

Is this the only form of Scaled Agile or are there other forms? Thank you Process Geekoid, SFC, SMC, LSSGB, PMP

Really enjoyed this video and love the Fibonacci sequence. Makes so much sense.

Wait! Is it me only or somebody can explain how and why we are dividing 55 by 21? Story points (55) are estimated by the devs, as Mr. David put puts it, OK , I get it. Now, he is bring the customer into the sequence who would be 'Valuing' the WHAT? The Story points? @ minute 5:15, he flips the Story points as Value points and , where does he get Story point 21 to divide 55? What's the FORMULA ?

Hi, Do you happen to have a reference explaining why using Fibonacci sequence helps?

I noticed that when determining story points, the values were 0-55. However, when determining value points, the values were 0-144. I know these values are decided by two different groups of people, but let's say I'm determining both values for a self project. Do you get a more accurate BFTB value by making your value point scale larger than your story point scale? Or should they be the same?

i would like to say thanks for this nice video.

very good explanation

Well explained 👏🏽👏🏽👏🏽

Very nice video

Exactly what I was looking for.... a simple and easy explanation of AGILE.

If you've enjoyed this video, then you might like to know that my wife Dawn and I have extended it into a complete video course on agile development for O'Reilly Media called "The Agile Sketchpad". You can find more details, see a preview and buy the course here: shop.oreilly.com/product/0636920049012.do

Just wondering, with what kind of software do you create such presentations?

You are superb! This is what i was looking for... can you please also let me know if we can follow the same process in JIRA as well.

Thanks this was very useful

Found it very useful. Very descriptive and explained so well.

excellent presentation

Really excellent film, well done for making.