Software Manager, Agile Aficionado, Tech Dabbler, and Public Speaker. A lifelong learner, the prospect of something new and coffee are what get me up in the morning.
People and Teams estimate LARGE tasks, there is a lot of uncertainty as there are unknowns in big things that are not fully detailed. When you break down large items to MEDIUM ones you get close to the work you are doing, so you could still estimate but you haven't delved down enough. What needs to be down is break the LARGE items down to MEDIUM blocks of work that can be separated out, and then make SMALL tasks that define the work at a human level. SMALL can be given a time, or if you like an estimate that is Measurable (like in that SMART thing) and can be referred back to as you work. But you can add up all those SMALL parts that have time associated and then get an idea of the LARGE.
The thing is you have time to break it down and get an idea of how long those SMALL items will take, when you are given a LARGE and moments to say a time then its either "when are you telling me to have it done?" or "would you like me to break it down and give you a realistic idea of how long it will take?"
I agree. Sounds exactly like a work breakdown structure which is also covered in Demystifying the Black Art. Few people working in software are aware of even the concept in my experience, let alone actually practice it.
At one job, I put a work breakdown structure together for a task and emailed it to my manager and project manager. It gave an estimate ranging between a best and worst case scenario. Both times were longer than all other proposed estimates. They nodded politely and ignored it until after the project was complete and it had taken a time hitting about the mid-point of the estimated range.
Then they came back to me and said "Can you make one of these for the next project?"
Software Manager, Agile Aficionado, Tech Dabbler, and Public Speaker. A lifelong learner, the prospect of something new and coffee are what get me up in the morning.
It's just something I have done in many jobs for years, working in Agile environments we needed small tasks and over time our ability to determine how long those small tasks can take got better. Honestly not hard to do, and to me seemed rather obvious.
For further actions, you may consider blocking this person and/or reporting abuse
We're a place where coders share, stay up-to-date and grow their careers.
People and Teams estimate LARGE tasks, there is a lot of uncertainty as there are unknowns in big things that are not fully detailed. When you break down large items to MEDIUM ones you get close to the work you are doing, so you could still estimate but you haven't delved down enough. What needs to be down is break the LARGE items down to MEDIUM blocks of work that can be separated out, and then make SMALL tasks that define the work at a human level. SMALL can be given a time, or if you like an estimate that is Measurable (like in that SMART thing) and can be referred back to as you work. But you can add up all those SMALL parts that have time associated and then get an idea of the LARGE.
The thing is you have time to break it down and get an idea of how long those SMALL items will take, when you are given a LARGE and moments to say a time then its either "when are you telling me to have it done?" or "would you like me to break it down and give you a realistic idea of how long it will take?"
I agree. Sounds exactly like a work breakdown structure which is also covered in Demystifying the Black Art. Few people working in software are aware of even the concept in my experience, let alone actually practice it.
At one job, I put a work breakdown structure together for a task and emailed it to my manager and project manager. It gave an estimate ranging between a best and worst case scenario. Both times were longer than all other proposed estimates. They nodded politely and ignored it until after the project was complete and it had taken a time hitting about the mid-point of the estimated range.
Then they came back to me and said "Can you make one of these for the next project?"
It's just something I have done in many jobs for years, working in Agile environments we needed small tasks and over time our ability to determine how long those small tasks can take got better. Honestly not hard to do, and to me seemed rather obvious.