*Quick summary:* - Scrum is a specific agile software development process - Agile software development processes focus on developing iteratively (basically, intermingling design and development) - In Scrum, you write the desired features of your software as "user stories" (which are formatted like so: "as a user, I want to be able to check my bank account balance") - You choose a subset of the user stories for a particular release (e.g. version 0.1), this subset is called the release backlog - You break up the release backlog into a bunch of sprints ("sprint backlog") - For each user story in a sprint, you estimate the amount of time it will take you to compete that user story - You assign these user stories to developers - As developers work on their user story, they update how much time is remaining on their user story - the burndown chart shows you how much time remains in order to complete all the user stories in the sprint - ideally, as the developers work on their user stories, the burndown chart should show that there is less and less time remaining in order to complete all user stories in the sprint Hope that was helpful to someone! Thanks for the video, very clear and concise.
EZ money from people who think a University has something more to offer than the infinite amount of free knowledge online. My my my, when will people learn.
I have spent hours and hours to get the correct and simple content on Agile and literally got frustrated after a while. But then here comes this video which give me everything i needed to know about Scrum Agile in short and simple video with real time project reference. You guys are awesome and saved my lot of time. Thanks a lot keeps posting such informative video.
I was really late on studying for my finals in software development, and haven't worked with scrum with he internships i followed so far. You really nailed in explaining the concept in 10 minutes, i took notes from your video and they have helped me a lot in my current study-sprint for today :) Thank you a million times Hamid.
Amazing synthesis of information within 10 minutes, I am an absolute illiterate on SCRUM and I grasped the structure of it and how it works perfectly, great job!
one of the best professional videos I've ever watched. I learned a lot in just 8 minutes! I love to be a product manager and am searching a lot through the web, this was one of the best, hands down!
I just want to say this was the best tutorial on Scrum I've seen, and I've gone through literally over a couple dozen. Can't believe how easy you've made it seem, and so clear. You rock!
A great video for those who want to get into Scrum or are just starting out. This explanation is brief and fast-paced, yet chock-full of information. Well executed video.
This is by far, the most brilliant illustration and explanation of agile scrum I've seen here in youtube. I like it when the person goes directly to the point, normally people tends to speak too many words for a certain topics which will eventually lead us to a more complicated way. Good job and Godbless.
Very useful video. Its smooth, on point and easy to follow. Its got all and only the critical content on the basics of SCRUM. Also the narration is very fluid and comfortable to the listener. it s evident that the video has been refined and revised to communicate everything effectively. GOOD JOB.
The explanation of the Scrum framework's emphasis on iterative development, frequent delivery, and continuous adaptation. The roles, ceremonies, and artifacts it covers are the core components that enable Scrum's effectiveness. The concept of self-organizing teams aligning with modern business needs for flexibility and collaboration is particularly insightful.
I changed my working style to Agile Scrum back in 2007 and I am not coming back to old work habits. It also changed my communications style. For this methodology to work, everybody in the company must be involved as "team players".
In a Linkedin post, I pointed out that this video has dozens of inaccuracies. I've decided to post my point by point clarifications for anyone that cares to read them: 0:29:User Stories are not a Scrum practice, they come from XP. While commonly used, they are not Scrum. This will be a common theme in these comments. 0:50:Release planning is again not a core aspect of Scrum. Scrum is built to inspect and adapt at the end of every sprint, not predict or plan exactly what will be delivered in a multi-sprint release 1:14:The description of the Scrum Master is pretty incomplete. They don't make sure the project progresses smoothly, they ensure the team is working collaboratively and inspecting and adapting as they go. They aren't required to set up meetings (the "team admin" dysfunction, they don't monitor the progress (the development team is self-managing, so they do that). Since Scrum is intentionally silent about release planning, it's not part of the core job description to facilitate it. The Scrum Master is NOT a lot like a Project Manager - they don't manage the project. The help the team. The team manages the project. The Scrum Master name is regrettable, but it's not just a relabeling of Project Manager that implies jujitsu skills. 1:37:The description of the Development Team members implies a Code-Test sequence, while most development teams will eventually adopt a test-driven approach. There are no official roles on a development team, only collaborative team members with skills in various areas. 1:41:Executives "generally get in the way" is a frustrating meme in the Agile community. It creates an us vs. them dynamic that doesn't help agility thrive. Agile executives are a rare breed, but they exist, or can learn to take an Agile approach, but not when we start with the premise that they just get in the way. 1:46:There is an entire section here on Release Planning. Again, not a core aspect of Scrum. There are many concepts in this section that I would not recommend, even when teams need to do release planning, such as picking all of the User Stories up front, creating a separate Release Backlog (there is no such artifact in Scrum) the team doesn't prioritize the User Stories, the Product Owner does, though effective ones will do that collaboratively with input from the team and stakeholders. 2:27:"Story points don't answer the question of when will my product ship". Actually, they do, and in my experience, more reliably than time estimates. This whole section on estimates shows a lack of experience or understanding for how Story Points and Velocity work. I recommend reviewing Mike Cohn's Agile Estimation and Planning book for all the details here. I could write an entire post on the drawbacks of time estimates (lack of collaborative estimation, overlooking the integration pieces, etc.). 3:19:"plan out several sprints". This is a dysfunction. We don't do this for many reasons. Slotting Product Backlog Items in sprints tends to bias us against inspecting and adapting at the end of each Sprint. That takes away one of the two core benefits of Scrum: the ability to adapt the Product Backlog based on feedback after each Sprint. 3:24:Calling Sprints milestones again overlooks the important Inspect and Adapt capability upon which Scrum is founded. In traditional projects, milestones are just checkpoints towards a shippable product. In Scrum, each Sprint results in a shippable product. 3:33:While it's theoretically possible to do a two day Sprint, I've never seen one that short. The event overhead would be too high and the timebox too short to get something meaningful to an inspectable state. Two days also overlooks the "human cadence" aspect of Scrum, where the Sprint cadence mimics other standard cadences, like a week, two weeks, or a month. 3:41:Specifying from 2-12 sprints for a release is just confusing to me. Releases and Sprints are decoupled in Scrum. Many Scrum teams release many times during a Sprint. Every team actually using Scrum as intended should be shippable every Sprint. 3:47:Sprint Backlogs are not created during release planning, and are not just a subset of the Product Backlog (or Release Backlog to use the video creator's terminology). Sprint Backlogs are created just in time, at the beginning of each Sprint, during the Sprint Planning meeting. The development team pulls items from the Product Backlog at that time into the Sprint Backlog for just that Sprint, and then does additional planning to figure out HOW they will deliver those items during the Sprint. 4:09:"A late finish of the Sprint" never happens in Scrum. Sprints are strictly timeboxed, so they don't get extended. The team may cut some scope to meet the timebox, not the other way around. 4:18:The author of the video is confusing two practices, neither of which are required in Scrum. A Sprint Burndown chart gives the Development Team visibility into their progress during the Sprint towards completing the items they've pulled into the Sprint Backlog. It's a common tool but not the only way to do this. A release burndown chart gives the Product Owner insight into progress towards a release goal. I prefer to use a Burnup chart at the release level in this context, since it provides a more elegant visualization for Scope is changing, which happens on nearly every multi-sprint release. 4:20:The burndown chart is far and away NOT the number one reason for Scrum's popularity. Maybe in the author's experience that's true, but not broadly speaking. The number one reason for Scrum's popularity is probably that you can get certified in it (cynical reason), or that it allows us to iteratively improve our approach through Sprint Retrosepctives and the Product through Sprint Reviews, so that the thing we build is actually what customers want. It's also just a more human way to do work, meaning it aligns with how software developers naturally thing about the craft of software development. 4:51:I've never heard the term Burndown Velocity before. The author is describing a trendline. Velocity, as it was popularized by Mike Cohn in the previously mentioned book, is the average number of Story Points completed in a Sprint. It's also how Story Points answer the question of when the product will ship. It's not a daily metric, it is a Spint by Sprint average. The rest of this section on Burndown Charts is pretty accurate, but applied to the Sprint Burndown, not the release burndown. 6:42: The author skips the Sprint Review entirely, a core Inspect and Adapt step of Scrum. 7:00:This section of the video is a sales pitch for OnTime, one of several ALM tools available. When I coach teams, I ALWAYS encourage them to start with a physical board so that they can tweak the process as they Inspect and Adapt. Any tool vendor will have a specific vision for how Scrum is used, and it is often (as in this video) not aligned with core Scrum concepts. The teams that start with a tool like this start doing Scrum according the tool vendors vision, rather than iteratively figuring out how best to use Scrum in their context. That's not to bash OnTime - all tool vendors have the same drawback. 7:34:Well, the tool vendor here bashes physical boards, implying that they're like the abacus of visualizing the work. I get it, they're selling a tool, but this is a recommendation and viewpoint that I strongly disagree with. 7:45:The Product Backlog is more than just a collection of User Stories. This description leaves out two core aspects of a Product Backlog. First, it is Ordered (or prioritized). Second, it is emergent, dynamic, and always changing as we learn (through the absent-from-this-video) Sprint Review meetings what is most important to build next. 7:50:The rest of the video summarizes the earlier points, and since I've already commented on them, I won't reiterate them here. Closing thoughts:I actually know some Axosoft folks, and they're a fine group of people doing good work. I don't like coming off as overly critical, but if anyone views this video as a key summary of how Scrum works, they're going to get the wrong impression. I'd reccomend, instead, that you check out the free videos Icreated here: ruclips.net/video/eRlIKDTetIs/видео.html
I'm an Iranian Person, I am so proud and happy that some guys like you exist, although being a brilliant Person is not related to belong to a especial nationality. It was a great video, helped us a lot. we are making an ride sharing system and software in Iran called Nettro.
Awesome video ...Thanks for the upload...... Updating this comment after 7 years, This is still my favourite video ,none can explain scrum as deep and as quick as you , its a definite Bombarding!!
Good info! I was able to capture some really great notes. PM terms: to know: user stories, scrum, product backlogs, team roles, sprints, burndown chart - provides the amount of work remaining in sprints and helps to keep the team on track, PRODUCT OWNER, Scrum master, users, release planning, build-test-use the product, estimates - do these in hours for smaller estimates, story points, standards, release backlog, sprints: short duration milestones - up to 30 days - shorter the release cycle the shorter the sprints should be, estimated completion date
Just came across this your comment amd I hope you're doing great as a scrum master now. I'm trying to transition to tech too with major focus on scrum master. Hopefully I'll become a scrum master like you soon.
The overview of the Agile Scrum methodology presented in this video was awesome! It covered the basic components of Scrum in such a way that was very helpful to my learning of all things Agile and Scrum. Very impressive!
Hi, Hamid Shojaee... thanks to KEEP this video on RUclips - I used it for some novice people to know better about Scrum - and it was really nice to find it here yet! All the best for you and AxoSoft Ninjas Team ;-)
In my experience developers update the time sheet (long existed) with the activities they have done and most of the time they just punch in some numbers because it is such a hassle and they want to get it done with and get back to work. Can I say this is probably the key hindrance to scrum and what can be done? I've been both a developer and a PM.
An operations vs sales dilemma question. The video content is the actual product that adds value, but the accessories like whistling music is to make-feel-good selling point. Which works as commented above for some.
Great vid, I have been part of teams and participated in the process, but I'm still new to it, I have an interview this morning and I needed a fast review of all the terminology so if I could EXPLAIN all the terms in case they pop quiz me, to throw me off. Stories --backlogs sprints buckets burndown charts velocity -good.
💯Definitely the Best. Love the way you broke it down and explain everything about the subject. 👌🤗 It seems like ontime is a great tool to incorporate in an enterprise, which is built by the team who understands on how to like the technology, people, constraints in an efficient order to deliver it on schedule. Nice☆
I am Aaron Franklin. I'm learning about Business intelligence and data analytics. Watching your video was very helpful in my understanding more about how the workflow works. Thanks so much for making it. Your product OnTime looks very useful, unfortunately at this time I don't have any use for it but as I continue on this path, I might in the future. Thanks again.
This is by far the best introduction to Scrum and facilitates the terminology in a fun way using brilliant animation/graphical images and articulates the framework in a clear and concise manner. No jibberish. Thanks a lot. Really helpful ..!!!
He provided excellent bit sized info in just 8-9 min and you could not get that even with a bigger course. Please show some gratitude and he never did too much sales pitch too. The guy has stuff so his work speaks for itself
Estimating in hours is the big mistake in this video. User stories estimated in days or months is even worse. Storypoints are very important to eliminate the debates on hourly estimates ("I could do it in 5 hours!") and to disconnect the story from who will develop it (as ShriKant says below). I would not use this video as a Scrum orientation.
What an eloquent explanation of scrum! Good enough for a 6th grader to understand and engaging enough for the professional to stay tuned in. I like it!
It's a shame about the misinformation about story points. Estimating in hours/days misses an important aspect of Agile/Scrum. Story points most certainly do tell you when your product will ship, but only when taken together with the team's velocity, which can only be calculated after a few sprints. So story points divided by velocity = when your product will ship (in sprints).
I thought the important aspect of relative estimation was to elicit discussion, particularly when different Developers provided different estimates. It may highlight a difference in understanding/knowledge that could be useful. It also serves as a shield to personal velocity; meaning we are agreeing on the distance, not the running speed. Therefore a junior and senior would agree it was 3 points, despite the fact a senior could complete it in an hour, while a junior may take over 4 hours. It might be hard for different skill sets to estimate a task in a common time, given they would take different times to complete.
I tend to think Agile/Scrum/flavor of the day methodologies are composed of two parts. The first are the obvious things you should do: breaking problems down into smaller pieces, testing, etc. You don't need a special word for this: it's common sense. The rest of them comes up with arbitrary rules and labels or juvenile names like the "Scrum master" or the "Product Owner" or the "Product Backlog" or "Sprints". Why do you need this specific of a set of rules? Can't intelligent adults just decide, "Hey, we should have someone/some group of people responsible for this aspect of the product" on a project by project basis?
it's a model that was devised, and in order to describe it, you need to constantly refer to its subjects (players and components). what better way to do that than to give them names? i do think that the names are not as straight-forward as they could be. "scrum master" could just simply be "project manager" or "producer," "back log" could simply be "features list," but in the end, you're still referring to the same concept.
I think you're restating the problem, though. It's a devised model. Instead of calling someone "the scrum master" why wouldn't you just say, "I think we need someone to be responsible for x on this project", and call them Lisa or George or whatever. The irony is that this kind of thinking exactly mirrors what it is purportedly trying to combat. You're starting off by saying, "we shouldn't define the solution to our project before we get there". Then on the other hand you're saying, "every project needs a scrum master and a product owner and sprints and ...".
+Ryan Williams So when you move on to the next project with a different set of folks, what would you say? "We need a Lisa or George for this project too!" It's just a standardized term so that everyone understands. Any methodology is just that - a standardized set of terms given to standardized way of doing things, so that everyone talks in the same language.
I was very interested until you said you prefer hourly estimates vs story points. It is very easy to estimate when something will be done but you need to know the teams velocity first. Hours don't work with difficulty estimating.
God! Man you save my life, I have been here googling and googling and in 10 Min, you just told me what I need to know to start with Scrum and it is amazing! Un très grand merci :-)
Some gotchas in the video. Estimating in hours can be recipe of disaster and brings out conflicts while estimating as a team. Hour estimation is mainly dependent on the expertise of the team-member in question and cannot be termed as team-estimate. Scrum Master is NOT like a Project Manager. By definition she's a servant-leader focused towards removing impediments and shielding the team from external interferences. Important ceremony Demo is missing. Lot more focus on burndown chart as that's the selling idea of the video anyway.
ShriKant Vashishtha user stories must definitely be estimated using Points, however tasks will be translated in Hours to quickly visualize issues on teams progress and maturity
I tend to agree with Sanjay. The video should say "The ScrumMaster is a LOT UNlike a project manager". A project manager oversees the deliverables, whereas a ScrumMaster oversees the delivery process. There are more likeness between a PM and a PO than a ScrumMaster.
It is. For instance just try having a daily meeting where everyone shows up and shows up on time and then try constraining it to 15 minutes. Those meetings often result in excuses given and accusations made against others that are present as to why they can't get whatever done, which usually degrades into a scream fest that you have to somehow control without any authority over those involved. And that's just the start of your day. And those executives that "generally get in the way"? That is an extreme understatement. They constantly harass and irritate you for updates and lengthy explanations as to why something isn't going quite as planned, as well as making you develop lengthy "action plans" as to what you are going to do about it. This while you are trying to focus on all the dozens of different complex aspects of the project each day.
As someone who has worked on this type of team, it is actually pretty simple. It can be pretty annoying having a meeting everyday about what you did the previous day when the work is actually pretty slow and you are trying to focus on the same thing for days. Here it sounds a bit complicated but it's not as bad. Being a developer, I have never had to deal with the executives that are mentioned in this video. They usually bother the managers above you. This methodology seems a bit unpractical as it makes you waste 30-60 minutes of your day trying to conduct a meeting, but in the long run it is very useful.
I guess you need to have very specific people with very specific experience and training. I can't imagine anyone from my office able to work like this even after some training.
*Quick summary:*
- Scrum is a specific agile software development process
- Agile software development processes focus on developing iteratively (basically, intermingling design and development)
- In Scrum, you write the desired features of your software as "user stories" (which are formatted like so: "as a user, I want to be able to check my bank account balance")
- You choose a subset of the user stories for a particular release (e.g. version 0.1), this subset is called the release backlog
- You break up the release backlog into a bunch of sprints ("sprint backlog")
- For each user story in a sprint, you estimate the amount of time it will take you to compete that user story
- You assign these user stories to developers
- As developers work on their user story, they update how much time is remaining on their user story
- the burndown chart shows you how much time remains in order to complete all the user stories in the sprint
- ideally, as the developers work on their user stories, the burndown chart should show that there is less and less time remaining in order to complete all user stories in the sprint
Hope that was helpful to someone!
Thanks for the video, very clear and concise.
Thank you so much
Thank you! 👍🏾👌🏾
Thank you
Thank u
THANK YOU! ~ A tired grad school student
I paid my university $4187 to do a course and they give me the link to this video
Lmao
sue your university
Funny story, two of my lecturers sent us here smh
now I feel like i saved $4187.... awesome baby ! Yang2020
EZ money from people who think a University has something more to offer than the infinite amount of free knowledge online. My my my, when will people learn.
"He's a lot like a project manager, but that's quite a boring title, so we will call him Scrum Master to imply he knows some jiujitsu" 😂 😂 😂 😂 LOL
Found this video more than 3years ago and even today it's still the best Scrum video around. Thanks Guys!
2024 and still valid. 😊
7:51 Review / Summary
- Product Backlog > Release Backlogs > Sprint Backlogs (short-duration milestones)
- Monitor progress of Sprints with Burndown Charts
- Daily Scrum Meetings to ensure everything is on track
- Retrospective Meetings after each Sprint for fine-tuning
small addition, Burndown chart is feed by hours completed on User Stories.
Thanks this is useful
Thank you, this makes the whole process uncomplicated
this is how a video should be made, perfect words, perfect video editing, and a piece of perfect background music.. respect....
"And these guys, they generally get in the way, but you can't get a project done without them."
i felt that lol
I have spent hours and hours to get the correct and simple content on Agile and literally got frustrated after a while. But then here comes this video which give me everything i needed to know about Scrum Agile in short and simple video with real time project reference. You guys are awesome and saved my lot of time. Thanks a lot keeps posting such informative video.
Glad I was properly caffeinated prior to watching this video! I love the pace and visual aids. Very well done.
I was really late on studying for my finals in software development, and haven't worked with scrum with he internships i followed so far. You really nailed in explaining the concept in 10 minutes, i took notes from your video and they have helped me a lot in my current study-sprint for today :) Thank you a million times Hamid.
Believe me I found this presentation the best ever THANK YOU
Too bad, it is chock full of inaccuracies. Good summary of the factual errors: ruclips.net/video/XU0llRltyFM/видео.html&lc=Ugw22fmi6bZsli4iXNZ4AaABAg
Amazing synthesis of information within 10 minutes, I am an absolute illiterate on SCRUM and I grasped the structure of it and how it works perfectly, great job!
one of the best professional videos I've ever watched. I learned a lot in just 8 minutes! I love to be a product manager and am searching a lot through the web, this was one of the best, hands down!
Could not agree more!
I just want to say this was the best tutorial on Scrum I've seen, and I've gone through literally over a couple dozen. Can't believe how easy you've made it seem, and so clear. You rock!
A great video for those who want to get into Scrum or are just starting out. This explanation is brief and fast-paced, yet chock-full of information. Well executed video.
No BS in this video. Straight to the point and articulate. All meat and no fluff. Nice job Hamid.
Excellent video with a very good coverage in a short time and it is never boring, not even for a sec.
Am a PMP, what an amazing gist of scrum, who else can give such a quick explanation of this tech, brilliant man
Thanks for the concise overview. Im a midlife mum switching from education to tech--every minute is precious!
This is by far, the most brilliant illustration and explanation of agile scrum I've seen here in youtube.
I like it when the person goes directly to the point, normally people tends to speak too many words for a certain topics which will eventually lead us to a more complicated way.
Good job and Godbless.
Very useful video. Its smooth, on point and easy to follow. Its got all and only the critical content on the basics of SCRUM. Also the narration is very fluid and comfortable to the listener. it s evident that the video has been refined and revised to communicate everything effectively. GOOD JOB.
It's also full of errors, as pointed out above.
The explanation of the Scrum framework's emphasis on iterative development, frequent delivery, and continuous adaptation. The roles, ceremonies, and artifacts it covers are the core components that enable Scrum's effectiveness. The concept of self-organizing teams aligning with modern business needs for flexibility and collaboration is particularly insightful.
Best video ever saw about explanation of scrum,thanks alot .
Best video on scrum on youtube. The others just hype it up without saying shit about appliance. Thank you
I changed my working style to Agile Scrum back in 2007 and I am not coming back to old work habits. It also changed my communications style. For this methodology to work, everybody in the company must be involved as "team players".
The problem with "team players" only is that the team becomes the "mob" and the individuality that promotes innovation is lost.
This video is very awesome, I went from zero understanding, to a pretty clear idea of what to expect from a scrum environment. EPIC
In a Linkedin post, I pointed out that this video has dozens of inaccuracies. I've decided to post my point by point clarifications for anyone that cares to read them: 0:29:User Stories are not a Scrum practice, they come from XP. While commonly used, they are not Scrum. This will be a common theme in these comments.
0:50:Release planning is again not a core aspect of Scrum. Scrum is built to inspect and adapt at the end of every sprint, not predict or plan exactly what will be delivered in a multi-sprint release
1:14:The description of the Scrum Master is pretty incomplete. They don't make sure the project progresses smoothly, they ensure the team is working collaboratively and inspecting and adapting as they go. They aren't required to set up meetings (the "team admin" dysfunction, they don't monitor the progress (the development team is self-managing, so they do that). Since Scrum is intentionally silent about release planning, it's not part of the core job description to facilitate it. The Scrum Master is NOT a lot like a Project Manager - they don't manage the project. The help the team. The team manages the project. The Scrum Master name is regrettable, but it's not just a relabeling of Project Manager that implies jujitsu skills.
1:37:The description of the Development Team members implies a Code-Test sequence, while most development teams will eventually adopt a test-driven approach. There are no official roles on a development team, only collaborative team members with skills in various areas.
1:41:Executives "generally get in the way" is a frustrating meme in the Agile community. It creates an us vs. them dynamic that doesn't help agility thrive. Agile executives are a rare breed, but they exist, or can learn to take an Agile approach, but not when we start with the premise that they just get in the way.
1:46:There is an entire section here on Release Planning. Again, not a core aspect of Scrum. There are many concepts in this section that I would not recommend, even when teams need to do release planning, such as picking all of the User Stories up front, creating a separate Release Backlog (there is no such artifact in Scrum) the team doesn't prioritize the User Stories, the Product Owner does, though effective ones will do that collaboratively with input from the team and stakeholders.
2:27:"Story points don't answer the question of when will my product ship". Actually, they do, and in my experience, more reliably than time estimates. This whole section on estimates shows a lack of experience or understanding for how Story Points and Velocity work. I recommend reviewing Mike Cohn's Agile Estimation and Planning book for all the details here. I could write an entire post on the drawbacks of time estimates (lack of collaborative estimation, overlooking the integration pieces, etc.).
3:19:"plan out several sprints". This is a dysfunction. We don't do this for many reasons. Slotting Product Backlog Items in sprints tends to bias us against inspecting and adapting at the end of each Sprint. That takes away one of the two core benefits of Scrum: the ability to adapt the Product Backlog based on feedback after each Sprint.
3:24:Calling Sprints milestones again overlooks the important Inspect and Adapt capability upon which Scrum is founded. In traditional projects, milestones are just checkpoints towards a shippable product. In Scrum, each Sprint results in a shippable product.
3:33:While it's theoretically possible to do a two day Sprint, I've never seen one that short. The event overhead would be too high and the timebox too short to get something meaningful to an inspectable state. Two days also overlooks the "human cadence" aspect of Scrum, where the Sprint cadence mimics other standard cadences, like a week, two weeks, or a month.
3:41:Specifying from 2-12 sprints for a release is just confusing to me. Releases and Sprints are decoupled in Scrum. Many Scrum teams release many times during a Sprint. Every team actually using Scrum as intended should be shippable every Sprint.
3:47:Sprint Backlogs are not created during release planning, and are not just a subset of the Product Backlog (or Release Backlog to use the video creator's terminology). Sprint Backlogs are created just in time, at the beginning of each Sprint, during the Sprint Planning meeting. The development team pulls items from the Product Backlog at that time into the Sprint Backlog for just that Sprint, and then does additional planning to figure out HOW they will deliver those items during the Sprint.
4:09:"A late finish of the Sprint" never happens in Scrum. Sprints are strictly timeboxed, so they don't get extended. The team may cut some scope to meet the timebox, not the other way around.
4:18:The author of the video is confusing two practices, neither of which are required in Scrum. A Sprint Burndown chart gives the Development Team visibility into their progress during the Sprint towards completing the items they've pulled into the Sprint Backlog. It's a common tool but not the only way to do this. A release burndown chart gives the Product Owner insight into progress towards a release goal. I prefer to use a Burnup chart at the release level in this context, since it provides a more elegant visualization for Scope is changing, which happens on nearly every multi-sprint release.
4:20:The burndown chart is far and away NOT the number one reason for Scrum's popularity. Maybe in the author's experience that's true, but not broadly speaking. The number one reason for Scrum's popularity is probably that you can get certified in it (cynical reason), or that it allows us to iteratively improve our approach through Sprint Retrosepctives and the Product through Sprint Reviews, so that the thing we build is actually what customers want. It's also just a more human way to do work, meaning it aligns with how software developers naturally thing about the craft of software development.
4:51:I've never heard the term Burndown Velocity before. The author is describing a trendline. Velocity, as it was popularized by Mike Cohn in the previously mentioned book, is the average number of Story Points completed in a Sprint. It's also how Story Points answer the question of when the product will ship. It's not a daily metric, it is a Spint by Sprint average. The rest of this section on Burndown Charts is pretty accurate, but applied to the Sprint Burndown, not the release burndown.
6:42: The author skips the Sprint Review entirely, a core Inspect and Adapt step of Scrum.
7:00:This section of the video is a sales pitch for OnTime, one of several ALM tools available. When I coach teams, I ALWAYS encourage them to start with a physical board so that they can tweak the process as they Inspect and Adapt. Any tool vendor will have a specific vision for how Scrum is used, and it is often (as in this video) not aligned with core Scrum concepts. The teams that start with a tool like this start doing Scrum according the tool vendors vision, rather than iteratively figuring out how best to use Scrum in their context. That's not to bash OnTime - all tool vendors have the same drawback.
7:34:Well, the tool vendor here bashes physical boards, implying that they're like the abacus of visualizing the work. I get it, they're selling a tool, but this is a recommendation and viewpoint that I strongly disagree with.
7:45:The Product Backlog is more than just a collection of User Stories. This description leaves out two core aspects of a Product Backlog. First, it is Ordered (or prioritized). Second, it is emergent, dynamic, and always changing as we learn (through the absent-from-this-video) Sprint Review meetings what is most important to build next.
7:50:The rest of the video summarizes the earlier points, and since I've already commented on them, I won't reiterate them here.
Closing thoughts:I actually know some Axosoft folks, and they're a fine group of people doing good work. I don't like coming off as overly critical, but if anyone views this video as a key summary of how Scrum works, they're going to get the wrong impression. I'd reccomend, instead, that you check out the free videos Icreated here: ruclips.net/video/eRlIKDTetIs/видео.html
youre awesome
@@annon123 Thanks!!!
But this video is pretty familiar with the scrum I have been reading at my university.
❤
I'm an Iranian Person, I am so proud and happy that some guys like you exist, although being a brilliant Person is not related to belong to a especial nationality. It was a great video, helped us a lot. we are making an ride sharing system and software in Iran called Nettro.
Thanks! Clear explanation, informative video, and the plug to your product actually made sense.
This is one of best, most concise videos on ANY topic on RUclips. Dude! Well done!!!
Wow! Impressed with how much info you conveyed in such a small amount of time. I really want to learn this process!
I bet he used scrum to produce this video.
Great video for the beginner. Easy to understand with a confident voice and no accent. I appreciate the brevity without sacrificing content.
Thanks a lot for making the concept to understand in short period.. It's really a good one.
Awesome video ...Thanks for the upload...... Updating this comment after 7 years, This is still my favourite video ,none can explain scrum as deep and as quick as you , its a definite Bombarding!!
Phew! That was a marathon presentation.....Good and concise video
Good info! I was able to capture some really great notes.
PM terms: to know: user stories, scrum, product backlogs, team roles, sprints, burndown chart - provides the amount of work remaining in sprints and helps to keep the team on track, PRODUCT OWNER, Scrum master, users, release planning, build-test-use the product, estimates - do these in hours for smaller estimates, story points, standards,
release backlog, sprints: short duration milestones - up to 30 days - shorter the release cycle the shorter the sprints should be, estimated completion date
Loved this! First video that I laughed at and engaged in. Trying to brush up before my final Scrum Master interview tomorrow. Thank you!
Just came across this your comment amd I hope you're doing great as a scrum master now. I'm trying to transition to tech too with major focus on scrum master. Hopefully I'll become a scrum master like you soon.
I've came to this video multiple times over my consulting career to brush up, one of the best out there. Thank you Hamid.
That pretty much scrums it up, thanks.
get... out
There are scientific papers online which are very confusing. This video explains the concept simply and effectively. Thank you!
The overview of the Agile Scrum methodology presented in this video was awesome! It covered the basic components of Scrum in such a way that was very helpful to my learning of all things Agile and Scrum. Very impressive!
Hi, Hamid Shojaee... thanks to KEEP this video on RUclips - I used it for some novice people to know better about Scrum - and it was really nice to find it here yet! All the best for you and AxoSoft Ninjas Team ;-)
Woa! You explained it Sir clearly. Thank you!
I'm learning, somehow. ^_^
Hehe. good for you my Deborah. :*
Its just amazing video to make any novice understand what scrum is .just ultimate.
Great video, fast paced, straight to the point and upbeat. I feel more informed about Scrum.
+Xander T I think so too. Also I am excited to use Scrum after this video :D
An amazing condensed version of SCRUM that is easier to understand , and the voice is just outstanding!
Perfect! You are an impressive speaker. Keep up the good work
My instructor; Mr. Lokesh told me to go through this video.
Thanks to him as well the presenter Mr. Hamid who make the whole thing a glass of water.
In my experience developers update the time sheet (long existed) with the activities they have done and most of the time they just punch in some numbers because it is such a hassle and they want to get it done with and get back to work. Can I say this is probably the key hindrance to scrum and what can be done? I've been both a developer and a PM.
one of the best video i have seen in my 12 years of career, its super quick, informative and has all the topics, thanks.
I just knew the term "scrum" before watching this video. But i have plenty of scrum terminology and concepts now. thanks to you.
This is the way that videos should be made. Precise , Fact paced and informative with a bit of humor. You my friend deserve an Oscar !!!1
Cheers
Great explanation. Thank you!
One of the best and time savvy visual representation of the scrum!!!
I literally laughed out loud at the Scrum Master joke... Thanks for that!
It's weird how much this dudes voice comforts me.. feels like some kind of core memory I don't remember. 😅
Why do they have to put whistling musics everywhere? Why???
Whistling is love. Whistling is life.
Whistle while you work... disney-esque happiness?
that's borrowed from Maroon 5 song - moves like Jagger... move wuuuu....
An operations vs sales dilemma question. The video content is the actual product that adds value, but the accessories like whistling music is to make-feel-good selling point. Which works as commented above for some.
Music here was a distraction. When you have serious business, avoid distractors.
No words! Awesomtacular. I worked in scrum and I liked it as much as I liked working in scrum!
Even this is a video recorded for commercial purpose, still this is a good video
Great vid, I have been part of teams and participated in the process, but I'm still new to it, I have an interview this morning and I needed a fast review of all the terminology so if I could EXPLAIN all the terms in case they pop quiz me, to throw me off. Stories --backlogs sprints buckets burndown charts velocity -good.
Best ad ever! thank you :)
That's a great video Hamid. I attended hours of scrum class but it was this comprehensive
💯Definitely the Best. Love the way you broke it down and explain everything about the subject. 👌🤗
It seems like ontime is a great tool to incorporate in an enterprise, which is built by the team who understands on how to like the technology, people, constraints in an efficient order to deliver it on schedule.
Nice☆
I really understood. I am marketing for a Scrum client and it helps to understand terminology. Thanks April Christian-Davis , Breakout Marketing Group
And just like that I'm going to pass this software architecture course. Next I'd like to ask for tuition assistance in a 10 minute video.
I am Aaron Franklin. I'm learning about Business intelligence and data analytics. Watching your video was very helpful in my understanding more about how the workflow works. Thanks so much for making it. Your product OnTime looks very useful, unfortunately at this time I don't have any use for it but as I continue on this path, I might in the future. Thanks again.
Dude amazing work thoroughly impressed. I would like to know Agile as well.
T
This is by far the best introduction to Scrum and facilitates the terminology in a fun way using brilliant animation/graphical images and articulates the framework in a clear and concise manner. No jibberish. Thanks a lot. Really helpful ..!!!
Holie smolie, I was 95% into the video before realizing it was a sales pitch!
At least they offered value :v
whats wrong with a sales pitch with information and value
He provided excellent bit sized info in just 8-9 min and you could not get that even with a bigger course. Please show some gratitude and he never did too much sales pitch too. The guy has stuff so his work speaks for itself
What's the problem? It is a win-win situation. We get a free short introduction to scrum and he has a platform to promote its product.
One of the best Videos explaining Scrum! Great Job Guys!
Estimating in hours is the big mistake in this video. User stories estimated in days or months is even worse. Storypoints are very important to eliminate the debates on hourly estimates ("I could do it in 5 hours!") and to disconnect the story from who will develop it (as ShriKant says below). I would not use this video as a Scrum orientation.
What an eloquent explanation of scrum! Good enough for a 6th grader to understand and engaging enough for the professional to stay tuned in. I like it!
It's a shame about the misinformation about story points. Estimating in hours/days misses an important aspect of Agile/Scrum. Story points most certainly do tell you when your product will ship, but only when taken together with the team's velocity, which can only be calculated after a few sprints. So story points divided by velocity = when your product will ship (in sprints).
I thought the important aspect of relative estimation was to elicit discussion, particularly when different Developers provided different estimates. It may highlight a difference in understanding/knowledge that could be useful. It also serves as a shield to personal velocity; meaning we are agreeing on the distance, not the running speed. Therefore a junior and senior would agree it was 3 points, despite the fact a senior could complete it in an hour, while a junior may take over 4 hours. It might be hard for different skill sets to estimate a task in a common time, given they would take different times to complete.
To date I didnt anything excellent than this. Really appreciate your work and effort !
I tend to think Agile/Scrum/flavor of the day methodologies are composed of two parts. The first are the obvious things you should do: breaking problems down into smaller pieces, testing, etc. You don't need a special word for this: it's common sense.
The rest of them comes up with arbitrary rules and labels or juvenile names like the "Scrum master" or the "Product Owner" or the "Product Backlog" or "Sprints". Why do you need this specific of a set of rules? Can't intelligent adults just decide, "Hey, we should have someone/some group of people responsible for this aspect of the product" on a project by project basis?
it's a model that was devised, and in order to describe it, you need to constantly refer to its subjects (players and components). what better way to do that than to give them names?
i do think that the names are not as straight-forward as they could be. "scrum master" could just simply be "project manager" or "producer," "back log" could simply be "features list," but in the end, you're still referring to the same concept.
I think you're restating the problem, though. It's a devised model. Instead of calling someone "the scrum master" why wouldn't you just say, "I think we need someone to be responsible for x on this project", and call them Lisa or George or whatever. The irony is that this kind of thinking exactly mirrors what it is purportedly trying to combat. You're starting off by saying, "we shouldn't define the solution to our project before we get there". Then on the other hand you're saying, "every project needs a scrum master and a product owner and sprints and ...".
+Ryan Williams So when you move on to the next project with a different set of folks, what would you say? "We need a Lisa or George for this project too!" It's just a standardized term so that everyone understands. Any methodology is just that - a standardized set of terms given to standardized way of doing things, so that everyone talks in the same language.
This video is very helpful. SCRUM understood in 10 mins. Kudos
I was very interested until you said you prefer hourly estimates vs story points. It is very easy to estimate when something will be done but you need to know the teams velocity first. Hours don't work with difficulty estimating.
It is a greatest SCRUM explanation I've ever seen in 10 minutes! Thanks!
Read Jeff Sutherland's book on Scrum. A great read.
God! Man you save my life, I have been here googling and googling and in 10 Min, you just told me what I need to know to start with Scrum and it is amazing!
Un très grand merci :-)
Some gotchas in the video. Estimating in hours can be recipe of disaster and brings out conflicts while estimating as a team. Hour estimation is mainly dependent on the expertise of the team-member in question and cannot be termed as team-estimate.
Scrum Master is NOT like a Project Manager. By definition she's a servant-leader focused towards removing impediments and shielding the team from external interferences.
Important ceremony Demo is missing. Lot more focus on burndown chart as that's the selling idea of the video anyway.
ShriKant Vashishtha user stories must definitely be estimated using Points, however tasks will be translated in Hours to quickly visualize issues on teams progress and maturity
Highly recommended, A super dense and super packed ~9 minutes.
Hey u missed about sprint review.
At the end of the video he did say sprint retrospective at the end of each sprint.
Retrospective is not review :)
Also missed the Sprint Planning, but IMHO, in this presentation Sprint Planning & Sprint Review is in one pack of Sprint only
Except for the cliche background music, this video actually taught me scrum! Better than other videos, thanks.
"This just became a job"
Gylfoyle!!!
@@alamjim6117 uuu
Thank you!!! I love such on point explanations.
SM is not a project manager with a different name!
very effective. Lot of knowledge revision for those who are already familiar with the basics of Agile and Scrum. Kudos
lot of wrong understanding.... .. first scrum master is not project manager
+Sanjay Jadhav ... video says "He is a lot like a project manager"... not "he is a project manager".
I tend to agree with Sanjay. The video should say "The ScrumMaster is a LOT UNlike a project manager".
A project manager oversees the deliverables, whereas a ScrumMaster oversees the delivery process. There are more likeness between a PM and a PO than a ScrumMaster.
Excellent introduction to agile. Downloading the demo software right away from AXOSOFT to try out the methodology with burndown chart. Welldone
Ah, the background music is so annoying!
jon hahaha, true!
jon i didn't hear it till the end. It's called reticular activating system
i didnt even notice it. you have bad attention
I wish all videos were this good and efficient. Thank you for the quick intro!
Sounds incredibly stressful...
In practice, I imagine it is simple and makes work-flow practical. But I agree, it does sound as straight-forward as the US congress. xD
It is. For instance just try having a daily meeting where everyone shows up and shows up on time and then try constraining it to 15 minutes. Those meetings often result in excuses given and accusations made against others that are present as to why they can't get whatever done, which usually degrades into a scream fest that you have to somehow control without any authority over those involved. And that's just the start of your day. And those executives that "generally get in the way"? That is an extreme understatement. They constantly harass and irritate you for updates and lengthy explanations as to why something isn't going quite as planned, as well as making you develop lengthy "action plans" as to what you are going to do about it. This while you are trying to focus on all the dozens of different complex aspects of the project each day.
As someone who has worked on this type of team, it is actually pretty simple. It can be pretty annoying having a meeting everyday about what you did the previous day when the work is actually pretty slow and you are trying to focus on the same thing for days. Here it sounds a bit complicated but it's not as bad. Being a developer, I have never had to deal with the executives that are mentioned in this video. They usually bother the managers above you. This methodology seems a bit unpractical as it makes you waste 30-60 minutes of your day trying to conduct a meeting, but in the long run it is very useful.
I totally agree.
I guess you need to have very specific people with very specific experience and training. I can't imagine anyone from my office able to work like this even after some training.
You should do Scrum for dummies 😃 This short and sweet video explained the process in a way that is easy to understand.
Thank you! I am starting a new health IT job where they will be using this. It made so much sense!!!
Perfect! A model for others to follow on how to make a concise, comprehensible tutorial video. So many on RUclips can learn from this example.
I am a beginner of Agile/Scrum, this helped me so much. Thank you.
Wow...it's Scrum in a bucket! Thank you this video. And that tool that you built-in is a rock star! 👏
Omg the aesthetics on that OnTime Agile Scrum software, dayum!
This is the best presentation I have ever seen. I can't believe you conveyed this entire info in just under 8 minutes, that too effectively.