This was the first problem we had to solve for CD. BDD was our solution for thin slices to overcome bloat in a story. We stopped arguing about story points and just focused on delivering scenarios that could get done in 1-2 days.
Same here, one point we still struggle though, stories that involve creating infrastructure, terraform, pipelines. We either split the base work, then it’s hard to follow bdd and show business value clearly or we end up with bigger stories that as expected take too long and are more prone to unexpected issues
@@CanalDoFante User stories are the wrong tool for building the infrastructure. Define the work for the infrastructure and do it. If a user story depends on infrastructure that doesn't exist, then you're blocked until it does.
@@CanalDoFante There's a lof of "cheating" that you can before you actually need any infrastructure on the cloud. Infrastructure should appear if there is a business need for it, not by default.
Would you consider making a video that walks through a thought experiment that accommodates the more complicated situations people are bringing up? I’m guessing that the advice remains the same even if there isn’t any real user component: make the problem you’re solving smaller. Or, try to discover the portion of the problem that can be solved in a 1-3 day window.
Contrived examples are always great, but the reality of user stories in complex systems is that they are often an ice berg. From the users perspective very little is happening but in the backend there are many technical things happening. Then devs are told its too big and they break it down into technical tasks... and make it look like user stories. If we were to take your trivial example and bring it closer to reality, you need to show the books from the legacy application and join it with some new data from another new service. From the users perspective they just see a list of books but from a technical perspective this may be a lot of work, and take longer than 2 weeks for a single dev. Sure its easy to tell the business we will just hard code everything but then what user story will fix the backend? Another user story wont do it because you will need to hard code everything there as well to keep it small? At some point the business needs the application to work properly and you cant keep skipping out on technical needs to make user stories small.
From the Project Management side, this is a benefit instead of a detriment and that is setting your dev team up for deadline failure, at best. The single dev you mention might also feel the pressure building as zero ticket movement occurs, which everyone else sees, while they _are_ being productive. I think the answer is casting different systems and major roles of code as "users" themselves; as in, the external service delivers __ so the __ can do __ and so on. When the project managers and, eventually, the product management are allowed to safely ignore technical details in their planning, they stop understanding that someone, somewhere is responsible for making these things happen and that they represent necessary and productive progress towards the "story". Weirdly enough, focusing on the number of decisions or "things that must happen", while seen as an out-dated concept, captured this very real work much better than any method I've seen currently because the number grows so quickly. However, that ever growing number is the reality and it provides insight into what the unit of composition of work should be and what layers, systems, etc. need to be improved to do more with less work. Erasing these details under the "User Story" rug simply hides the truth and leads to people accepting lower standards of quality so their sprint points look better than most.
sounds like a skill issue to me. Its paramount that those creating user stories and use cases need to have mastery over systems thinking techniques and the ability to level thinking from high to low, low to high and everything in between. My experience is that this just isnt the case
@@wcwilkins firstly this board movement thing is a load of crap, scrum masters try and convince the world that developers only sense of accomplishment comes from moving a ticket across the board. Devs don't care unless you tell them they must. Without a board devs care about code, tests, deploys, etc. Then the odd comment that not split the ticket hides the details so people skip on sp and quality. That is also just not true for good devs that can self manage, yes if you have inexperienced devs and you need a manager to hold their hand every step of the way m, then yes you need to specify technical tasks. You can keep the broad user story, then sub task technical work.
@@uskok4636 if you're an expert then please look at my example split that user story without it getting technical. Everytime this talk of user stories comes up people always use trivial examples. The example I gave is not even that bad it gets far worse than that but it illustrates the point of there being a lot more to do than what the user sees.
Agreed. Where I work we use Goals, Epics, Stories and Tasks. Goals are high level business objectives, Epics are "largish" features that bring something meaningful (valuable) to the marketplace. I would consider them "above the water" in the iceberg analogy. Below the water are stories and tasks and there are lot of them and many are highly technical. In my experience, the biggest problem is keeping product management out of the below water stuff. They like to come down there, dictate minor details, remove testing stories, deprioritize refactoring and other tech debt, etc. I wonder if you could look at an organizational layout and count the number of people in certain roles to tell if the "iceberg" is well balanced or not.
Good topic. Thank you! I didn't really grok stories till your interview with Alan Holub, where he talked about stories as literally 'stories' that describe a desired interaction with the software, but don't fully specify that interaction. I think one way stories become too prescriptive is when the development team has little to no connection with or understanding of end users, and must rely on BAs or POs or some other intermediary. This often causes the story to be the only communication point between stakeholders, and devs clamour for more details because they have no other context to understand what is required.
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.
this is a really interesting thought and it makes sense to bring the devs closer to the user. I often find it can make meetings more productive, because a dev can ask the right question to the business user, instead of meeting ping-pong, with the intermediary BA, but if that is true, what do you see the role of the BA is, within software development ?@@ContinuousDelivery
Dave, I love your content and while I don't share 100% your point of view, I value it still since it's coming from years of experience. Have you considered making a video on the topic of being effective hiring people?
I don’t think I understand your argument this time. I’m missing some way of going back to the original question at the end. Maybe I’m wrong but at some point you have to write those endpoints. And sometimes even the smallest tasks take days. Unless they are really like a technical tasks. 😅Maybe I should finally read the User Stories book.
Many devs that work on a user story that is just a mock of Books for example. often end up later that they create a user story that says "create database" and when that happens the full functional value will take more days than 1-3 days. In that case they invent horizontal splitting, and not vertical slice user stories. And if there is a feedback loop and the idea is to add the database before they close such a story, the lead time can be 7 days or more. So the size of a story is not the size of the "coding work" it shall consider the lead time to. If we start the story then is shall also be closed and in prod after 3 days. If not then it's big by it self.
Seeing it from the point of user story is one way. Another way is going more big corpo, for example diving and creating soft boundaries. It can be: +> task or subtasks: can take 2 hours to 1-2 days (ideally less than one week), +> user stories: should be possible to be completed within one sprint or scumban iteration. They are comprised by tasks. +> epics: can span through more than one iteration. They are a group of user stories. +> initiatives: is a working force for one quarter. They are made of epics. With this, after a few months (and how many months can variate a lot), this setup allows to have clarity on where a requirement or detail should be scoped and makes easier for the different members of an organization to work and describe value in different levels. It add also some overhead to the planning. What are other disadvantages from this layered approach?
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!
@@ContinuousDelivery Certainly but the area that I work with has some very complicated maths going on and depending what you are trying to do, just to work in the smallest feature/story/requirement would take days, and any work already takes weeks. Some features are faster but sometimes Devs prefer to say their work is more research than actual development because of how long something takes
@@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.
@@ContinuousDelivery I agree and specially in the area that I am right now people expect a whole design before the developer starts coding. My argument is entirely on how long a story takes and being able to break it down
@@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.
I am enjoying your videos, but I am having a hard time seeing how usability or UI development work within your trunk-based CI/CD approach. I am still working through Modern Software Engineering, but I don't see these ideas in the index. Can you share your thoughts on these, or are they covered in another video?
I don't use jira. I have a small team of 2 devs (me included) and there is no point writing details of what we know needs to be done. However, I have worked on teams with the typical scrum master writing stores "as a user" and then goes on to write a novel. I would never read these and just ask the person to summarize it for me. Eventually, after weeks and months of doing this, they finally caught on that I wasn't reading all of what they wrote, and no one else was either.
I dont see how you can say "once we have it, this is already of value although not yet valuable". From dev's perspective yes it makes it gives us value for us to make it easier to later hook it up with actual data but i dont see how that is a value from customers perspective. Idk seems a bit weird to say something is of value but not yet valuable
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.
It would have been nice to address what kind of story the remaining backend of the book store would be, once you have faked the frontend. This is a very common question and problem for teams when trying to size up their tickets and trying to stay small but valuable.
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!
@@ContinuousDelivery Thank you for elaborating on this. I have found this change in focus very difficult with our teams, because a lot of the BE architecture work we decide to do is not directly impacting what the user/client asked for. And devs being devs, we tend to add things because architecturally they seem to make sense (maybe due to wider context of the product or platform behind the scenes), e.g. for scalability or maintenance reasons etc. However, it's clear that we need to learn to express all of that in terms of actual user need, or, if we can't, discard it until it becomes a user need. A difficult mindset change, but definitely worth it.
@@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.
@@ContinuousDelivery Thanks again, that's very clear. This way of rethinking a ticket and using Gherkin comes with a nice way identifying unjustifiable work: It becomes ridiculous very quickly when "as a user I want my backend to be in microservices so I can decouple..." and so on.
A little late to the party, but what happens once you complete your story with hard coded values? You release it to prod ASAP and then what? Do you work on the next step for that feature immediately? If so do you create the new story immediately after completing the previous story or do you already have one prepared in the sprint backlog from a previous grooming session?
Stories are not the tasks, theyre the problem description and who is involved, outcome they like to achieve. They're describing tasks that are related to this story and could be related to more stories
Based on my experience, every time things get too abstract and too complicated to explain, something is wrong! Example on the most common scenario we all have (TDD on CRUD) will set an standard and put stop to all discussions, IMHO.
I wonder how long it takes to change a mind set on the developers side when the team management changes. Going from "solution must be right on first go and you won't be able to touch it until it breaks" vs "i want fast prototypes which help you understand the problem and you change the complete application as the understanding and needs change". It's an uphill battle.
Not long. The outcome of the first approach is a failed product right from the start, because there is no business that can clearly state its needs "on first go". The second one will lead to a successful product because you are building iteratively and you provide incremental value to which the users can react and provide feedback.
Management always assumes the solution is always right the first time. At the same time, the dev teams can always refactor and change their mind on the solution as they go along, and they don't really need to communicate or ask for permission to management. Dev teams can always do that as part of the user stories.
Apologies, I overlooked that when writing the notes. I’ve added it now and the link is here: courses.cd.training/courses/atdd-from-stories-to-executable-specifications
This was the first problem we had to solve for CD. BDD was our solution for thin slices to overcome bloat in a story. We stopped arguing about story points and just focused on delivering scenarios that could get done in 1-2 days.
Wow! YT URL filtering is even more aggressive than I expected.
There is an org page for the DojoConsortium that has the methods we found useful.
Same here, one point we still struggle though, stories that involve creating infrastructure, terraform, pipelines.
We either split the base work, then it’s hard to follow bdd and show business value clearly or we end up with bigger stories that as expected take too long and are more prone to unexpected issues
@@CanalDoFante User stories are the wrong tool for building the infrastructure. Define the work for the infrastructure and do it. If a user story depends on infrastructure that doesn't exist, then you're blocked until it does.
@@CanalDoFante There's a lof of "cheating" that you can before you actually need any infrastructure on the cloud. Infrastructure should appear if there is a business need for it, not by default.
Would you consider making a video that walks through a thought experiment that accommodates the more complicated situations people are bringing up? I’m guessing that the advice remains the same even if there isn’t any real user component: make the problem you’re solving smaller. Or, try to discover the portion of the problem that can be solved in a 1-3 day window.
Contrived examples are always great, but the reality of user stories in complex systems is that they are often an ice berg. From the users perspective very little is happening but in the backend there are many technical things happening. Then devs are told its too big and they break it down into technical tasks... and make it look like user stories.
If we were to take your trivial example and bring it closer to reality, you need to show the books from the legacy application and join it with some new data from another new service. From the users perspective they just see a list of books but from a technical perspective this may be a lot of work, and take longer than 2 weeks for a single dev.
Sure its easy to tell the business we will just hard code everything but then what user story will fix the backend? Another user story wont do it because you will need to hard code everything there as well to keep it small? At some point the business needs the application to work properly and you cant keep skipping out on technical needs to make user stories small.
From the Project Management side, this is a benefit instead of a detriment and that is setting your dev team up for deadline failure, at best. The single dev you mention might also feel the pressure building as zero ticket movement occurs, which everyone else sees, while they _are_ being productive. I think the answer is casting different systems and major roles of code as "users" themselves; as in, the external service delivers __ so the __ can do __ and so on. When the project managers and, eventually, the product management are allowed to safely ignore technical details in their planning, they stop understanding that someone, somewhere is responsible for making these things happen and that they represent necessary and productive progress towards the "story".
Weirdly enough, focusing on the number of decisions or "things that must happen", while seen as an out-dated concept, captured this very real work much better than any method I've seen currently because the number grows so quickly. However, that ever growing number is the reality and it provides insight into what the unit of composition of work should be and what layers, systems, etc. need to be improved to do more with less work. Erasing these details under the "User Story" rug simply hides the truth and leads to people accepting lower standards of quality so their sprint points look better than most.
sounds like a skill issue to me. Its paramount that those creating user stories and use cases need to have mastery over systems thinking techniques and the ability to level thinking from high to low, low to high and everything in between. My experience is that this just isnt the case
@@wcwilkins firstly this board movement thing is a load of crap, scrum masters try and convince the world that developers only sense of accomplishment comes from moving a ticket across the board. Devs don't care unless you tell them they must. Without a board devs care about code, tests, deploys, etc. Then the odd comment that not split the ticket hides the details so people skip on sp and quality. That is also just not true for good devs that can self manage, yes if you have inexperienced devs and you need a manager to hold their hand every step of the way m, then yes you need to specify technical tasks. You can keep the broad user story, then sub task technical work.
@@uskok4636 if you're an expert then please look at my example split that user story without it getting technical. Everytime this talk of user stories comes up people always use trivial examples. The example I gave is not even that bad it gets far worse than that but it illustrates the point of there being a lot more to do than what the user sees.
Agreed. Where I work we use Goals, Epics, Stories and Tasks. Goals are high level business objectives, Epics are "largish" features that bring something meaningful (valuable) to the marketplace. I would consider them "above the water" in the iceberg analogy. Below the water are stories and tasks and there are lot of them and many are highly technical. In my experience, the biggest problem is keeping product management out of the below water stuff. They like to come down there, dictate minor details, remove testing stories, deprioritize refactoring and other tech debt, etc.
I wonder if you could look at an organizational layout and count the number of people in certain roles to tell if the "iceberg" is well balanced or not.
Good topic. Thank you! I didn't really grok stories till your interview with Alan Holub, where he talked about stories as literally 'stories' that describe a desired interaction with the software, but don't fully specify that interaction.
I think one way stories become too prescriptive is when the development team has little to no connection with or understanding of end users, and must rely on BAs or POs or some other intermediary. This often causes the story to be the only communication point between stakeholders, and devs clamour for more details because they have no other context to understand what is required.
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.
this is a really interesting thought and it makes sense to bring the devs closer to the user. I often find it can make meetings more productive, because a dev can ask the right question to the business user, instead of meeting ping-pong, with the intermediary BA, but if that is true, what do you see the role of the BA is, within software development ?@@ContinuousDelivery
Dave, I love your content and while I don't share 100% your point of view, I value it still since it's coming from years of experience.
Have you considered making a video on the topic of being effective hiring people?
I don’t think I understand your argument this time. I’m missing some way of going back to the original question at the end. Maybe I’m wrong but at some point you have to write those endpoints. And sometimes even the smallest tasks take days. Unless they are really like a technical tasks. 😅Maybe I should finally read the User Stories book.
Many devs that work on a user story that is just a mock of Books for example. often end up later that they create a user story that says "create database" and when that happens the full functional value will take more days than 1-3 days. In that case they invent horizontal splitting, and not vertical slice user stories. And if there is a feedback loop and the idea is to add the database before they close such a story, the lead time can be 7 days or more. So the size of a story is not the size of the "coding work" it shall consider the lead time to. If we start the story then is shall also be closed and in prod after 3 days. If not then it's big by it self.
The power of the right question!
Seeing it from the point of user story is one way. Another way is going more big corpo, for example diving and creating soft boundaries. It can be: +> task or subtasks: can take 2 hours to 1-2 days (ideally less than one week), +> user stories: should be possible to be completed within one sprint or scumban iteration. They are comprised by tasks. +> epics: can span through more than one iteration. They are a group of user stories. +> initiatives: is a working force for one quarter. They are made of epics. With this, after a few months (and how many months can variate a lot), this setup allows to have clarity on where a requirement or detail should be scoped and makes easier for the different members of an organization to work and describe value in different levels. It add also some overhead to the planning. What are other disadvantages from this layered approach?
It's interesting that these examples of stories that should be quick to implement are always web related where things and quick and easy...
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!
@@ContinuousDelivery Certainly but the area that I work with has some very complicated maths going on and depending what you are trying to do, just to work in the smallest feature/story/requirement would take days, and any work already takes weeks. Some features are faster but sometimes Devs prefer to say their work is more research than actual development because of how long something takes
@@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.
@@ContinuousDelivery I agree and specially in the area that I am right now people expect a whole design before the developer starts coding. My argument is entirely on how long a story takes and being able to break it down
@@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.
I am enjoying your videos, but I am having a hard time seeing how usability or UI development work within your trunk-based CI/CD approach. I am still working through Modern Software Engineering, but I don't see these ideas in the index. Can you share your thoughts on these, or are they covered in another video?
I don't use jira. I have a small team of 2 devs (me included) and there is no point writing details of what we know needs to be done. However, I have worked on teams with the typical scrum master writing stores "as a user" and then goes on to write a novel. I would never read these and just ask the person to summarize it for me. Eventually, after weeks and months of doing this, they finally caught on that I wasn't reading all of what they wrote, and no one else was either.
I wish this video was out years ago!
Don't know from who i picked this up but story points are of 3 discrete values: 1, TFB, NFC
"This isn't, primarily, a PM tool"
Well, where I work it is.
It is very commonly treated as a "PM tool" but I think that is a big misunderstanding of the real value here.
I wonder what a story would look like when you develop an AI? Or when you are doing software for medical equipment tech?
I dont see how you can say "once we have it, this is already of value although not yet valuable". From dev's perspective yes it makes it gives us value for us to make it easier to later hook it up with actual data but i dont see how that is a value from customers perspective. Idk seems a bit weird to say something is of value but not yet valuable
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.
It would have been nice to address what kind of story the remaining backend of the book store would be, once you have faked the frontend. This is a very common question and problem for teams when trying to size up their tickets and trying to stay small but valuable.
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!
@@ContinuousDelivery Thank you for elaborating on this. I have found this change in focus very difficult with our teams, because a lot of the BE architecture work we decide to do is not directly impacting what the user/client asked for. And devs being devs, we tend to add things because architecturally they seem to make sense (maybe due to wider context of the product or platform behind the scenes), e.g. for scalability or maintenance reasons etc.
However, it's clear that we need to learn to express all of that in terms of actual user need, or, if we can't, discard it until it becomes a user need.
A difficult mindset change, but definitely worth it.
@@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.
@@ContinuousDelivery Thanks again, that's very clear. This way of rethinking a ticket and using Gherkin comes with a nice way identifying unjustifiable work: It becomes ridiculous very quickly when "as a user I want my backend to be in microservices so I can decouple..." and so on.
A little late to the party, but what happens once you complete your story with hard coded values? You release it to prod ASAP and then what? Do you work on the next step for that feature immediately? If so do you create the new story immediately after completing the previous story or do you already have one prepared in the sprint backlog from a previous grooming session?
Good stuff! Do you have another video on the other issue you mentioned, "Taking Responsibility for Quality Away from Devs"?
There is this one: ruclips.net/video/XhFVtuNDAoM/видео.html
Stories are not the tasks, theyre the problem description and who is involved, outcome they like to achieve.
They're describing tasks that are related to this story and could be related to more stories
Thank you, Dave! This advice came to me at an actually useful time, as I just realized a huge mistake I was doing.
just love your t-shirts
So a story should display 1 user requirement and show how we test the requirement? Without getting techical?
Based on my experience, every time things get too abstract and too complicated to explain, something is wrong! Example on the most common scenario we all have (TDD on CRUD) will set an standard and put stop to all discussions, IMHO.
User Story # 1: Build Complex Distributed System
User Story # 2: ???
User Story # 3: Proffit
I have worked on that project 🤣🤣🤣
I wonder how long it takes to change a mind set on the developers side when the team management changes. Going from "solution must be right on first go and you won't be able to touch it until it breaks" vs "i want fast prototypes which help you understand the problem and you change the complete application as the understanding and needs change".
It's an uphill battle.
Not long. The outcome of the first approach is a failed product right from the start, because there is no business that can clearly state its needs "on first go". The second one will lead to a successful product because you are building iteratively and you provide incremental value to which the users can react and provide feedback.
Management always assumes the solution is always right the first time. At the same time, the dev teams can always refactor and change their mind on the solution as they go along, and they don't really need to communicate or ask for permission to management. Dev teams can always do that as part of the user stories.
Great video.
Thanks!
Yay! First comment 🤪
Love your work Dave!
I don’t see the course in the show notes
Apologies, I overlooked that when writing the notes. I’ve added it now and the link is here: courses.cd.training/courses/atdd-from-stories-to-executable-specifications
Whenever you hear "this is just CRUD" these days, run away.... fast.
Why is your audio distorting? I am sure you could invest a bit in a decent mic setup + audio production.