Hello and welcome to Lessen 4.3 are video lab of developing and agile schedule
A quick admin note if you start seeing me doing the ducking and weaving its because I have a Web camera right in my face that it's blocking the monitor.
So I apologize in advance. But I'm your instructor cane, and I'm gonna walk you through a brief example of developing a agile schedule. And for this video, we're going to use Microsoft Dev ops.
software suites and things that you can use. I just happen to have access to this one, so we're going to use it for this video, and then I'll try to use something different for the next video lab so you can see different software options.
So what we've got here is a product backlog. And as we talked about in the pure, agile video,
once we've identified our structure, our schedule or methodology in this example, we're going to use from with traditional sprints, um,
or iterations where we want to call him. And, uh, the next step would be to develop the backlog
when this is the all encompassing backlog.
But it's a living document. So remember, once we've identified what these items are
bacon totally change day in, day out, when something new pops up, just add to the backlog. So I've got some items here. No notice that these air tagged with MVP minimum viable products. So those were the items that are for sure gonna go in the first iteration
and then I'll have as I'm meeting with my team and being with my customer,
I'll be adding more and more options. So in this case would be nice
if it showed users. Avatar,
it doesn't really matter what the
what the thing is, but
we'll go ahead and add it. So I'm meeting with the customer. I'm talking to people. I'm having requirements, gathering sessions, but again is living documents. So the more we know, the more we're gonna add. So at this point, really just adding to our to do list, OK,
and then eventually I have this big giant backlog and this is all happening before I really even start the first iteration.
So I've got a backlog. I know it's living. I know it's gonna grow day in and day out,
but I'm gonna have my first sprint planning meeting, my first iteration meeting,
and I'm going to do a couple different things. One. I'm going to figure out what the prioritization is. And two, I'm going to figure out what the effort is.
As this is my first iteration. I don't necessarily know what my teams velocity is going to be, but we can make.
Really. It's not even a educated guess. You just throw a number against the wall
because as each generation goes, you're going to get better and better at estimating. And that's an important feature of the Sprint styles, from style of doing agile. So I've got these items and I'm gonna sit down with my team and I'm gonna say, OK, let's talk about these items.
Obviously, the MVP's have to go first. So Okay, how long you know how much effort on a scale of I'll pick 1 to 10 But again, doesn't really matter.
this item here, how much effort do I think it's going to be? I talked to my programmers. They say, on a scale of 1 to 10 they feel like it's a five. Okay, cool. But the five,
then we'll look at the other items. And I'm going to say, you know, again, what's the effort?
Notice how I'm not filling in. I'll show you on this next one. There's these other fields here about criticality and business value. I'm not really feeling those in right now and the reason why that is, and I'm gonna assume this one's easy. But the reason why I'm not filling it out right now is because these air minimum viable products so I don't care.
There's no decision making at this point. Those are for sure, going into
the first generation.
Okay, so I'm gonna drag those over, and I'm gonna drop him into my current sprint.
Okay? Don't you don't see them there yet. We just kind of weird, but whatever. So now they're in my spring.
The next step, I shall look, look at this as a board will be a little easier.
Okay, so I've got these items at a minimum viable products, so they're definitely going into this friend.
now, I'm gonna look at the other items, and I'm actually going to look at adding those additional pieces of data. So the ability to use paypal how much effort is it going to be? It's going to be a five,
but for business value, I think it's gonna be a seven at attend. It's a big deal. I want to do it
and I'd go through the rest of these that exact same way. Then
when I get ready to decide what else can go in the backlog, I can look at it From the standpoint of
I dont know why thats working that way. But we'll go back to the board.
So OK, so I've got things, additional items
and I have their business value and I already have a certain amount of effort in the sprint.
have it's been a lot of time customizing this particular project
for the demo, but I've got I think it's to 501 So I've got
11 effort points in my sprint, and we've already decided in our meeting that we think we can do 15. Don't know, but we think we can do 15.
So I'm gonna look at the other item that I'm gonna say, OK,
this effort is a 10. It's gonna be really hard, and the business value is, Ah, three. It's a nice toe have, but we're not really worried about it.
So one of the ones everything has got everything has a score at this point, and they actually do you sell. I don't have one with me on that, the network.
But they do so agile scoring
car decks like like you know, or, you know, like a deck of cards. And that's really convenient and useful tohave during these planning sessions, because you can. Basically, it's almost like using, ah Delphi technique, where you pass out a deck, teach each individual or a portion of the deck. I think there's four
sizes in the deck anyway. Don't matter, but you pass out this deck of cards and everybody gets the opportunity to score each item in their priority matrix. But the key is,
once you burning hard, you don't get to use it again.
So it's kind of a fun and interactive way to get
the project team to do a really good job of prioritizing and scoring these items. So if I think something's a 10 I'm gonna use it. But then my 10 card is gone, and I don't get to use it anymore. I only have one through nine or whatever the case might be,
and it's a good way of of
there's a term camera, the exact name of it. But it's basically the wisdom of the masses. So if you ask 1000 people to guess, for example, how many gumballs air in a gumball machine
and you take the mean the average of that of all of their guesses,
then you're going to statistically be very, very close to the actual answer. Even if every individual person is not that wise, the mass of people boating or bidding
tends to be closer to write on average than anything else. So there is a certain you always hear about,
bad things about masses. But there are some good things about large groups of people, large sample sizes. So, um,
once we've scored everything out and we have four effort points left in our sprint, we're gonna go ahead and pick an item. That or more I multiple items that meets that requirement. So let's say this item right here is a nice tohave,
but it only takes four effort points. It's only got a one for business value, but I only have four points left.
So I'm gonna go ahead and bring that into my sprint.
So this is all happening at the very beginning of your sprint. I now have work items that I'm going to be working on. I sign them to people
from an ideally each person
or each item should only require one person's worth of effort. So you're not necessarily doing
really complicated things. These are all supposed to be very tactical things that I can accomplish in two weeks and get to production.
There you go. So the being adjourns and we all go back to our desks or whatever, and we start working on these things
once we get to the end of this friend.
Whereas I'm completely thing Lister say, once I complete this task, I move it over, complete this task, move it over
so one of so on, we get to the end of this member myself a little bit more credit,
get to the end of the sprint, and here we are. Now it's time to put stuff into production. Close items out. Notice how this item here did not get completed. And that's because the
nice if it showed users. Avatar was my lowest priority item,
and I brand at a time. And in my estimation, skills aren't all that great.
So notice two things are gonna happen. One I'm gonna move all of this to done once it goes into production. And this is all during the sprint. Uh, retrospective. So their gun, they're done, they're gone.
The next thing I'm gonna do is I'm gonna take this item and I'm putting it back into the backlog.
So I clear these two lanes
Now, when I go to planet aeration number two
the nice If it showed users Avatar doesn't get any extra credit because I've already started working on it. If it's not in production, it goes back into the backlog and it just hangs out there.
We go back to looking at some of these other items. This should item, for example, outweighs. It's nice to have items so automatically it's going to be approved after we figure out the effort
in the business value, but it's it's higher on the priority list. It's gonna be approved.
While all this is happening.
The product owner and the customer as they're testing the system and doing things with it. They can come in here any time and keep adding things to the backlog.
So visualized this is happening all during that two week sprint.
So now when I actually go back and pretend that I didn't finish that Okay, so I'm back to my sprint planning. But notice, You know, I've got all these new things now, so I have to go back and look at everything with a fresh set of eyes and order to decide what makes it into the Sprint. What's the value to the business? What's the effort? How much throughput do I have?
And this cycle would be repeated during each iteration of
the agile execution process until I either completely around a backlog items which never gonna happen in real in real life or I run a time. My project is a three year project, and then it's over. So that's a brief walk through on
executing and developing a schedule for a purely agile project,
thank you very much and have a great day