I’ve stopped asking developers to estimate tasks (You should too)
ฝัง
- เผยแพร่เมื่อ 29 ม.ค. 2024
- In this video, I share why I've decided to stop asking developers to estimate tasks and why you should consider doing the same. By focusing on collaboration, flexibility, and continuous communication, we can create a more efficient and productive work environment. Watch to learn more about the benefits of this approach and how it can positively impact your development process. Say goodbye to the stress of estimates and hello to a more agile way of working!
👇🏼 HOW CAN I HELP YOU?
✅ Get promoted to Senior IT Project Manager, without juggling an unmanageable workload
itpmschool.com/go/plan
✅ Become a Senior IT Project Manager in 45 days
itpmschool.com/go/career-acce...
====================
MENTIONED IN THIS VIDEO
====================
• Project Management Tut...
Dmytro Nizhebetskyi is a participant in the Amazon Services LLC Associates Program, an affiliate advertising program designed to provide a means for sites to earn advertising fees by advertising and linking to amazon.com.
✅ Get promoted to Senior IT Project Manager, without juggling an unmanageable workload
itpmschool.com/go/plan
that was great comment, it's best that the team works to agree what they believe is fair. the reason is that if you want your pay check to turn up on a day you agree, you want to make sure the company doesn't say "you should have agreed the requirement we pay you"
Yes, it's always best to empower the team to provide the estimates. Then, they'll have a buy-in in all project decisions.
Hate such situations when clients or even internal stakeholders for internal project are asking: "So, this will be done?" and you can not answer, because your IT team is not giving you proper estimates. Used to work with both approaches - strong estimation of each task and gutfeeling of dev's team like "yeah, we will be able to do it in next month". Funny or not, but both actually worked.
When you have strong process of estimation, involving whole team looking at proper requirements - great. It takes a lot of time, but gives you better understanding. However, if the team is experienced enough, even quick chat about some feature idea can give you rough estimation, which you just multiply by (put here figure from you experience with current team) , then add 10% more as buffer and then give some promises.
Thanks for the content, Dmitro!
Thanks for sharing your insights. Totally agree.
Different teams and situations call for different approaches.
So, this one is default for me.
And the idea is that at some point the team can follow the process themselves.
I would ask David: how can I help you with these current estimations? What info do you need from my side in order for you to proceed?
And then going further into details...but to some point of course.
This is how I do it with my co-workers on the projects, although I'm working in Automatics Industry.
"How can I help you?" is a powerful question.
And in this case, David said he needs design from the UI team. But we can't wait for those designs.
We need an approach to convince David that it's safe to provide preliminary estimates.
But overall, you approach is sound as well.
Thanks for participation!
I would ask why after what I have promised to the developer he don't want to give estimate. In case this kind of tasks he has never done in his life, I would ask some dev to help who has similar experience to estimate. Or maybe the reason is that they're some additional clarifications I could provide quickly enough that would help to dev give an estimate. Also would look in history of projects in the company and see if same tasks were previously done and how much did they take.
Thanks for participation, Anna. You questions are spot on. Great mindset and approach.
It's a very common issue. thanks for covering👍
Thanks for watching, Kasmine! Glad it was helpful.
That's a great video!
Glad you enjoyed it, Alex!
Nice job!!!
Thanks! Glad you found it useful.