The author's approach is to favour descriptive todo over the user story phrased like 'As a human, I need to do xx in order to have yy', which is weird to read and not very straightforward.
User stories are a roundabout way to describe a todo.
User stories is the wrong kind of abstraction for most tasks.
In the end we still need to extract actionable tasks out of the stories.
He continues to give some background for user stories
I think user stories came to be ~20 years ago when engineers and users operated in very low context environment. Nether engineers or users really knew how to describe software. Everything was new. User stories were a language to describe functionality.
Today, most good engineering teams operated in high context environments, having a lot of knowledge of the product, market, users and existing solutions and patterns. Both engineers and users also have experience using other products and can visualise solutions.
So they strive to break down stories into tasks which should be actionable and have a deliverable (e.g code, design or docs).
Others commented which I agree
In my experience a task and a user story are two different things. Tasks is for when you know what to build, user stories are when you do not know what to build. User stories ensures you cover the underlying user need, regardless of implementation.
it is about aligning with the user, “do we understand the problem?”. Tasks is step 2
My take on this is also they are not conflicting with each other, in case of high context, there are more alignments and understanding about the products and problems it is trying to solve across different teams, it's feasible for them to directly work on implementing tasks, while this is not universal for all the companies and teams.
6thfdwp
commented
3 years ago
The author's approach is to favour descriptive
todoover the user story phrased like 'As a human, I need to do xx in order to have yy', which is weird to read and not very straightforward.He continues to give some background for user stories
So they strive to break down stories into tasks which should be actionable and have a deliverable (e.g code, design or docs).
Others commented which I agree
My take on this is also they are not conflicting with each other, in case of high context, there are more alignments and understanding about the products and problems it is trying to solve across different teams, it's feasible for them to directly work on implementing tasks, while this is not universal for all the companies and teams.