I think estimates of effort required, estimates of timeline, and commitments to timeline (deadlines) are three different things with only loose relationships that are far too often conflated - to significant pain. I'm trying to play with this a bit in my personal process (and talking to my team about it) but don't really have any hard results yet.
Yes, Estimate Software Projects
21–30 of 96 posts
Re: Yes, Estimate Software Projects
#22> Have you noticed how Apple ships most of their big bang projects at WWDC, a date they commit to far ahead? Is this why so many Apple products have been increasingly low-quality? Instead of committing to quality, they commit to arbitrary dates because some bean counter decides quarterly profits needed to be higher. I don’t disagree that we should estimate, but I think we should be realistic about just how difficult…
> Is this why so many Apple products have been increasingly low-quality? Potentially, however the author makes another mistake: assuming that Apple, Google or Facebook actually know what they're launching at the time they set the date. I've heard many stories of "big bang projects" being pulled at the last minute.
I would actually believe it to be the opposite. If you know you will be attending a big event, and you have a project that seems feature complete. It might make sense to hold out releasing it for a couple of months until the conference. If you're a big enough enterprise it seems likely you will always have something finishing up.
Re: Yes, Estimate Software Projects
#23I hate deadlines simply because organizations I have worked in tend to assign them indiscriminately without any reference to reality. Upper management wants to set a deadline for a big project? Then they need to be prepared to commit and compromise. While developers continuously deliver, product owners and stakeholders need to continuously review, reevaluate, and adapt. In Thinking Fast and Slow, Daniel Kahneman offe…
In many ways the story points are outside view. You estimate complexity, then you look at how long it took to do stories of simular complexity before.
Re: Yes, Estimate Software Projects
#24One thing he misses out is that story points, eventually get turned into estimates using velocity. They are estimates, just a different approach based on past history.
Re: Yes, Estimate Software Projects
#25My current employer switched from SCRUM to KANBAN. We're broken up into person squads. Epics are created by product by engineers are involved in kickoff and story breakdown. We use KANBAN cycle times to estimate delivery dates. For example, my squad completes 85% of stories in 5 days. Given that, the number of stories in the epic, and number of engineers, it's easy math to calculate an approximate completion date. It…
> For example, my squad completes 85% of stories in 5 days. Given that, the number of stories in the epic, and number of engineers, it's easy math to calculate an approximate completion date.
Until it turns out that the remaining 15% takes half of the total time. In my experience, estimating about 80-90% of a project accurately isn't that difficult; it's the other 10-20% that can end up taking considerably longer than you expected and throwing off the entire estimate.
Re: Yes, Estimate Software Projects
#26This is such an important topic and missing skill in the tech workplace. It's impossible to prioritize work without estimating the cost & value of projects, and teams that don't prioritize are always overworked, playing catchup and are unhappy. What the author says about 'we shipped different functionality to what we planned' is really important too -- beginning managers aren't willing to have this conversation but s…
> make time to identify & resolve unknowns before committing to features / timelines.
I find it difficult to identify unknowns before I actually start working on it. Personally it makes sense to just give it a go as estimating it correctly may be as time consuming as completing it. Especially true for one off feature or bugs in large codebase.
Re: Yes, Estimate Software Projects
#27I’ve worked at a company that took this too far and product managers used the release cycle clock to game the system by launching features that were not even half-baked but just outright didn’t work but since they hit their official target of launching managed they to get promoted and the next person in line is responsible for fixing the problem. Instead of using the release cycle as a way to focus the product process it became a goal in itself. But this author seems to work with really top class people so maybe that level of stupidity in using the metric as the goal in itself is less of an issue in those circles
Re: Yes, Estimate Software Projects
#28The problem is is that most businesses refuse to negotiate on scope once deadlines have been agreed.
Getting a manger who is willing to do that is great.
Re: Yes, Estimate Software Projects
#29This whole article rubs me the wrong way. It's holding up their failures in software planning & management as best practices. And while they are normal practices in the industry it doesn't mean they are good practices.
They start off by talking about how important estimates are, and how they always meet their estimates across many types of projects/deadlines.
Then they admit that "delays are normal and expected" - so you're not meeting your estimates.
Then they admit that "they delivered something different" - so you're not building what you promised.
Then they admit that "they "spent too much time on non-deliverables" - so you're spending the last months pre-deadline working hard to catch up on something that is already behind schedule and doesn't match the original spec.
But it's all OK because they kept the stakeholders updated with frequent communication and conversations...basically the same result as if they had not estimated a date but instead focused on iterative delivery and constant feedback with the customer. Sound familiar?
> Suddenly, the whole team became focused, distractions were all gone, and we moved at a faster pace than I've ever felt the team do so.
Why was the team not focused & distraction free from the start?
How could you achieve this efficiency without needing a deadline hanging over your heads?
Re: Yes, Estimate Software Projects
#30> Have you noticed how Apple ships most of their big bang projects at WWDC, a date they commit to far ahead? Is this why so many Apple products have been increasingly low-quality? Instead of committing to quality, they commit to arbitrary dates because some bean counter decides quarterly profits needed to be higher. I don’t disagree that we should estimate, but I think we should be realistic about just how difficult…
> Is this why so many Apple products have been increasingly low-quality? Potentially, however the author makes another mistake: assuming that Apple, Google or Facebook actually know what they're launching at the time they set the date. I've heard many stories of "big bang projects" being pulled at the last minute.
Pretty much every big company has big conferences that they "need" to announce appropriate stuff at. In my experience, you end up with a combination of changing what you announce, announcing what you planned but without immediate availability (especially if it doesn't obsolete a current product), dropping features, and prioritizing work on what you really want/need to announce.
Historically, the software industry has been more fluid with its announcement cadence that, say, the auto industry. But companies still have big events at which they really want to make high visibility announcements.