With a team this small, and relatively few cross-team dependencies, I’m not convinced of the ROI of story level estimates, as in this case we expect our team to be thorough with understanding the requirements.
I tend to think “what CAN’T I do without these estimates?” In this case, I’m can’t think of much. Presumably, all the training work is a fast follow and the go-to-market team is ready to go within a matter of weeks after dev complete, as one would expect shipping this to be their #1 priority. They should just be waiting for the go-ahead, so ongoing status reports will deliver a much better value than pre-dev estimates, which lead to false expectations.
Rather than estimates, setting timeboxes to get _something_ useable in front of customers is likely a better bet. Setting a 3-week goal of having a prototype in users’ hands would push the team to pare down to only necessary features, and then the team can slip that date if they deem it necessary to round out the MVP. It can also give the GTM team some stuff to build collateral templates and sales narratives around.
If estimates are needed, just estimate aggregate chunks of work. Finding a logical way to break down work over time is not always the easiest, but assigning dev estimates to 3–4 chunks of work, rather than two dozen user stories, is likely a better measure of progress towards value anyway.
I wondering if the 4w solution doesn’t deliver the expected value, is it throwaway work? Or does it ultimately build toward the more complete/complex solution? If there’s substantial product uncertainty, it’s probably smart to get something testable asap.
at 4w, thats 4 x (230k + 95k + 20k) for dev to wrap (1.3m), then maybe another 2 weeks to mobilize GTM and bugfix (460k + some % of dev team’s time)… between lost business and expenses, it’s still <$2m. beyond that, who knows? it starts to get expensive fast.