6 ms·
If it can't be done upfront it's largely useless for business folks ("so you have an estimate but can't translate it into time? so why do it? go away" :). If i
by jakubp 6y ago
If it can't be done upfront it's largely useless for business folks ("so you have an estimate but can't translate it into time? so why do it? go away" :).
If it assumes remaining work is equivalent in time to done work (notion of velocity), it's (in my view) very optimistic. People learn the nature of the beast as time progresses. Collective learning happens slowly. A lot of important work is usually only discovered and planned in the second half of the actual (not original) timeline. A lot of important stakeholders are naturally only introduced into projects close to its finalization, which creates a flurry of new activity and discoveries. This makes projects late.
But where that real halftime is - most people I worked with rarely know. I was no better, I also rarely knew.
The only way to manage this I found was the basic rule: build, demo, decide what to do next. Don't get attached to original backlog and grand plans for the future. It won't work that way. Just build and make it work, launch ASAP, get decisions on a ~weekly basis done. Ignore long term planning. It's not helpful.
Sadly, few business folks want that of course :)
- tootie 6y agoFor one, it doesn't assume pace is consistent. Tracking velocity is part of the game too and it can vary with capacity, talent and maturity. Secondly, telling business that we can't estimate accurately is more useful than saying we can estimate accurately and being wrong (which is guaranteed). It's a tough sell but it's necessary.
- jakubp 6y agoAgree on the second point. I tried to convince some managers and sales guys to stop giving estimates at all and build trust otherwise, didn't work :) As for consistent, my point was if you have 100 SP in backlog, delivered 50, then I contend you are not in the mid-point of the project. This is a dangerous assumption. You don't know where you are in my experience.
- tootie 6y agoIt is if you're following agile principles. By the time you've completed a few stories you should be delivering every feature at production quality with all the automation pipeline and deployments ready. The question from that point is always did we build enough features for a launch.
- jonpurdy 6y agoI agree that building and demoing something small is key. The larger and more complex a project will be, the harder it is to estimate. I’ve been trying to distill this into a framework that is accessible to both development and business folks [0]. I've used it a few times and it has resulted in a few projects getting cancelled due to a massive difference in initially expected cost and post-analysis expected cost. 0 - It's basically just Scrum oriented towards providing upfront estimates. https://jonpurdy.com/pm-framework/how-to-quickly-plan-and-estimate-an-mvp/ https://jonpurdy.com/pm-framework/how-to-quickly-plan-and-es...
- mbesto 6y agoI'm gonna play the devil's advocate here. > Sadly, few business folks want that of course :) Business folks want this usually because it's their money you're playing with. > Ignore long term planning. It's not helpful. So, no don't tell people to ignore long term planning otherwise people who give you money are going to stop giving you money to "build, demo and decide". Unless you're on your own dime (e.g. you pay yourself or are self funded), then I wouldn't take this advice.