What is an MVP?
It took 12 weeks to ship an MVP I thought would take 3
91–100 of 221 posts
Re: It took 12 weeks to ship an MVP I thought would take 3
#92Developer to self: "It'll take me about a week" Developer to development lead: "It'll take about two weeks" Development lead to project manager: "It'll take about 4 weeks" Project manager to self: "It'll take double that plus 2 weeks" Project manager to management: "It'll take 12 weeks" Management to client: "It'll take 8 weeks" Actual time taken: 16 weeks.
Isn't it common for sales people to intentionally give a longer time frame than management specifies? I believe they try to buffer 20%+ rounding, unless there is an exact public release date. Though, I'm not in sales so I could be completely wrong.
In the consulting world there is the rule of three, where you multiply everything by three, not just how long it will take.
Re: It took 12 weeks to ship an MVP I thought would take 3
#93OP here - this is a sidebar but the HN hug was making the page load really slowly (~10s for me) even though the blog part of the site is cached. Anyway, because I'm using kubernetes all it took to fix it was bumping the nodes in my cluster, 4x the replicas, kubectl apply and it's snappy again! All done in about a minute. What an awesome tool kubernetes is.
Please take this comment in good faith because I'm genuinely curious: why do you need a kube managed cluster of N nodes (an now 4x N) to host a static blog? I wonder what works goes on under the hood that this needs such scale.
Re: It took 12 weeks to ship an MVP I thought would take 3
#94What is an MVP?
Minimum viable product.
Re: It took 12 weeks to ship an MVP I thought would take 3
#95Earlier quoted context omitted.
>> We usually anticipate 4x. All software estimation boils down to the long established scientific methodology: (2 X what the last person said) optionally plus 2 weeks
Years ago I worked with a developer who had a different methodology: 2x, then bump the unit of measure. Thus, 1 day -> 2 weeks; 2 weeks -> 4 months. It's been remarkably accurate over the past couple of decades.
Mine is to multiply by five. It’s pretty accurate.
Re: It took 12 weeks to ship an MVP I thought would take 3
#96As my colleague says: The time where you know the least about a project is when you start. This is also the time when your estimates are likely to be the worst.
When can you say with fairly good certainty how much longer it's likely to take? In my experience it's about 1/3 the way through the project. I'll give you my reasoning behind this number.
There is a model of software defect discovery called Littlewood's model. It basically says that the rate of software defect discovery is a random variable. As you discover more defects in the code, the number of defects that are left to discover diminish. Assuming you put in a constant effort to discover defects, your rate of discovery decreases. You can estimate the number of defects left in the software, by looking at the decrease in discovery rates over time. There are lots of scholarly articles on Littlewood's model, so I won't go into more detail than that. There are newer models too, but I always found Littewood's "good enough" for my purposes.
It occurred to me that requirement discovery might follow a similar curve. As time goes on and you understand more and more about what you need, the number of things to discover decreases. If you work on your project in a constant manner, the rate at which you discover new requirements will decrease over time. I took data for a number of project and the discovery rate curves were very similar to defect discovery rate curves.
The key is to look at the rate of change of discovery. Once it is tailing off, you can estimate the speed of the drop and get a good idea of how much work you have left to do. Each curve is different depending on a number of factors, but by the time you are about 1/3 the way through the curve, you have enough information to estimate the parameters.
Note: Littlewood's model doesn't actually hit zero, but you can set a threshold that is "close enough to zero". Where you place it will change the 1/3 figure, but I hope what I'm saying is understandable.
Re: It took 12 weeks to ship an MVP I thought would take 3
#97Earlier quoted context omitted.
The trick is to break it down until it’s all trivial. That process takes time itself, but you can estimate that much more easily. I’ve recently found I end up giving an estimate of, say, 2 days to get a solid estimate, and then come away from that with 2-5 weeks of tasks that are no more than a day each. Estimates of a day are pretty accurate (for me). Another approach I had some success with was estimating the 80% l…
I'd extend this by aiming to have each trivial step be a useful result that can be immediately released to market. If you can't make every step useful, try to get as many as possible useful with a minimum number of steps between useful results. Put a hard estimate on the first few trivial steps, but recognise that it's largely guesswork beyond that. If the trivial product can be released and start earning money then…
The problem is that in many business domains, the absolute minimal viable product, or even a customer-worthy demo, is a 6 month long, 10-15 person project. If the market already has complete solutions available, releasing an app which does 5% of what other apps do + 1% that's different is simply not viable, and is likely to help you never get a second look.
Re: It took 12 weeks to ship an MVP I thought would take 3
#98The thing about estimating is that you can't factor in the things you don't know:
- The tool you planned to use has a bug/defect that blocks you.
- The people who said they could give you some information you need, can't.
- You misunderstood or were misled as to the capabilities of a tool you need.
- The parts you need don't actually fit together as planned.
- The documentation you were relying on is wrong.
- A delivery you are relying on won't actually be ready on time.
- A process that's worked every time has an unhandled edge case that you're going to trigger in this project.
- A regression in a software package will block you because you can't use the previous version for other reasons.
The more moving parts there are, the more likely it is that one of the interface points between them will block or delay you in one of these ways, potentially for weeks, maybe even months.
So for any nontrivial project, you should expect a 2x-8x delivery inflation over your "safely padded" estimate. You have a 75% chance that you'll deliver within 2x of your padded estimate if you've made a good estimation, sliding to worse as the number of moving parts increases.
Re: It took 12 weeks to ship an MVP I thought would take 3
#99Earlier quoted context omitted.
>Yet for some reason people still insist that estimating non-trivial software is not only possible, but trivial. It's always maddening to get into debates about this stuff with project managers who believe this nonsense. I know the Fibonacci point scale is supposed to address this by giving PMs something , but I've only ever seen it turn into time-estimates-by-proxy. These days, I only ever give estimates in terms of…
Most maddening thing I've seen is PM translating agile points to man-hours because that's what upper management requests. Same people: you must complete assignments in the estimated time, or else, be prepared to work overtime including weekends. It drives me bonkers.
Quarterly planning is equally frustrating. I don't think we've ever had a quarter where we're on track three sprints in. Something always comes up, we pivot a bit, or our estimates were as uninformative as we all thought they were.
Re: It took 12 weeks to ship an MVP I thought would take 3
#100> Sometimes it takes a conversation with someone else unfamiliar with your work to really question your fundamental principles This is one of my favorite tools for development. I always sketch out an idea (no coding) and then try to describe it to someone with zero CS background before diving into an mvp. The times when I didn't follow this process - well - just as op described while trying to document the cli, I bas…
Fun fact, what you're describing it's called dechunking. https://en.wikipedia.org/wiki/Chunking_(psychology) And ofc, rubber duck debugging too. ^_^