Without thinking too much about it I've been doing both. To me it just comes natural to start with the User Story. In some cases, mostly with big technical topics I might start with the Feature and it's probably because I need the structure.
I also used to do both, but I believe User Stories often become convoluted and unclear when you reverse engineer them from Features.
Better to preserve the original User Story, which is rooted in the problem and the thing they truly care about, and then link the features you're delivering to resolve that to it. It saves a lot of time, and is more clear, as otherwise User Stories may or may not describe a real need.
The user doesn't want to press the button or filter, they want to achieve a certain outcome. If they could do it without the filtering also fine :). And that's why it's better to keep the User Stories agnostic to what you're buliding, as then you can validate what you're delivering actually fixes their problem.
I’m finally beginning to break the thinking pattern for our team by working backwards from the problem (the user story). It’s difficult to get away from those patterns when we have frameworks like SAFe that induce them. I’ve seen those frameworks be used to create solutions, instead of organizing work - which is what they’re really intended for. Thanks for the write-up!
Without thinking too much about it I've been doing both. To me it just comes natural to start with the User Story. In some cases, mostly with big technical topics I might start with the Feature and it's probably because I need the structure.
I also used to do both, but I believe User Stories often become convoluted and unclear when you reverse engineer them from Features.
Better to preserve the original User Story, which is rooted in the problem and the thing they truly care about, and then link the features you're delivering to resolve that to it. It saves a lot of time, and is more clear, as otherwise User Stories may or may not describe a real need.
The user doesn't want to press the button or filter, they want to achieve a certain outcome. If they could do it without the filtering also fine :). And that's why it's better to keep the User Stories agnostic to what you're buliding, as then you can validate what you're delivering actually fixes their problem.
I’m finally beginning to break the thinking pattern for our team by working backwards from the problem (the user story). It’s difficult to get away from those patterns when we have frameworks like SAFe that induce them. I’ve seen those frameworks be used to create solutions, instead of organizing work - which is what they’re really intended for. Thanks for the write-up!