These are EASILY the best developer or even Professional development videos on RU-vid. I’d say I wish more people put things together this well, but really I’d rather you get all the views and everyone else just stop making videos... would make the searching WAY easier.
Love this video, thanks for sharing! Can you tell me where you found this information? I want to learn more on his time working on curriculum, thanks in advance!
Hi @gary. This is a video I really enjoyed. In my current team, we estimate using story points just because, as you said, estimating in terms of time is something extremely inaccurate. Using story points, however, doesn't solve the problem but just move the attention to a different question: how complex this task is? I believe, the only reasonable solution is splitting the problem is really small tasks individually achievable in 1 or max 2 days. Doing this way, you can just calculate time based on the number of tickets/resources you have in your team. Thanks
You're right: Story Points is one of the ways to get to better estimates. I'm also a fan of the 1-2 day tasks - I'm curious, is your team a Kanban team?
Sort of. We're moving towards that direction but we're still releasing multiple features together. So we still have a "Ready to deploy" column in between "In progress" and "Done" .
We have both a physical board used during stand-ups and a virtual board in where adding a more technical description of the tasks. Good idea to use a larger card, however, everything we accumulate under the ready to deploy column is released together so, I guess, it's the same as having a big release card.
Love the video and looking forward to the follow up one Gary! Your timing question creates a healthy tension that's needed to facilitate peak performance. The key is a both / and collaborative perspective over an adversarial either / or one.
Development That Pays - Absolutely! Without timelines and estimates things tend to drag on longer than necessary costing too much money. If we get to restrictive though with hard, non flexible deadlines they can cause bad work. Ideally, an ebb and flow with two way communication that adapts to the situation nets some of the soundest results. This means the developer considers not only their own perspective, but also the product owner's and vice versa.
"Without timelines and estimates things tend to drag on longer than necessary[...]" - I'm not sure that applies to an individual (developer) task, but it can apply elsewhere - such as a Sprint.
Optimism effect- so we end up padding the estimate. But then we suffer from Student Syndrome. We procrastinate and start a task later than we should because we feel positive about it. And we end up losing the benefit of the padding. So we are late anyways. lol
You're right: knowing that we tend to be optimistic, it's only natural to "pad". I didn't know "student syndrome" was a thing; I knew I was guilty of it... but I didn't know I could look it up on Wikipedia!
My problem with estimating, is that stakeholders (often paying customer) thinks that the estimate = maximum time they have to pay for. We need a new word for them to understand. Ballpark?
I feel I am seeing videos in this channel but not coming to any conclusion, just moving from one video to another knowing about things that wont work. The presentation is soo good but the videos leave me with the same emptiness which I had before watching the video. Although respect you for your experience, effort and dedication.
Great vid as they all are :-) I am a developer working on freelance on fixed-price assignments. I tend to have an optimistic estimate which I then multiply by 3. Seems to work :-)
If the thing itself is a learning process in doing something that hasn't been done before then isn't the correct answer to the question of "How long will it take?" basically just "I'm working on figuring that out by doing it. I'll tell you how long it took after I'm done with it." ?
Please just hint me in the right direction 🙈 i have a Job Interview tomorrow afternoon I would looove to have a good answer to that (or at least a clue I can work with🙏😊🙈)
Think it's the case that "Agile" is aware of this problem (the Planning fallacy)... and has a few "tactics" to combat it: (1) we estimate as a group - think Planning Poker; (2) we don't estimate "when will it be finished". We even try not to think about duration. Instead, we have notions of "size"/ complexity - think Story Points. Is that helpful?
