> I think you need better software developers or a better system if for a person in your team, fluent with the object model and the systems downstream, takes 3 weeks to import data from an excel sheet honestly...

Ah yes, nothing is better than questioning the estimate of a hypothetical user story that lacks any and all detail about the existing environment.

Like, maybe 3 weeks is quick? Maybe there is all kinds of shit you didn't even think of at all? Maybe the excel sheet has all kinds of weird non-canonical data that makes it very hard to reliably import? Maybe nobody on the team ever touched an excel spreadsheet in their life, let alone imported one?

Like.... seriously. Are you one of those people who always go "you people are idiots, I can do task XYZ in 1/3 of the time all you estimated"?

When an engineer tells you something will take 3 weeks, you listen to them.

If it takes three weeks to import an excel sheet either you change your system or your engineers. tertium non datur.

All the most profitable companies I've ever worked for, which also have had the smartest engineers I've worked with, would take longer than three weeks to build an Excel sheet import system. An engineer thinking it can be done correctly in three weeks, without bothering to know all the requirements, would be a red flag for all except the most junior of positions.

A junior engineer thinks speed is the most important metric.

In case it helps you to see OPs point, please contact this person for a spreadsheet to import.

https://news.ycombinator.com/item?id=18608294

It needs half a terabyte of RAM to open.

I remember all of the "I could write Twitter in a weekend" posts on blog years ago. Your comment reminded me of that, sadly.

What if importing an excel sheet actually means importing an excel sheet, formulas and all, instead of a CSV? Commenting on a hypothetical estimate on a hypothetical story isn't adding much value...

The task isn't "import data from a spreadsheet", it's implement a feature that allows users to import data from their spreadsheets.

Ironically, this is a pretty good example of why tickets end up the way they do in jira - overly specific and concrete. Even the hypothetical situation is getting misinterpreted.

I would still love it if user stories were implemented as the "why" (or even "what") instead of "how", though.

Stories should absolutely be a "what" and a "why." Stories are property of the product owner and they are ideally writing them. The "how" is up to the team or implementor. If your product owner is specifying "how," that just sounds wrong. Maybe they could suggest how if they are a domain expert.

I.e. requirements.

so, basically just paste data in from clipboard