Your videos are informative so kudos to you on that!. I have subscribed btw. I had a question though, (Assumption : User stories created are independent , and selected user stories are from different epics for first release ) Question : => "if user stories are selected based on team capacity or team velocity and created using INVEST criteria , then how do you come up with an increment that is potentially a shippable product (at the end of a sprint or a release) , for example first release" ? =>are user stories selected for a sprint be connected and is increment always a shippable product ? Would be happy if you could neutralise my questions with a succinct approach. :D Thanks
Hey! Thanks for your support and for subscribing! The backlog should be ordered based on business value. This means the user stories on top bring the most to the users. Whenever the Product Owner aims to release a certain functionality will make sure that those user stories are on top. To give you a concrete example, at Orli, we release our first version of the Management Dashboard. The user stories were split as per the INVEST principle and ordered the highest value first. But unfortunately, the Scrum team didn't have enough capacity to develop all the user stories that our Product Owner would have to want. So then, the Product Owner (PO) negotiated with the Development team on how to release a Dashboard in the given capacity. The solution we found was to not support custom questions for the Daily Standup Discord bot. Because we use Behaviour Driven Development, this "feature" represented several acceptance criteria from several user stories. And our Product Owner created another user story for it which had the highest priority in the upcoming sprint. At Orli, we do continuous deployment and release on demand. This allowed our Product Owner to release this latest user story as soon as it was ready, and the users weren't that disturbed. Regarding: "are user stories selected for a sprint be connected, and is increment always a shippable product?". You have 2 situations: 1. improvements user stories, small functionalities that were "negotiated" out of the scope of a sprint to have a shippable product. Or new requirements from the users when they see a new feature. 2. In real life, not all the completed user stories make a shippable product. While the aim is to release everything, it does happen to arrive at Sprint Review and see that we need more usability features, for example, to make it client-facing. Did I answer your questions?
@@theagilescrumchannel8657 Well the response was fantastic. Would definitely take a moment to appreciate your time and efforts for the same. It just sparked more questions though. 1. Is first release always suppose to be MVP or MVP comes in multiple releases? 2. Is it a good practice to have several user stories ready ahead of the release cycle , so the developers don't sit idle , just incase the completed user story is perceived as an incomplete user story ? 3.what are some salient, essential recommended practices that you would recommend to gear someone towards being a seasoned BA (excluding documentation , facilitation and stakeholder management, learning new software tools and testing)? P.S. My questions are not an attempt to boast what I know , but more centred towards finer details. :D And here I rest my case ( I am budding BA applying for jobs) :D. Appreciate your support :D
Your videos are informative so kudos to you on that!.
I have subscribed btw.
I had a question though,
(Assumption : User stories created are independent , and selected user stories are from different epics for first release )
Question :
=> "if user stories are selected based on team capacity or team velocity and created using INVEST criteria , then how do you come up with an increment that is potentially a shippable product (at the end of a sprint or a release) , for example first release" ?
=>are user stories selected for a sprint be connected and is increment always a shippable product ?
Would be happy if you could neutralise my questions with a succinct approach. :D
Thanks
Hey! Thanks for your support and for subscribing!
The backlog should be ordered based on business value. This means the user stories on top bring the most to the users. Whenever the Product Owner aims to release a certain functionality will make sure that those user stories are on top.
To give you a concrete example, at Orli, we release our first version of the Management Dashboard. The user stories were split as per the INVEST principle and ordered the highest value first. But unfortunately, the Scrum team didn't have enough capacity to develop all the user stories that our Product Owner would have to want.
So then, the Product Owner (PO) negotiated with the Development team on how to release a Dashboard in the given capacity.
The solution we found was to not support custom questions for the Daily Standup Discord bot.
Because we use Behaviour Driven Development, this "feature" represented several acceptance criteria from several user stories. And our Product Owner created another user story for it which had the highest priority in the upcoming sprint.
At Orli, we do continuous deployment and release on demand. This allowed our Product Owner to release this latest user story as soon as it was ready, and the users weren't that disturbed.
Regarding: "are user stories selected for a sprint be connected, and is increment always a shippable product?".
You have 2 situations:
1. improvements user stories, small functionalities that were "negotiated" out of the scope of a sprint to have a shippable product. Or new requirements from the users when they see a new feature.
2. In real life, not all the completed user stories make a shippable product. While the aim is to release everything, it does happen to arrive at Sprint Review and see that we need more usability features, for example, to make it client-facing.
Did I answer your questions?
@@theagilescrumchannel8657 Well the response was fantastic. Would definitely take a moment to appreciate your time and efforts for the same.
It just sparked more questions though.
1. Is first release always suppose to be MVP or MVP comes in multiple releases?
2. Is it a good practice to have several user stories ready ahead of the release cycle , so the developers don't sit idle , just incase the completed user story is perceived as an incomplete user story ?
3.what are some salient, essential recommended practices that you would recommend to gear someone towards being a seasoned BA (excluding documentation , facilitation and stakeholder management, learning new software tools and testing)?
P.S. My questions are not an attempt to boast what I know , but more centred towards finer details. :D
And here I rest my case ( I am budding BA applying for jobs) :D.
Appreciate your support :D