5 ms·
AD: I call BS... There is a fundamental difference between functional requirements and the tasks required to implement them. Note there are NO examples in that
by endiangroup 6y ago
AD: I call BS... There is a fundamental difference between functional requirements and the tasks required to implement them. Note there are NO examples in that article, and I bet you it's because it was hard to think of context free tasks... because context is everything and thats what your functional requirements provide your tasks.
User stories capture functional requirements:
```
As a restaurant guest
I want to consume food
Because I am hungry
Scenario: Guest is provided with menu when they are sat at their table
Given there is a free table
When I am sat at my table
Then I should be given a menu
```
This is BDD style, I don't really care what you think of BDD it covers what I need to make the point... First of all context is king, there should be NO scenarios here that do not satisfy the guest being hungry, thats scope creep. Equally there is NOTHING here about HOW you implement this, it does not mention who gives the menu, what the menu contains, how it looks or anything about the rest of the restaurant. Why is that the case? Because we are at a level of abstraction that is talking about delivering value, not about the quality of what we deliver. You can only deliver value to users so we can only talk about users and their experiences. Now as for tasks, they are derived from these functional requirements, they connect what currently IS to what needs to be, e.g. if we currently give guests a menu when they enter the door, thats what IS, now we need to go about creating a task to change that to when the guest sits down, thats the task and it is a poignant task because it's derived from our functional requirements, there is no room for scope creep here.
Please do not write context free tasks, you'll run yourself into the ground in scope creep, because you're detached from what matters. That's why user stories are important... but most people don't write user stories correctly, they treat them like a task template and forget the value delivering aspect and all the context that goes with it.
- hinkley 6y ago> There is a fundamental difference between functional requirements and the tasks required to implement them. Tasks that don't honor the 'why' of the work can make someone look productive when they are not (or indeed, when they are being destructive). I see the same thing in 5 Why's analysis. There's always one faction that wants to come up with an inactionable 5th Why. It is remarkably easy to steer such discussions to whatever agenda you are pushing.
- endiangroup 6y agoAD: I completely agree, value > ego's.
- redler 6y agoAs has been said elsewhere, beware that zealot on your team who keeps on with the whys until the user gives up and screams, in tears, “because I don’t want to die alone!”
- endiangroup 6y agoI think the insight here is that if you're asking your user you aren't going to get the answers you want. This is why survey writing is so hard, because people can't just explain themselves on the spot.
- teachingassist 6y agoI don't mean to pick on your example... but it's absolutely not true that I go to a restaurant because I'm hungry. There are other ways I can and would sate my hunger if that was my genuine motivation. For me to go to a restaurant, it does have to provide food, but that is not sufficient, since I can get cheaper/more convenient food elsewhere. A restaurant has to offer something other than just food, or I won't go at all.
- endiangroup 6y agoAD: Sorry you got bogged down in the details. Would you like me to put together a more thorough example? That one I wrote in 2 minutes. To clarify I picked /some/ value for the restaurant guest, but we could negotiate what the /true/ value is. I go to restaurants when I'm hungry and I'm sure others do, but you're right there are other reasons why you might go, but that doesn't detract from my point being made.
- teachingassist 6y agoI commented this because I find it does relate to your point - in my view, you have identified a false motivation/incorrect user story. By my understanding, this is exactly what the parent article is identifying as potentially damaging. Quote from the article: "User stories are time-consuming to write and read and can silo engineers into a mechanical role where they code to the issue requirements instead of thinking about the user experience holistically at the product level."
- endiangroup 6y agoSo let's negotiate the true value? How else are you going to know if you're delivering technology thats useful? You said there are other reasons, what are those reason? I've gone to restaurants to meet friends... and ultimately we all eat to satisfy our hunger. My point is that tasks are derived from functional requirements, they aren't context free, and if you make them context free then we're just doing what ever we want? To analogise, why do you have relationships in databases and indexes? An index is a flat map to speed up lookups on known queries, you don't get at the meat of your query in the index, the meat of what you want is in the row and it's relationships. You have an object graph for a reason, and yeah it was the hard part, but it's what makes a model useful. ... and to counter the quote... What's the point of your users experience if it's not to get them to where they are deriving value?
- endiangroup 6y agoAD: So this has been downvoted without refute... any takers? Or is it just bots...