In your point on Too Many Details, I understand what you are recommending, that a story card is an opportunity for a conversation. But so often in larger company projects, decisions will have already been made or the dev will not have the opportunity to have the range of conversations. That could be a bad thing but also can save load for some areas. So having past conversations and discovering from product own and business on the card can help. Let the space on the story be more how it is represented than the needs.
Excellent video, you are an experienced professional knowledgeable about the subject and with great didactics to understand it, greetings from Caracas, Venezuela
For the example at 3:31, i would prefer to leave the solution space mostly open. I.e. "As a customer, I would like to know which dishes i have already ordered in the past, so i can try something different this time". This way around, there are multiple approaches how to present the user the information. As a label on the dish description card, as a separate order history, as a hint in your shopping cart, etc. When we formulate like "locate previous orders" it shapes the solution space around the order history view, which may not be the most convinient way for the customer to be informed. The other point, i want to add, is that it is pretty obvious, when we are taking examples from systems we are all well acquainted with as users. But there are also business areas, with specific knowledge, where you have no relation point for empathethic reflection on the users needs. I.e. some insurance software suite. And the users of this software (the customers) have no good references, so they come up with straight forward wishes, limiting the solution space to "..need a checkbox on the ... screen, to mark the customer as ... so that i can filter ..." And because the developers have no experience in such systems, they may not try to elaborate on or challenge this requirement further.
You have such great content! Lately, I’ve been having trouble with finding any software that sufficiently lets me clean, split, and ranks raw stories in a fashion that seems intuitive to me. I’ve thought about writing my own software for it, I’ve thought about just using notion or something- do you have any recommendations on software accessible enough for others to add on to, for me to purely focus on a user story-based backlog? I’m sure inexperience is the primary factor for not feeling happy with Asana or Trello or Pivotal, but I still feel like, if my only goal is to go through a bunch of submitted user stories, clean, organize and rank them, then split and iterate a little until a backlog can be found, in a way that’s somewhat self documenting… idk. I’m having trouble and wanted to see if you had any thoughts or recommendations :|
I can relate to that Price and had similar experience with Asana and other similar tools. They have too many features that serve as distractions rather than help. Notion is by far the cleanest. But here's another thing that I found while working with different tools. Tools doesn't matter. It's how much time you spend within those tools doing what you need to do. With practice you develop your own rhythm of doing things. I would advice you to pick one simple user story and within one tools of choice do all that you need to do with that one user story. Create a list of the things you did. Then repeat those with other user stories. Once you get a hang of it you'll find it engaging and feel satisfied doesn't matter the tool. Hope this helps.
@@VibhorChandel I suppose I’ve been slowly crawling to that conclusion in one way or another. It absolutely does help, thanks so much. I look forward to learning more from you and your videos!
Question "What is the assignment cycle of the User story? Does the QA Team member assign a user story to himself or story remains assigned to Developer?"
Bilal, the word "assignment" has a bad reputation in Agile space. Assignment refers to pushing the responsibility to someone else in the team. We don't do that. We "pull" the responsibility or "assign" it to ourselves. When the dev parts or dev tasks of a US are done the dev puts the story in the "dev complete" column where it is free to be pulled by any available QA. When they pull this dev complete US, the QA then assigns it to him/her self. Hope that makes sense.
' As a customer i want to pay using credit cards so I can buy the service I like on credit' congrats you now got an user story as big as an entire sprint with unknown weight that has 50 sub tasks without weight.
What about changing the user story during the iteration or after, should we add the change as a new user story ( and leave the old one unupdated) or we update old ones to keep them as documentation?
Hi Muhammed, If the user story gets amended to a certain degree that's fine the old story can be updated but if the change is substantial then its best to drop the entire story and recreate a new story altogether.
Great Content - I have just subscribed, I would like to run a podcast with you if that is possible? I run a small agency for e-commerce websites, It think your content can be very useful for wide audience across the Globe
![Diggy Graves - Red Vineyard [Official Lyric Video]](http://i.ytimg.com/vi/8Ro085T0mnQ/mqdefault.jpg)
Really looking forward to your user stories series
You are amazing! You get straight to the point and keep it short unlike these other videos where they overload information
You are awesome and your presentation is right on point. Thank you for providing such clear explanations!
In your point on Too Many Details, I understand what you are recommending, that a story card is an opportunity for a conversation. But so often in larger company projects, decisions will have already been made or the dev will not have the opportunity to have the range of conversations. That could be a bad thing but also can save load for some areas. So having past conversations and discovering from product own and business on the card can help. Let the space on the story be more how it is represented than the needs.
I find most videos of user stories to be average and missing important traits, but this was very good.
Amazing video! I'm going to watch every video you have. You give so much value.
Excellent content. Was looking at my first draft of user stories when watching this and picked up mistakes. Thanks for a clear and concise video.
Nice, crisp, and valuable content, as always. Keep them coming, Vibhor.
Thank you Partha
Excellent video, you are an experienced professional knowledgeable about the subject and with great didactics to understand it, greetings from Caracas, Venezuela
For the example at 3:31, i would prefer to leave the solution space mostly open. I.e. "As a customer, I would like to know which dishes i have already ordered in the past, so i can try something different this time". This way around, there are multiple approaches how to present the user the information. As a label on the dish description card, as a separate order history, as a hint in your shopping cart, etc. When we formulate like "locate previous orders" it shapes the solution space around the order history view, which may not be the most convinient way for the customer to be informed.
The other point, i want to add, is that it is pretty obvious, when we are taking examples from systems we are all well acquainted with as users. But there are also business areas, with specific knowledge, where you have no relation point for empathethic reflection on the users needs. I.e. some insurance software suite. And the users of this software (the customers) have no good references, so they come up with straight forward wishes, limiting the solution space to "..need a checkbox on the ... screen, to mark the customer as ... so that i can filter ..." And because the developers have no experience in such systems, they may not try to elaborate on or challenge this requirement further.
Solid, well explained, great examples. Appreciate it!
For the first don't; please can you let know as to when do we actually freeze a user story and it's acceptance criteria for development?
Hi,
This is the best content ever! Please create some content related to business analysis, It would be great to learn from you.
very useful
You have such great content! Lately, I’ve been having trouble with finding any software that sufficiently lets me clean, split, and ranks raw stories in a fashion that seems intuitive to me. I’ve thought about writing my own software for it, I’ve thought about just using notion or something- do you have any recommendations on software accessible enough for others to add on to, for me to purely focus on a user story-based backlog? I’m sure inexperience is the primary factor for not feeling happy with Asana or Trello or Pivotal, but I still feel like, if my only goal is to go through a bunch of submitted user stories, clean, organize and rank them, then split and iterate a little until a backlog can be found, in a way that’s somewhat self documenting… idk. I’m having trouble and wanted to see if you had any thoughts or recommendations :|
I can relate to that Price and had similar experience with Asana and other similar tools. They have too many features that serve as distractions rather than help. Notion is by far the cleanest.
But here's another thing that I found while working with different tools. Tools doesn't matter. It's how much time you spend within those tools doing what you need to do. With practice you develop your own rhythm of doing things. I would advice you to pick one simple user story and within one tools of choice do all that you need to do with that one user story. Create a list of the things you did. Then repeat those with other user stories. Once you get a hang of it you'll find it engaging and feel satisfied doesn't matter the tool. Hope this helps.
@@VibhorChandel I suppose I’ve been slowly crawling to that conclusion in one way or another. It absolutely does help, thanks so much. I look forward to learning more from you and your videos!
life saver.
Question
"What is the assignment cycle of the User story? Does the QA Team member assign a user story to himself or story remains assigned to Developer?"
Bilal, the word "assignment" has a bad reputation in Agile space. Assignment refers to pushing the responsibility to someone else in the team. We don't do that. We "pull" the responsibility or "assign" it to ourselves. When the dev parts or dev tasks of a US are done the dev puts the story in the "dev complete" column where it is free to be pulled by any available QA. When they pull this dev complete US, the QA then assigns it to him/her self. Hope that makes sense.
' As a customer i want to pay using credit cards so I can buy the service I like on credit'
congrats you now got an user story as big as an entire sprint with unknown weight that has 50 sub tasks without weight.
Hello, I didn't understand the logic you tried to convey. Is it possible to rephrase? Sincerely
What about changing the user story during the iteration or after, should we add the change as a new user story ( and leave the old one unupdated) or we update old ones to keep them as documentation?
Hi Muhammed, If the user story gets amended to a certain degree that's fine the old story can be updated but if the change is substantial then its best to drop the entire story and recreate a new story altogether.
Great Content - I have just subscribed, I would like to run a podcast with you if that is possible? I run a small agency for e-commerce websites, It think your content can be very useful for wide audience across the Globe