Thanks for the Acceptance Criteria examples. Scenarios really do help break down complicated stories with multiple paths. I found your examples really helpful. You mentioned Definition of Done as it relates to "what is in every user story... and how it does not need to be written in each story, etc.." - I would like to add to that. In the context of Acceptance Criteria - I think that is related to Definition of Ready even though it impacts Definition of Done. I'm pushing for my teams to ensure user stories are actionable. While not a hard rule but more of a general guideline to determine if user stories have enough content to begin work. I would say acceptance criteria is one of those requirements. As far as Definition of Done, I would have a item that requires an automated test for each acceptance criteria. Obviously that depends on your testing strategy, but that is how I would separate Ready vs Done.
Sorry if I wasn't clear. I don't consider acceptance criteria as part the definition of done. I was only meaning pointing out what I wouldn't include in a user story. My team very strictly required complete acceptance criteria as part of the definition of ready. We didn't estimate without complete acceptance criteria.
I'd love to see an example of an actual document containing all of these parts whether for USs, BRDs, or even LOEs and IAs. Think you could show some real-life (non-proprietary of course) examples? Because I transitioned from accountant to BA, I have a lot of knowledge in the business side, but when it comes to what these documents should look like, I'm still at a loss, I'm afraid. 🤷🏿♂️
User stories are themselves the document and in scrum they are in a backlog. You don't create BRDs. At the end of the day, anything you produce should be organized and written to ensure whoever is reading it gets exactly what they need to understand from it. Is there a specific challenge you are facing? This video uses real examples that might help you think through it. th-cam.com/video/VZ2cfvpkMjY/w-d-xo.html I also recommended this video on modeling your information th-cam.com/video/a6ZZWol3WJs/w-d-xo.html BA Pro Tip : Avoid using acronyms. Part of your job is to ensure everyone is having the same understanding and you are assuming those acronyms mean the same to me as the mean to you.
Idk why I don't get notifications about yt entries... but glad you responded. When I had that role at the time, I was being asked to create a "level of effort" document in relation to a particular update happening on the then Sprint platform (I'm pretty sure I can say that now). I had never heard of this, so I was taken aback and scrambling. When I spoke with my dev to see what he thought, he said it was low... and that was it. When I told my manager (after a week of searching), she said "ok." So I felt like I was setup. Initially she asked for a document, but when giving that as an accepted response, she seemed to forget about the "document" part of that request. Still, is there such a thing as an LOE doc?
For me writing in Gherkin is a bit countering the earlier point you made about focusing on what the user needs to do and leaving freedom for the team on implementation. How do you leave this freedom while still describing such detailed steps?
Depends how you write it. For example... GIVEN user has selected an amount AND has sufficient funds WHEN user selects withdraw THEN dispense the selected amount I haven't dictated how the selection should happen, how it should look, how the funds should be confirmed, the verbiage to be used, how many confirmation screens to include, etc.
@@AngeloTheBAif the BA is writing requirements to specify things like verbiage, how something needs to look/be laid out, etc. in order to meet business needs, would those conditions be considered acceptance criteria as well?
Hi,Very good and simple video, thank you for posting. While I like this approach, it seems to me that Gherkin is a bit time consuming. What would you suggest to make is easier and quicker for BAs to implement this?
Gherkin is really just a style of writing that creates clarity. On my team Gherkin was requested by our development team to help them be more efficient so the BAs adopted it. Taking a little extra time to write a more clear user story saves time in the long run when the team is developing it. At the end of the day, its up to your team to decide the right balance and style.
![POLYCAT - ข้อความรูปยิ้ม [Music Video]](http://i.ytimg.com/vi/lBhIgPGCgbI/mqdefault.jpg)
Final slide is so meaningful, to understand different terms used in waterfall and agile but how similar they actually are.
Good content! it would be a nice idea to put an example from the beginning through the end.
Good feedback. Thanks.
Agreed
Thanks for the Acceptance Criteria examples. Scenarios really do help break down complicated stories with multiple paths. I found your examples really helpful. You mentioned Definition of Done as it relates to "what is in every user story... and how it does not need to be written in each story, etc.." - I would like to add to that. In the context of Acceptance Criteria - I think that is related to Definition of Ready even though it impacts Definition of Done. I'm pushing for my teams to ensure user stories are actionable. While not a hard rule but more of a general guideline to determine if user stories have enough content to begin work. I would say acceptance criteria is one of those requirements. As far as Definition of Done, I would have a item that requires an automated test for each acceptance criteria. Obviously that depends on your testing strategy, but that is how I would separate Ready vs Done.
Sorry if I wasn't clear. I don't consider acceptance criteria as part the definition of done. I was only meaning pointing out what I wouldn't include in a user story. My team very strictly required complete acceptance criteria as part of the definition of ready. We didn't estimate without complete acceptance criteria.
@@AngeloTheBA FYI- I took examples out of this story and applied it to an Acceptance Criteria exercise with my team. Thanks again!
Nice contents. brief and accurate. Thanks
I'd love to see an example of an actual document containing all of these parts whether for USs, BRDs, or even LOEs and IAs. Think you could show some real-life (non-proprietary of course) examples? Because I transitioned from accountant to BA, I have a lot of knowledge in the business side, but when it comes to what these documents should look like, I'm still at a loss, I'm afraid. 🤷🏿♂️
User stories are themselves the document and in scrum they are in a backlog. You don't create BRDs.
At the end of the day, anything you produce should be organized and written to ensure whoever is reading it gets exactly what they need to understand from it.
Is there a specific challenge you are facing? This video uses real examples that might help you think through it. th-cam.com/video/VZ2cfvpkMjY/w-d-xo.html
I also recommended this video on modeling your information th-cam.com/video/a6ZZWol3WJs/w-d-xo.html
BA Pro Tip : Avoid using acronyms. Part of your job is to ensure everyone is having the same understanding and you are assuming those acronyms mean the same to me as the mean to you.
Idk why I don't get notifications about yt entries... but glad you responded. When I had that role at the time, I was being asked to create a "level of effort" document in relation to a particular update happening on the then Sprint platform (I'm pretty sure I can say that now). I had never heard of this, so I was taken aback and scrambling. When I spoke with my dev to see what he thought, he said it was low... and that was it. When I told my manager (after a week of searching), she said "ok." So I felt like I was setup. Initially she asked for a document, but when giving that as an accepted response, she seemed to forget about the "document" part of that request. Still, is there such a thing as an LOE doc?
Can you please make videos on wireframe
I'll put it on my to do list!
I would also like to see this.
Thanks bro.
This helps. Thank you
For me writing in Gherkin is a bit countering the earlier point you made about focusing on what the user needs to do and leaving freedom for the team on implementation.
How do you leave this freedom while still describing such detailed steps?
Depends how you write it. For example...
GIVEN user has selected an amount
AND has sufficient funds
WHEN user selects withdraw
THEN dispense the selected amount
I haven't dictated how the selection should happen, how it should look, how the funds should be confirmed, the verbiage to be used, how many confirmation screens to include, etc.
@@AngeloTheBAif the BA is writing requirements to specify things like verbiage, how something needs to look/be laid out, etc. in order to meet business needs, would those conditions be considered acceptance criteria as well?
This is awesome
Hi,Very good and simple video, thank you for posting. While I like this approach, it seems to me that Gherkin is a bit time consuming. What would you suggest to make is easier and quicker for BAs to implement this?
Gherkin is really just a style of writing that creates clarity. On my team Gherkin was requested by our development team to help them be more efficient so the BAs adopted it. Taking a little extra time to write a more clear user story saves time in the long run when the team is developing it. At the end of the day, its up to your team to decide the right balance and style.
Hi Angelo, thanks for your great content on BA, I'm trying to access your website but it's currently down, can you have a look ?
Thanks for letting me know. Seems there was an update pushed that broke something. Everything is back up and running.