Comments by "" (@ContinuousDelivery) on "USER STORIES Shouldn’t Be TOO BIG" video.

I wouldn't have a "Backend" story, this is an artificial split driven by technical design choices and so exposes those choices at the level of stories, meaning you have allowed implementation detail to leak out into the story - a bad idea, and so you have increased the coupling between the Story and the solution - another bad idea. I would instead find a user story that matters from the perspective of a user, and forces me to implement something not hard coded. In the bookstore example, we could imagine a requirement along the lines of "I'd like to see new books when they are added to the list" or perhaps "I'd like to see what books are left when a book is removed from the list". None of these have to be perfect. The idea here is NOT to do programming by remote control, the idea is to give us the freedom to design good sensible solutions without, 1) being told what those solutions must be and 2) Without the story necessarily forcing us to make any specific technical change, other than WHATEVER is needed to achieve the goal that the user wants. Stories are tools to HELP us develop software, so use the Stories, that should ONLY express user need, to guide your choices in terms of design of the solution, but those solution choices are yours, and it is ok for you to decide when to sensibly make them. So my example wasn't meant to demonstrate me splitting F.E. from B.E., in fact in my example, the story had both F.E. and B.E., represented by the service and the UI in my diagrams. The service with the hard-coded list of books WAS MY B.E.! What I want next is a story that makes me need to do better than simply hard coding a response, if I can't think of one, then maybe I should hard-code the response, because that is simpler!
6
@PatrickMetzdorf My experience has been that it gets easier to make those kinds of changes, once you do express these things in terms of real user need. Implicitly you know this stuff, otherwise why would you want to change BE architecture. So it is about thinking about that "wider context" and expressing these user needs in that wider context - Instead of "We need to refactor to improve responsiveness", "as a user, I want a response within X milliseconds so that I get clear feedback that my request is being acted upon" etc.
4
I have worked on that project 🤣🤣🤣
4
There is this one: https://youtu.be/XhFVtuNDAoM
3
It is very commonly treated as a "PM tool" but I think that is a big misunderstanding of the real value here.
3
@AlessAbreu That can take some very creative thinking. I have been challenged several times and we had to think hard about how to break things down. My fallback position is that the key idea, the foundation that underpins the concept of user stories, is, I think, the desire to be able to separate WHAT the system needs to do, from HOW it does it. Stories should ONLY describe WHAT and NEVER HOW! I find that helps me to be creative about finding them, and breaking them down into smaller pieces.
2
Apologies, I overlooked that when writing the notes. I’ve added it now and the link is here: https://courses.cd.training/courses/atdd-from-stories-to-executable-specifications
2
@christiansaldana9320 I may deploy a first draft of a story "with hard coded values" intro production, but I wouldn't "release it". In CD we make a distinction, we want to deploy into production frequently to get clear unambiguous feedback, that our changes deploy correctly work, along with other things etc. but we can choose to separate all that from "releasing" to real users until we are ready (and we don't have any hard-coded values in the wrong place, unless that is something that we choose to do.) This isn't about reducing choice, it is about increasing it. By definition a Story is meant to be a user-visible ATOMIC change, which means that once it is finished, we may choose to add to it, but it alone is enough to fulfil it's goal.
1
It's interesting that people so often make that assumption, but it is wrong. My background is in building high performance, low-latency, trading systems, web access was incidental, but user stories worked exceedingly well. Don't make the common mistake of confusing "user focus" or "user stories" with "user interface" they aren't the same thing at all!
1
@AlessAbreu me too 😉 I really don't believe that this is a constraint. It does demand a different way of thinking about, and organising, development sometimes, but I have yet to find a problem area where, thinking about what your user's need, doesn't help.
1
Thanks!
1
I agree, to properly use "user stories" the dev team needs to understand the problem they are solving from the perspective of the user. But then again, you are NEVER going to build great software without that. The "magic" here is that if you create TRUE "user stories" they communicate the needs of the user in a way that, over time, the dev team build the knowledge that they need. This learning is facilitated and encouraged by this incremental, small-steps, approach, and is diminished by the "programming by remote control" that is all too common.
1
There is more value in being able to find the price of a book, than not. So there is value there. It is not all that a user wants, but it is more useful than nothing. That is what I mean by something having value, without being "valuable". A penny has value, but one penny is not valuable.
1