Intro to Scrum in Under 10 Minutes
- Articles, Blog

Intro to Scrum in Under 10 Minutes


[Music] Hi. This is me. My name is Hamid Shojaee, and I’ve been involved
with a number of software development projects over the years, at a number of different companies, and I’ve
come to recognize ‘Scrum,’ as one of the best agile development practices
in use today. In this fast-paced video, I want to show you why Scrum is so great,
and how you can get started with Scrum in under 10 minutes. I’ll cover all the core Scrum concepts, like product backlogs, team roles, sprints,
burndown charts, and more. So get ready to be bombarded with information. Lets say THIS is the product we want to build. For this product, we get all kinds of feature
requests from customers, executives, or even other team members. In Scrum, features are written from the perspective
of the end-user, therefore, features are known as user-stories. The collection of all these user-stories is
called the product backlog. Another way to think of the product backlog is to think of it as a wish list of all the
things that would make this product great. Once we have our wish list or the product
backlog, we need to start planning which specific user-stories we’re going to put into a particular release
of our product. But we’re getting ahead of ourselves. Let’s back up a bit. To build this product, we need to have one or more people in our
team who are going to play a variety of roles. First, we need her. She plays the role of product owner, and helps make sure the right features make
it into the product backlog representing the users and customers of the
product. She helps set the direction of the product. Then, we need this guy. He is the Scrum Master and his job is to make
sure the project is progressing smoothly and that every member of the team has the
tools they need to get their job done. He sets up meetings, monitors the work being
done and facilitates release planning. He’s a lot like a project manager, but that’s
such a boring title. So, we’ll call him a Scrum Master [Karate
yell] to imply he knows some Jui-Jitsu. And the rest of the team has similar roles
to other development processes. These guys build the product, while these guys test it to make sure it works
right. These guys use it, and hopefully pay for it. And these guys, they generally get in the
way, but it turns out you can’t build many products without them. But lets get back to this: Release Planning. To plan a release, the team starts with this,
the product backlog, and they identify the user-stories they want
to put into this release. These user-stories then become part of the
release backlog. The team then prioritizes the user-stories
and estimates the amount of work involved for each item. Sometimes larger user-stories are broken down
into smaller more manageable chunks. The collection of all the estimates provides
a rough idea of the total amount of work involved to complete
the entire release. A quick side note about estimates. There are a lot of techniques for creating
good estimates. Some prefer estimating in story points where
estimates are made relative to building a small component with
a known level of difficulty. Unfortunately, story points don’t answer
the question of, “When will my project ship?” I have found that the best technique is to
estimate work in hours, but to use some standards in how estimates
are done. For example, things that take less than a
day to complete will be estimated as 1 hour, 2 hours, 4 hours
or 8 hours. Every item will fall into one of those buckets. There will be no 3 hour estimates, for example. A 3 hour item would fall into the 4 hour bucket. Larger items will be estimated as 2 days,
3 days, 5 days, or 10 days. Again, all estimates in between will fall
into the next larger bucket. Extremely large items are similarly estimated
in months: 1, 2, 3 or 6 Months, but the reality is that such items will need
to be broken down substantially before work actually begins. We’ll come back to these estimates in just
a minute. But for now, lets go back to this: The Release Backlog. With a prioritized set of user-stories and
the estimated amount of work at hand, we are now ready to plan out several sprints
to get the work done. Sprints are short-duration milestones that
allow teams to tackle a manageable chunk of the project and get it to a ship-ready state. Sprints generally range from a couple of days
to as much as 30 days in length, depending on the product’s release cycles. The shorter the release cycles, the shorter
each sprint should be. And you’ll want to have at least 2 to as many
as a dozen sprints in a given release. So, at this point, we can take our release
backlog and split it up into several of these: Sprint Backlogs. One of the most important things to remember
about sprints is that the goal of each sprint is to get
a subset of the release backlog to a ship-ready state. So, at the end of each sprint, you should
have a fully tested product with all the features of that sprint 100% complete. Since sprints are a very short, but a realistic
representation of part of the product, a late finish of the sprint is a great indicator
that the project is not on schedule and something needs to be done. Therefore, it’s extremely important to monitor
the progress of each sprint with THIS: A Burndown Chart. The burndown chart is the number one reason
for Scrum’s popularity, and one of the best project visibility tools
to ensure a project is progressing smoothly. The burndown chart provides a day-by-day measure
of the amount of work that remains in a given sprint or release. In this graph, you can see that the amount
of work remaining bounces up and down from day to day, but is generally trending towards zero. Because historical information is provided
in the burndown chart, it’s easy to see if the team is on the right
track. Using the burndown chart, the team can quickly
calculate this: the slope of the graph, which is also called
the Burndown Velocity. This is the average rate of productivity for
each day. For example, a team’s rate of productivity
might be that on a typical day, they finish approximately 50 hours of work. Knowing that, it’s possible to calculate an
estimated completion date for the sprint or even for the entire release, based on the
amount of work remaining. What’s great about the burndown chart is that we can compare our actual velocity
and projected completion date to what the team needs to do in order to finish
OnTime. This is perhaps the most useful piece of knowledge that any team member, product owner or product
executive can have about the project, because knowing whether or not the project
is on track early in the schedule can help teams make the proper adjustments
necessary to get the project on track. The burndown chart provides empirical proof
that the project is on track or if it’s going to be late. So, let’s talk a little about where the data
for this incredibly useful burndown chart comes from. As you recall, part of the release planning
process was to create an estimate for each user-story in the release backlog. The collection of these estimates for a given
sprint represents the total amount of work that must be done to complete that sprint. As each team member goes through and makes
progress on one or more of the user-stories, they simply update the amount of time remaining
for each of their own items. So, the total amount of time remaining on
the group of user-stories that make up a sprint, changes on a day-by-day basis, hopefully going downward until it hits zero
when the sprint is complete. The burndown chart aggregates the remaining
work data and shows it visually. It’s brilliant because it communicates a massive
amount of information in just a few seconds. And that brings us to this: The Daily Scrum. The Daily Scrum is an essential tool to having
communication flow freely between team members. The idea is to have fast paced stand-up meetings where team members quickly list the work they
completed since the last meeting, and any obstacles in their way. By meeting daily, it ensures the team is always
in-sync, and any major issues are dealt with as soon
as they are known. Finally, as each sprint comes to a finish, it’s important to have a Sprint Retrospective
meeting, where the team can reflect on what went right
and areas of improvement. After all, Scrum is a flexible agile development
method that needs constant improving and tweaking
for every team. So, there you have it. Scrum in under 10 minutes. You now know all the essential concepts to
start implementing Scrum inside of your organization. But wait a second, what about tools to help you implement Scrum? Well, it just so happens that I’ve spent
the last 10 years building such a tool. With a lot of help from these guys: a group of genius coders and design ninjas. The tool is called, OnTime, and it helps you manage your products, your
backlogs, your team, your releases and your sprints. It gives you project visibility with burndown
charts, and always answers the question of who is
working on what. You can get started with it for free, at Axosoft.com. Of course, you could use a giant white board,
some note cards [Paper crumples] and a bunch of different spreadsheets [Paper
crumples] to track everything. You could also use an abacus instead of a
calculator to do math, but we’re getting a little off topic. So, let’s quickly review everything. In Scrum, you work with this: a Product Backlog, which is nothing more than a list of features
that we call User-Stories. You then break down the product backlog into
one or more Release Backlogs, and for a given release, you further break
up the release backlog into a number of Sprint Backlogs which are essentially short duration milestones
throughout your project. You then monitor the progress of each sprint
using these: Burndown Charts and have Daily Scrum meetings to ensure everything
is on track. After each sprint, you have a Retrospective
meeting to fine-tune everything. And if you want a tool to implement Scrum,
you can use, OnTime. It’ll help you ship software, OnTime. That’s all there is to it! Oh, and one last thing. Whether you loved or hated this video, I’d
love to hear from you. You can reach me on twitter or via email if
you have any feedback. Now get going, Create a great team, Collaborate, and Ship Software OnTime. [Music with whistling fades]

About Ralph Robinson

Read All Posts By Ralph Robinson

100 thoughts on “Intro to Scrum in Under 10 Minutes

  1. Excellent, comprehensive explanation of the Scrum process! Also, the "Scrum Master" vs "Project Manager" title comparison made me laugh out loud. (1:36) Ah, I love programmer/geek culture.

  2. Every like for this is someone who needs to unlearn the things he learned in this vid. Almost right, but slightly off to many times. But: nice presentation, good job.

  3. this is really amazing visit our tutorial and aws interview questions (below links)
    https://bit.ly/2R4YnjU | https://bit.ly/2DUj6nG | https://bit.ly/2ypVJOl

  4. This is very outdated … Estimating in hours is counter-intuitive to the entire concept of team performance monitoring and improvement. Team must use the Story Points to only focus on the combination of complexity and effort and not just the time needed to finish the work and use that as an scale to measure the rest of the work. If you force the team to use hours, they will pad the story hours with extra hours as an insurance to avoid looking bad if they make a mistake. Also hours are not a good abstraction measure and mix with the day to day work instead of staying on their own layer. For example, a team member may end up using 5 hours on a 2 hour story in a day that was half taken by technical issues with the server and network. Also team performance should be measured by what ends up in the Demo session and can be shipped, not by the hours they used. Team can spend 100 hours and have to output in the end. Use Pointing system to track team performance and use shippable product as measure of performance.

  5. Wow this presentation was short but loaded with depth. Straight to the point, no beating about the bush! I would really like to hear great failure stories of Scrum/Agile! Thanks for the presentation video.

  6. I'm trying to quickly learn a little bit about Agile and Scrum for a new communications role I start in a couple of days, supporting an IT executive. This was a very helpful and engaging video. Thank you!

  7. 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.

  8. You cannot estimate tasks in time, only difficulty relative to other tasks. The founder of SCRUM has tried for years to get people to move away from time-based predictions- humans are just not that good at estimating how long things will take.

  9. Kudos for such a useful video in less than 10 minutes. Only thing which I am not convinced is the estimation which can be debated πŸ™‚

  10. I'm now a Scrum Master in 8 minutes. 2k of training saved, especially when you have 6k of PMP, DMAIC Sigma, and Lean training.

  11. Scrum is a micromanaging, suffocating methodology that stifles all creativity and efficiency, and should only be used by large corporations to ensure they squeeze out at least some productivity from even the most lazy and/or borderline incompetent developers. It should be avoided like the plague if you actually care about getting quality software shipped in a timely fashion – for this you need top quality developers who are granted autonomy and freedom.

  12. Estimating work in hours is against what proper Scrum teaches. Estimate by difficulty and know how many Points your team can do in a Sprint based on Velocity (which you get better at knowing as you get more experience and data).

  13. So … great … but ….

    The great missing part? Does anyone told the customer/stakeholder/user/friend/client/gizmodo/whateveryouwannacallthem…..

    The absolute very first thing YOU WANT them to KNOW and Understand before anything …. ???

    1 What is Automation?
    2 Why one automates
    3 Why one doesn't automate
    4 The ancient and unchanged essentials and principles of automation???

    No? You perhaps will rethink this. Thing is, Digital Automation is exact, for every professional and customer/stakeholder/user/friend/client/gizmodo/whateveryouwannacallthem alike. And Exact = 100% Predictable. So before you like to debate or challenge this most legal aspect….

    If you as a professional don't know the essentials and principles of automation and you are not school your customer/stakeholder/user/friend/client/gizmodo/whateveryouwannacallthems, and you don't line them up how matter automation is behaving and is to be treated, you as a professional in any part or discipline of the digital automation, are 100% accountable and liable…

    Perhaps you like to think this over since 99% of all methods basically comes down to the same, which to me is just fine however, not KNOWING the essentials and principles of automation, not conveying this to your customer/stakeholder/user/friend/client/gizmodo/whateveryouwannacallthem… will turn in to a nasty pitfall in times of mediation or settlement.

    Just so you KNOW…. now …

    Start with the essentials and principles first, then you build …

    Perhaps the good folks, professionals of all feathers in IT, ICT, IoT, AI, prince 2, itil, scrumtydum and all want to $hare this with one and other???

  14. Scrum = endless pointless meetings sucking the life out of everyone until all the best people get sick of the micromanagement and leave.

  15. Such a great video
    I had no clue about scrum and after watching this video I feel like I know so much. Thank you, for the future videos can you please make the background sound a bit softer?

  16. I'm an executive and If I ever hear anyone say that I get in the way, I will fire their arse right then and there!

  17. Scrum is a framework! It's nothing but a set of rules or guidance to ease the effort for better results. It's a list of norms to abide for accomplishing every increment. It involves planning, effective utilization of resources, lessons learnt to avoid similar mistakes in future, Receive constructive feedback before acting upon the subsequent iteration.

    Please have a look at the below blogs which covers the basics. After which let's take a deep dive into the concepts.

    https://dexturous.wordpress.com/2019/03/30/agile-in-a-nutshel/

    https://dexturous.blog/2019/03/30/agile-and-scrum-myth-and-misconceptions/

    https://dexturous.blog/2019/04/01/power-of-failing-early-2/

    Regards,

    Siva

    E: [email protected]

  18. Post it notes are better – "If the glue on the back of a post it note wears out, it's been on the backlog too long" – valuable lesson though – thank you for the explanation!!!

  19. I already practice most of that, and so does every developer I know of. Scrum sounds like nothing more than giving different names to existing practices.

  20. Estimating in hours is very problematic for a number of reasons. The reasons behind story points is that we are not good in absolute estimations but relative estimations. Measuring in hours does not reveal data about how we improve our velocity over time, and if we make improvements we are then expected to ask people to adjust their estimation to those improvements. By estimating in points, the meaning of those points reveal themselves over time (our velocity). Using our velocity we will know what we can reasonable get done in a sprint, and we will have the goal of removing impediments in order to improve our velocity as well. So, over time, we should see that number increase – something that would be very cumbersome to try to track if we were using hours.

  21. Ah the reason why you focused on burndown chart as most important is because of selling a tool. Of course, the are many other, probably more valuable, aspects to scrum and the agile philosophy that scrum aims to support.

  22. Such a perfect video. I first discovered this while I was studying the unit Project Management in uni and I am now watching it before my job interview to brush my memory! Thank you.

  23. Can u put this same video without disgusting music which is unnecessary disturbing us and we can not pay attention to your words what you are saying.. very bad unnecessary music on backside.. put same video without music will be best 🀬🀬🀬🀬

  24. Good job, but Some few small mistakes in the video will be noticed quickly by an agile coach during any interview process.

  25. Thank You for this excellent professional presentation. It's clear, concise and engaging. Great work!!

  26. Great video, but as someone with ADHD, the super upbeat, kinda obnoxious music really distracted, and I had to pause and rewind several times. Otherwise, great explanations and breakdown.

  27. Crappy commercial video. It's not really about scrum but it's about a piece of shitty proprietary software.

  28. OrangeScrum and OpenProject are much better alternatives available for a cheaper price as well as for free

  29. Really amazing overview of scrum at high level and would like to hear from you regarding devops as well now. Thnx

  30. Your explanation was good, it gave me overall understanding of scrum, I have a query, who decides which technology to use for application development , for example a code needs to be developed, which one to use either java or python, does the scrum master decide that ?

  31. Thank You! Good refresh and understanding of Scrum and the components involved. Loved your C-Level Exec's comment!

  32. Succint, Clear and informative. Great job, helped me get ready for my (possibly) next workflow type. Thank you.

Leave a Reply

Your email address will not be published. Required fields are marked *