September 19, 2019
Agile Project Management: Scrum & Sprint Demystified

Agile Project Management: Scrum & Sprint Demystified


[Music]>>Hi. I’m Devin Deen, Content Director here
at projectmanager.com. Hi. In today’s whiteboard session, I’m going
to cover Agile project management in about 180 seconds, so let’s get stuck in. Now, first thing you need to know is that
Agile project management methodology is not an approach for every single project. It’s
only good for projects where the end user may not know exactly what they want. You have
kind of also the constant variable changing priorities and you have access to a cross
functional team of people who can collaboratively work together at the same time, ideally co-located.
If you’ve got those ingredients, then you certainly have everything, at least at the
starting point where you might want to try and approach the project using Agile project
management. Now, Agile project management came about in
1986-ish, a couple of Japanese fellows by the name of Nanaka and Takeuchi, studying
the manufacturing process and the supply chain in restaurants oddly enough, came up with
the idea that a rugby team type project team approach was the best way to get those projects
delivered. The metaphor was that you have a rugby team who takes the ball across the
line, passing it back and forth until they get against the try line. When they observed
and studied projects that had that cross-functional project team working together to get that
project across, they found that they had a higher degree of success rate than, let’s
say, a bunch of individuals working asynchronously to achieve that same objective with that project. Ten years later in the United States, a couple
of fellows by the name of Sutherland and Schwab presented a paper on that topic on what they
call the rugby method, but Sutherland and Schwab renamed that and called that Agile
project management and that was delivered in Texas. I think it was a Business Objects
Conference. Now, what you need to know about Agile project
management is your project is organized into a story of backlog and task. The story is
the use case, it’s what you want to achieve out of that particular project, the overall
project might be, for example, an ecommerce website and, just following my train of thought,
the story would be wanting your customer to be able to log in a series of shirts or clothes
and purchase them through your ecommerce website. That’s your story. That’s your use case. The backlog is the set of requirements that
go into filling up that story. You might say a user in Idaho can access your website, that’s
a requirement, or they can pay with a credit card, a Visa card or a MasterCard or their
own personal banking card or do a fast check, a direct deposit to pay for that. That’s part
of your backlog. The list of requirements that sort of comprise your story is what’s
called your backlog. Your project team, when they get together,
they look at that backlog, they then decompose the backlog or the requirements into different
tasks and those are quite simply tasks, so that’s easy enough. When you’re trying to
achieve the story, you get your list of backlogs and you organize the achievement or the production
of that backlog into what’s called a sprint. They’re time-boxed sort of mini projects if
you will anywhere between a week to probably four weeks. Four weeks is your absolute maximum
and one week is your absolute minimum. Anywhere between one to four weeks, you’ll time box
your effort, you’ll time box what you’re going to deliver in those requirements in your backlog
and that’s called your sprint. Your project team, your cross-functional team
is organized into what’s called a scrum. The scrum is a collection of people who get together
in that particular sprint. They’re locked ideally in the same area working together
to achieve your backlog. Sprint planning is a meeting that you have half a day with your
end users. You go over the story, you take them through the list of backlog and you get
them to prioritize the requirements or the functionality that they want you to deliver
in that particular sprint. It’s really important that the users own that prioritized as a backlog.
That’s the first half of the day. The second half of the day, you bring your
scrum together, get them to look into the backlog, get your scrum to sign up to which
of those items on the backlog they can actually deliver in your period of time, in your sprint
time frame. Let’s say you’re going to do a sprint in 21 days. Get your project team together,
get that scrum together and they’ll look at the backlog and they’ll say, “Yeah, we can
do this one. Yeah, we can do this one. We can get the functionality so they can drag
that shirt into their shopping basket. We can get the functionality to actually make
that credit card payment.” They’re the ones who are signing off on which items in their
backlog they’re actually going to deliver. When you’re in execution, you have a scrum
meeting. Those happen everyday, generally in the morning, no longer than five minutes
across your cross-functional team. Three things that team members talk about, they talk about
what they did yesterday, they talk about what they’re going to do today, and they’re talking
about what they’re going to do tomorrow. A lot of Agile project managers put the list
of task that need to be accomplished on a board somewhere, organized by person or organized
by functionality. It’s really up to you about how you organize that, but it’s important
that the team keeps a constant focus on what they’re doing and they’re thinking about what
they need to achieve, what might go in their way. In that scrum meeting, that’s when they
sort of talk about obstacles and who can help whom and they do that coordination. A sprint review is the demo that you have
at the end of the sprint. It’s what you’re actually showing to your end users, demonstrating
the number of items in that backlog that you’re actually able to achieve in that particular
sprint. A sprint retrospective is at the end of that sprint, after you do your sprint review
meeting, you get the scrum together, you talk about what you did well, you talk about what
you didn’t do so well and then you also look at that backlog of items. It’s assumed that
you won’t be able to achieve all the backlog, so those backlog items that you didn’t achieve
in that particular sprint go into the next sprint and they form the starting task of
your next sprint. Now, how do you manage this as a project manager?
How do you manage these sprints? Do you just turn up everyday at the sprint meeting and
make sure nobody gets into fisticuffs? Let them go for it and just assume the team’s
going to achieve what they said they’re going to achieve? No, you don’t do that. There are
ways to track, manage and monitor and control that sprint once it’s on the way. The most
popular way to do it is using what’s called a burn down chart. Let me just quickly describe this burn down
chart for you. Burn down chart is really easy. It’s the number of days on your sprint on
the bottom. In this case, zero to 21 days. On the left-hand side, we’ve got the total
number of hours in effort required to achieve that backlog and that’s based on the task
that the scrum has put together and then again on the right-hand side, we’ve got the list
of tasks. These are the tasks that the scrum when they look at the backlog, they broke
that backlog into different tasks and you had a quantity of task, in this case, 30 tasks. For this particular sprint of 21 days, I’ve
got about 300 hours worth of effort to achieve a backlog that I’ve agreed across 30 different
tasks. On a day by day basis, as a project manager, you need to be recording how much
effort has been expended by that scrum and how many tasks they’ve completed. What you
should be seeing along the way in your sprint is that the list of hours obviously left to
go sort of whittled down. You start at 300 hours in your hopper and you basically subtract
the number of hours per day the team is working and you’re also counting down the number of
task left to do to achieve the backlog. Depending upon where they get is an indication
of how successful that scrum work together in that particular sprint. Along the way,
if you’re seeing lots of issues crop up, certainly as a project manager, take control, get in
there, make some suggestions on how to clear up those problems or maybe it’s an indication
that you need to revise your sprint and think about which items need to go in that backlog
and manage your stakeholders’ expectations. This is just a top level view about Agile
project management. Certainly, after this whiteboard session, don’t go out there and
say you’re an Agile expert. Go out there and read the material from Schwaber and from Sutherland
or Takeuchi and Nanaka. Read up on the Agile project management method. There are many
different flavors depending upon if you’re doing project development or software development.
Pick the one that works for you, but most of all get out there and try it. Give it a
go. For more project management whiteboard sessions
and all your project manager needs, come see us at projectmanager.com.

99 thoughts on “Agile Project Management: Scrum & Sprint Demystified

  1. An 8 minute video titled Agile Project management in 3 minutes is not very convincing. If this would be a project, it would be more then twice as long costing me twice as much time and effort, has a wrong product delivered (an 8 minute video in stead of a 3 minute video) and thus showing the basic problem of many projects. Promises aren not met, budget and time exceeded and an endproduct you didn't ask for. Well done guys. Very convincing to hire you as a project manager. 

  2. For all these free-loaders with negative comments: the 180 seconds may be a catch to grab your attention! Be a little grateful for a succinct summary of what Agile Project Management is!

  3. Thanks for an excellent video but there is One correction – In a Scrum Meeting, we discuss: "What was done y'day, What will be done today and what are the roadblocks and how to remove those" . We do not discuss that what will be done tomorrow as that will be discussed tomorrow ! This is Agile….

  4. Hi, I like your content and generic explanations, however, for future videos (my point of view) you need to have a script to follow rather than simple bullet points because in this video you loose your train of thought an come across as guessing rather than factual.

  5. All these ceremonies mentioned by this speaker are actually facilitated by the Scrum Master and product owner and not the Project Manager in an ideal team, Although the project management can also do the same since there are many different flavors being done by the different organizations

  6. i like this guy .. also he helped me finally understand some of scrum ways which two quite well animated videos i saw before didnt .. also i like his gestures

  7. Apart from the minor time issue in the title, this gentleman is outstanding. Succinct, effective, superbly explained and very clear. This man is an elite level educator, and I found this really useful.

  8. That was great! But i wish he would talked about Epic and difference between user stories. And you didn't talk about sizing the stories!

  9. From what I have seen this method discourages taking on really big projects. By requiring a potentially shippable product at the end of every sprint you are making big projects that take months before they could ever be considered shippable look unappealing. Often after several iterations of smaller projects and not shipping the team realizes they could have done the bigger one in that time and actually addressed the real problems. Don't forget, this was invented in the restaurant industry.

  10. You're a little bit wrong. In daily scrum meeting scrum master must ask 3 questions:
    1. What did you do yesterday?
    2. What will you do today?
    3. Are there any impediments in your way?

    And not that you plan to do tomorrow. In these matters there is a big difference. And the goal of this meeting to understand what obstacles are on the way the team.

  11. great first 30 seconds – Agile is not right for everything. I love the pace of this. Around 2:30 great description of story and backlog etc. Good job!

  12. after reading some of the comments here is my input. Guys this guy is being ironic with the title where is your sense of humor. It does not matter if it's Agile or Waterfall as history has shown chances are projects very rarely are on time, hence the sarcasm. Also for those of you who don't know but like to make uneducated comments in Agile there is a Scrum Master which is the equivalent of a Project Manager in Waterfall.

  13. Hi Devin,
    Thanks a lot for basic info, I am so kind of you, if you give me authenticate Scrum software & product links. What you stated in your session
    .

  14. i live in Australia. i work as a contractor for Government in IT.i am interested in pursuing my career in Project Management. would someone please advise explain about PM certifications. Prince2 OR Argile. i cant go for PMP as it is expensive and needs alot of study. my consideration is which costs less and beneficial in career

  15. The question still remains: How could the biggest projects in the history of mankind like the Manhattan Project or Operation D-Day be completed with success without any modern management principles or software tools?

  16. Excellent and very efficient! However, I suggest to specify the step of potentialy shippable product increment generates by a sprint execution. This increment has to be challenged by users and it's the important moment to collect feedback, new requirements, remarks and to refresh the Product Backlog Items… Scrum have to facilitate the exchange between the end user, to respond to the demand and to be "time to market".

  17. Well, this is one of the videos worth to check on youtube. Beside the videos including small kittens 🙂 kidding. So, This video gave me a lot of confidence and information about agile way of project management. Thanks and congrats!

  18. Very impressed that you did the whole thing in one take. At 3:42 you say that Sprint Planning includes end users: this is highly unusual. Stakeholders may be involved, but Product Owner + Scrum Master + Dev Team (only) is more usual.

  19. Interesting concepts but going from first principles the PM role doesn’t exist in Agile using Scrum. The leadership and work control is intended to be mainly carried out by the Product Owner and an autonomous team. The facilitation and soft skills should be provided by the Scrum Master. I think in most organisations this creates a problem due to their hierarchical management structures and lack of comprehension or trust of Agile self governance. It’s a Very informative presentation though.

  20. I concur on the part of AGILE being a methodology for handling relatively complex software projects.

  21. I love analogies. Great for people who don't have natural skills at delivering great ideas and alternative thinking. THis is theory for peole who can't do it naturally.

  22. I would like it much better if you would add more examples to the presentation. Good job though. Thanks!

  23. Sir
    Let me ask some question below for your explanation will be great appreciated.
    1. Many tasks can complete in 1 day even a week due to it has to supported from various department such as procurement , engineering , production, construction logistic and so on. How we run scrum meeting effectively ?
    2. As of Agile and Scrum concept , do any construction business use before?

  24. This is wrong on several counts. 1. There is no such thing as "Agile Project Management". 2. There is no scrum role called "Agile Project Manager". 3. Scrum is not just for the types of projects mentioned. 4. The co-author of Scrum in the US is not "Schwab". He is Ken Schwaber. The presenter does correct this on the closing. 5. Scrum is not about project management. It is more accurately about product management. 6. The discussion of stories and backlogs is wrong. Backlogs do not make up stories. The backlog consists of stories. 7. The "daily scrum meeting", frequently called the "standup" takes more than 5 minutes. Three minutes per person is a good rule of thumb. 8. The presentation is over 8 minutes long, not "180 seconds". I would urge our colleagues to look elsewhere for a a primer on scrum.

  25. With all respect, Agile didn't start 1986 and not even 1996. I have been doing Project Management since 1987. First Agile is BS. It is not new. They just changed names: Sprint are releases, Scrum is project status meeting where the PM review the status, risks and issues. Stand up meetings are checkpoint meetings and you ONLY do that when is close to deployment or cutover IF NEEDED. New Project Managers think Agile is new methodology which is not. It is just a business marketing to make money

  26. Devin.. Good job. A lot of people here view agile as ritual..think they have to follow exactly like 99.99% coach them.. You did good as you gave the philosophy in short time. Time boxed only for sprint as they is a culture change, to deliver in that time boxed agreed backlog and tasks.. Now how I do it depends on project and it's complexity.. Not all projects are applications, web development.. I also liked when you said, where actually agile works.. Cross functional, where scope creep is allowed.. I want to add the scrum team should not be more than 10 (max) ideally about 7 staff

  27. Disappointed watching this video. Firstly is he talking about scrum or agile project management? Lol! Secondly half of the things he spoke about were correct but some were just a load of faff. In scrum, there is no prescribed way of writing PBIs (Product Backlog Items) so I’m free to write then however the end users and team understand them, however writing them in a format of user stories is recommended but not required.

  28. Renaming 'Rugby method' to 'Agile' might be the most brilliant move by Sutherland and Scbwab, apart from mastering the method.

  29. This was great, thank you. I think it's a bit silly as it's a bunch of new terminology and concepts that those of us in the business have known for years, but your video presented a nice over in and gave me more information in 8 minutes than some videos 2 or 3 times as long.

  30. A couple of distinctions that might be useful to add are the differences between requirements and stories, and between hours and points.

  31. can this be used in construction management, where i know my outcome but to manage my resources and my material and have a cost and time over-run controlling ??

  32. Agile can be applied to any project and with any industry. I am pretty sure that the presenter has very little experience with Agile or Scrum practices

Leave a Reply

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