If you are new to Agile or more of an observer than a practitioner, you may not be clear on the precise meanings of Epic, User Story, and Story Point. So, let me explain. Thank you for watching - please do subscribe to the channel and, to join my community, sign-up at onlinepmcourses.com/assets440251/the-onlinepmcourses-newsletter/
Best explanation I have ever heard. I have been on courses and asked multiple Scrum Master to explain User Stories and received a lot of contradications and vague explanations.
I passed my PMP on 23 August-3 ATs! Most of the questions were agile. Your tips were very helpful. All the best to those who are preparing for the exam. Thanks a lot!
Love your channel. There are so many bogus PM teachers online who use terms interchangeably and confuse the heck out of students, but you, my friend are the ultimate myth debunker! Subscribed! :) Thank you for this video!
Thank you very much. To be fair, some terms are used differently in different places (countries - even companies). However, where I don't have deep expertise (like Agile - I learned my PM in the e1990s, so am a predictive PM sort of a guy), I do try to do my research and double-check where I can. And on the rare occasions (twice in 600 vids, I think) that a commenter spots an error, I add a correction to the pinned comment. It's great to have you on board!
@@Onlinepmcourses I appreciate the fact that you do your due diligence and responsibly make video content by double-checking. That is appreciable. Thank you, once again.
Hello from France! I am currently studying PM and your video is the first one that has really helped me understand the differences and links between these terms : Epics, User Stories and Story Points. Very clear and well explained! Thank you! I'll go watch your other videos 😊
That's great to hear, thank you. You may want to look at my (more recent) video on Story Mapping, which is closely related to this one: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-aQHIegIaqFQ.html
In a row I watched 3 videos and yours is 4th Video Sir, Thank you for explaining in comman words and making it understandable in layman words. Subscribed to your channel.
Well, it depends upon the industry as to which approach to adopt. For construction projects, we go for Waterfall and for IT projects we settle with Agile. I have served a decade leading projects in Waterfall approach so I am comfortable with it :) In IT the projects are incremental and require a lot of iterations
This is true. However, there are a lot of projects where it pays to use a hybrid approach that borrows tools and methods from one domain (adaptive or predictive) and overlays them onto the general approach of the other. Like you, my primary experience is with predictive PM. I deprecate the term 'waterfall', but it is important for those who don't know, what waterfall is: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-W4lE6ozdjls.html By the way, Waterfall vs Agile: The Big Principle at Stake: ru-vid.com/video/%D0%B2%D0%B8%D0%B4%D0%B5%D0%BE-we1PJ7OY3PY.html
@@SritamPaltasingh Tasks belong to predictive project management. Stories belong to agile methods. You could split a story into tasks, but in practice - particularly in software development, dev teams do not. However, 'Story Splitting' is the process of breaking a user story into smaller stories to create more manageable chunks of work. You could call the work needed to deliver the smaller story a task, but I don't think that is a common terminology in the agile community.
The action is what you want to be able to do: 'I want to store the name of my customer' The benefit is why you want to do it - what advantage that confers: 'So that we can contact them again later' Sometimes it will seem that the benefit of an action is obvious. However, the benefit is the 'why' and so allows us to ask: 'okay, that's what you really want. How else (what alternative action) can we give that to you?'
Epics form part of story maps (video scheduled for October 2023). And these often follow the user or customer journey. But they are different. An epic is a big chunk of functionality needed along the user journey.
Storypoints are used to estimate the scale of the task and therefore what work can be done in an iteration. I have never heard of them being used to represent the value to the business and do not see how that would be done - ro why. By default, I would expect that *broadly*, the stories drawn down for the next iteration will represent the most valuable user stories remaining, once the infrastructure elements are in place. The simplicity of story points would be compromised if we tried to shoehorn a second metric into the concept. If I wanted to rate the business value of a user story, I might add a simple coding like 1, 2, or 3 stars to the story, to simplify sory selection. But, that said, I'd expect the Product Owner to always have a clear idea of the value and priority of the stories in the backlog - especially those likely to be candidates for the next iteration or two.
Excellent explanation. I am learning about Scrum world. I have some questions, if you don't mind. :) I guess that it is the P.O who writes the Epics and User Stories in the initial engagement with customer/sponsor of the project? I think that would be great to see a video illustrates how everything really starts. As I guess that sometimes the Product Backlog starts without a Scrum Team formed yet, is that correct? I am curious to know this initial "phase" in Scrum, something equivalent to business case or project charter in waterfall. Finally, who adds the story points per user story? Is it the developers during the Sprint Planning session? Thanks so much, much appreciate your videos.
Thank you, Fabio. You ask a lot of questions here and, truly, I am not an expert in Scrum. For this level of detail, I think you're going to need a more experienced guide - either a different channel, a training course, or a good book. But I would start with The Scrum Guide, which is a free download from Scrum.org. It's written by the two originators of the Scrum methodology for software development and is about as authoritative as you'll get - and it's available in many languages: scrumguides.org
I don't think I agree. Lots of things matter. But that? Really? Even in the military (western militaries in democratic countries), obedience is not more important than integrity. Unlawful orders do not requireobeidience. I'd rather my direct reports think for themselves and have integrity. If they can see a better solution than the one I asked for, that's good for them, for me, and for the project.
Task-based planning is a different way of working. The developers in Scrum will define their own way of working on a User Story, based on their assessment of how to tackle it.
I don't get you. What are you asking? A user story describes capabilities. In agile the team determines the features needed to deliver the capabilities. Is this what you need to know? Effectively, this is a for of capabilities-based planning.
