Agile Team Practices with Scrum

About this Course
Hello and welcome to Pluralsight's agile team practice fundamentals course. My name is David Starr and before we get into the contents of the course itself, let's talk a little bit about how this course might be a big unique.

Agile and Why It Works
Our first module of the Agile Team Practice Fundamentals course is Agile and why it works. This is really an overview of Agile Software Development. There are a lot of conceptions and misconceptions out there about what it is and hopefully we can dispel some of those and confirm others when we work our way through this module. If you're trying to introduce the idea of Agile Software Development into your organization, this might be a good one to show maybe to decision makers in the organization who are wondering what this Agile stuff is all about. In this module, we'll compare development processes looking at Agile Software Development and Plan Driven or Waterfall as we typically talk about it. We'll look at what Agile is and is not because as we said, there are a lot of preconceived ideas out there about what Agile is and we'll see if we can get to the bottom of some of that. Lastly, we'll look at some contemporary Agile methodologies that have found some good success in industry, primarily we're going to focus on just a lap around some proven and demonstrably effective Agile Software Development methodologies.

Agile Requirements and Estimation
This module is about Requirements and Estimation in Agile software development projects. It turns out that most of the waste and missteps in any software development project can usually be attributed to poor communication or a lack of communication within the team or between the team and the customers. This module is all about how people who want the software and people who will be making the software can communicate more effectively. We'll take a look at what makes an effective requirement and after looking at some attributes of effective requirements, we'll see a formula for creating some very simple but effective requirements with user stories. Now that we have our user stories, we'll take a look at how teams can use those user stories in an estimation process enabling business decision makers to make long-term plans and teams to be more deliberate about their work. Lastly, we'll look at Planning Poker as a technique for effective estimation.

Scrum Fundamentals
Hello, welcome to this module on Scrum. This module focuses on Scrum Fundamentals including all of the Scrum framework and the basics of the vocabulary and that weird Scrumish vocabulary that you hear people talking about, also the behaviors and activities that Scrum teams go through. First, we'll start off with a little bit about the history of Scrum and where it came from. It's always important to know where this stuff originated. Then we'll take a look at the principles that led to the creation of Scrum in the first place. We'll examine the basic Scrum framework and we'll talk about all of the roles that Scrum defines. We'll look at the artifacts or the things that are generated and used by the Scrum processes and talk also about Scrum ceremonies. Ceremonies, hence, it's a better word than meetings, right? Then we'll talk about activities. These are the processes that actually occur on the teams. This module is a great introduction for anyone considering bringing Scrum into their organization or anyone having conversations with others about Scrum.

Enterprise Scrum
Hello, this is David Starr and welcome to this module on Scrum in the Enterprise. This is working in Scrum environments that can be much bigger than 1 to 3 teams scaling up. And hopefully, we'll see how we can get big without getting slow. Some of the tools for scaling Scrum that we're going to look at include the Scrum of Scrums which is exactly what it sounds like. And we're also going to look at the problems inherent with multiple or large backlogs that is when you have a lot of different product owners maybe or a lot of different products, many teams, how do we manage backlogs in those environments? And we'll look at using Scrum maybe on a development team that exists in an otherwise plan driven organization. So, I've got water falling all around me in other places in my organization but we really want to use Scrum here in our team. How can we do that? And then finally, we'll take a look at some measurements that we can use maybe to get people to understand Scrum a bit better and its value even in a plan driven organization. What are some metrics that we can take and use to talk about Scrum to those who aren't yet familiar with it?