The following content is
provided under a Creative
Commons license.
Your support will help
MIT OpenCourseWare
continue to offer high quality
educational resources for free.
To make a donation or
view additional materials
from hundreds of MIT courses,
visit MIT OpenCourseWare
at ocw.mit.edu.
SARA VERRILLI: OK.
Welcome to class.
Some very quick announcements.
We had the date wrong
on the vision statement.
The vision statement you
guys worked on on Monday
is due today.
We had the date
wrong in Stellar.
So it will not be
late as long as it's
turned in by tomorrow morning.
We have adjusted
the date on Stellar
so now it shows the real date.
But since we made that mistake,
it's not late until tomorrow.
But we will expect them all in
by the end of the day today.
Secondly, the things
that are due next Monday,
you will be expected to be
turning in a product backlog.
We're going to work on creating
product backlog in class today
and then you will have some
time to refine and think
about it as you're working on
the project over the weekend.
One thing you should be
working on along the way,
remember we require a design
change log for this project
as well.
So you should have
already started it
because you probably made
some design decisions
in your meeting on Monday.
So don't forget that and
don't try to do it at the end.
I think that's all
the announcements.
Yeah?
OK.
So today's class is
going to be, we're
going to start talking
about project management.
What we are trying to do
with project management
is give you the just
in time version of it.
Which is to say, we're
trying to give you
the pieces of project
management you
need for the project you're on
right now in the state it's on.
And we're going to be
just in time project
management for project two.
And then on project
three, we're going
to expect you to use all those
pieces from the beginning
and all the way
through on your own
so that you'll have had a
walkthrough on project two,
a practice run on project
three, and then on project four
hopefully you will need
it and it will all work.
That's sort of the philosophy.
So we are giving it out
to you in bits and pieces,
and I acknowledge that.
I suspect that between today's
lecture and Monday's lecture,
we will have covered
sort of all the things we
expect you to be doing as
far as project management.
But today's lecture's
sort of the first half
and then Monday's will
be the second half
and tidying it all up.
So we're going to do
a brief history of how
project management was done
in the past in the software
industry.
We're going to talk about agile,
which is where many software
companies are using
now or moving to
with various levels of success.
Not all of them, unfortunately.
Then we're going
to start getting
into the nitty gritty of
the agile management system
that our lab is most familiar
with, which is Scrum.
And we'll start walking through
all the aspects of Scrum.
We will concentrate today
on product backlogs.
We'll take a break
from our lecture
and you guys will have the
opportunity in about a half
an hour to make your
own project backlogs
and then do very quick
presentations of sort
of, OK, here are the top
features that we found
in our product backlog when we
sat down and actually thought
about our game.
Then unfortunately I will get
up and start talking again.
We'll go over the meetings
in Scrum, how they run,
and what they are,
and why you do them,
and their level of importance.
And when we hit the
end of that, we'll
have you run a
small one yourself
and then we will actually get
to use the rest of time in class
for working in your groups
and working on your projects.
OK?
Any questions?
And let's go.
Now that we have the
class interest guides,
I can mostly skip that slide.
OK.
So you all took
this class to learn
how to create video games.
We, however, created this class
to teach project management
in video games.
Fortunately, we're all
going to get what we want,
because you really do need
some good project management
skills to successfully
make video games.
The better your
project management,
the better your chances of
coming out with a good game.
It won't guarantee it.
You need a lot of other
good things as well.
But I can pretty much guarantee
that without any project
management, your attempt to
make a game is going to fail.
So do try to listen.
I know this is some of the less
interesting stuff we cover,
especially coming after the
high of prototyping and making
games.
But this is just as
important as prototyping.
So what is project management?
Let's start by explaining what
the heck I'm talking about.
Project management is the
work on the project that's
devoted to planning, organizing,
securing, motivating,
and controlling the resources
to successfully complete
a project.
You've all heard of fast,
good, cheap, pick two.
Most projects are actually lucky
if they manage to choose one.
And it's project
management allows
them to figure out
whether they're
going to be fast or good or
good or cheap or whatever.
Project management is
all about predicting.
I knew the definition up
there says controlling,
but you really can't control
a whole lot of things.
What you can do is you
can make some estimates,
make some predictions, plan for
the risks you're going to run
into and then deal with them.
So it's really about
predicting what you're
going to need to do when
you're going to need to do it
and how you're going
to need to do it.
If you follow game and
other large software project
releases, you know
how rarely they
actually manage to
come out on time
with all of their features.
Games are especially
famous for coming out late,
for being over
budget, and for often
under delivering the shiny
things that they had mentioned.
Can anybody think of a
couple of games recently
that have done that?
No?
AUDIENCE: [INAUDIBLE].
SARA VERRILLI: Yep.
OK definitions may vary.
But yeah, it is
really, really common
for games to come out
late and over budget.
Here's another one.
Anybody name a tripe A
game that shipped on time?
I'm not actually sure
I can do this one.
With all the features
that they predicted.
Can anyone name one?
AUDIENCE: [INAUDIBLE].
SARA VERRILLI: Call Of Duty.
OK.
That's impressive.
OK, so how do you manage
to plan what you're
going to need to do, get all
of your resources in order,
have them all in the right
place at the right time,
and get them working together?
The old model of doing
this, which is actually
the model that I worked at
in several studios and I've
seen several other
studios that use it.
And it doesn't work very well.
But sort of the
model that things
started with in the industry
and grew from is waterfall.
And I want to talk
about that because it's
where some studios still are
and it's where a lot of software
projects still are.
And so it's good to understand
what the history of project
management is so you understand
some of the problems that
were found in that model that
the agile model is trying
to fix.
Agile has its own problems
and we'll talk about them.
But let's start with waterfall.
So the very traditional
tool is waterfall, where
you prepare for every stage.
You sort of finish
every stage 100%
and then you move on to the
next stage to see what happens.
First you need your spec.
You need your requirements.
Which in game design is sort
of your concept and your design
phase.
You figure out what
you want to make,
you figure out what
all the features are.
You also figure out
other constraints
like what is your
budget, how long
you're going to take, what
can the people on your team
actually do.
If you don't have a
physics programmer,
you probably don't want
to make a physics game.
All that pulling all
those constraints together
to make a design
that is reasonable
that works with the things
that you think you're
going to have to work with.
That concepting
and design is going
to flow into pre-production
where you sit there
and you made a whole
lot of assumptions
in design and concept.
And in pre-production,
you test them
in very small scale usually.
You figure out if
people can actually
do the things they said
they were going to do.
You figure out if the
software you were going to buy
is actually going to work or
not and all those other details.
Using the data you
gathered in pre-production,
you create a whole lot
of big fancy schedules.
And using those schedules,
you hire up your team
and you go into production,
and you implement everything
and you get it all built.
Well, you get most of it built.
Then in game processes,
you go into alpha
when you've got most
of your features in.
And that's when you usually
bring on a few small testers
to do a little bit of
testing and make sure
your code is working the
way you expect it to.
Then when you've got
all your features in,
it's mostly working,
you go into beta.
You bring on more testers.
In big studios these
days it's often
common to have open betas.
If you're looking at
some sort of massive game
where you're not going
to hire 100,000 testers.
So what you do is
you have an open beta
and you let people play the
game for free in exchange
for testing it.
That hopefully nails out the
rest of your big problems
and then you ship it.
Does anyone see the big problem
with games in this model?
It's a little subtle,
so it's easy to miss.
It's OK if you don't.
Yeah?
AUDIENCE: [INAUDIBLE].
SARA VERRILLI: That is it.
Almost all of the testing
is here at the end at beta.
It's a little late to
change your design if you're
doing all of your
testing at the end.
if you're doing all
your testing at the end,
the team can't respond to it.
They can't fix things.
And that is where a lot of
schedules get stretched out
and a lot of budgets
get stretched out.
Because all of the
planning you had goes out
the door somewhere
around early alpha
and you have to start
reworking your whole system.
The problem here is, of
course, you can't predict fun.
You can't design an
engaging experience
without interacting
with the people who
are going to be
using it, which means
not just the people
on your team,
not just the small
group of pre-prod.
I mean, in waterfall
they do do testing.
In pre-production you
test, in design, you test.
But you're almost always
testing with a very small group
of people.
The other designers
on your team,
the other people
in your company.
You're not going
for any big testing.
You're not going for
any user testing.
You're not finding
out how the people who
are actually going
to use your product
are going to react to it.
So in many ways
it's doomed to fail.
There's not a lot
you can do about it.
None of these problems
are unique to games.
It's why big software
projects often run over budget
and run into a lot
of feature creep.
But games have the
really unique problem
that their primary feature,
their primary goal,
is to be interesting
and engaging to use.
If you are looking at business
software, and it's hard to use
and it's annoying, but it does
all the calculations you need
and it's the one that the tech
department bought and deployed,
you're going to use it.
There's just no
getting around it.
But nobody has to
play Call of Duty.
Nobody has to turn on a
particular game on their phone
and play it.
So if a game fails in that
sort of user connection,
it has completely failed.
There's nothing else you can do.
It really kind of comes down
to, if your users aren't happy,
it's not a good game.
Your design changes,
your schedule changes,
and your project
management has now--
all of the time you put
in project management has
mostly a waste of time.
So what do you do instead?
First of all, you think about
building design iteration
into your project
management model.
You assume that you're going
to be iterating and changing
your design all the way around.
That is what the agile project
management movement I guess
is the right way to put
it was invented from.
There are actually
several different types
of project management
that call themselves agile
and there are several
different techniques and tricks
that call themselves agile.
The one thing that
they have in common
is they try to follow the
agile manifesto, which
is individuals interactions
over processes and tools.
Does anyone want to--
let's just go ahead.
Working software over
comprehensive documentation.
Customer collaboration
over contract negotiation.
And responding to change
over following a plan.
So for the first one,
individuals and interactions,
means it's better to get
up and talk to someone
than to send a whole lot
of change requests over.
Working software.
That's why we ask for
paper prototypes and vision
statements instead of
a big design document.
It's why we want to see what
it's doing rather than having
you tell us what it will do.
You don't really have so
much customer collaboration.
So you don't even have
to worry about signing
contracts and getting people
to observe milestones.
That's less of a problem
in a class specifically.
And responding to change
over following plan
means that if you discover what
you're doing isn't working,
you sit down and
you figure out how
to fix it rather than continuing
to go down the rabbit hole.
PROFESSOR: I just want to
state that everything on this
are good things to do.
Even the things that are
sort of low in priority.
It's good to have
processes and tools.
But it's more
important that you have
good interactions between the
individuals in your group.
Say if you are saying,
no, I can't actually
get up and talk to
this person because we
have a process that
we have to follow.
Then you're now prioritizing
incorrectly [INAUDIBLE].
I guess the [INAUDIBLE]
a lot of your classmates
are going to be people who
are going to play your games.
And you [INAUDIBLE]
collaboration
is important in that sense
because you just replace that
with work with your players.
Work with the people who
are going to play your game.
And yes, we did specify this
is what we want you to see.
This is what we wanted
to see in the game
that they are going to create.
That's my contract.
Well, that's less important
than actually coming and talking
to us about problems
that you might
be having and [INAUDIBLE].
Don't just use our syllabus as a
laundry list of things that you
have to do [INAUDIBLE].
SARA VERRILLI: Yeah.
Yeah.
Thank you.
So the model of making
a software project.
I keep wanting to say game,
but this is for any software,
actually, agile model.
Is that the project start you've
got your vision and your idea
what you're making.
And then on every
iteration, you go
through every step, essentially,
of the waterfall process.
You do a little bit of design,
a little bit of detailed design.
You do a little bit
of implementation
of that particular chunk of
the design you've just created.
Then you spend some time
testing it to make sure
that, A, it works the way
you expect it to, and B,
it's achieving the
result you want to get.
I.e.
the feature does
what you expect it
to do as far as improving
the quality of your project.
Then you spend some
time reviewing what
your overall project is doing.
Is it still going
the same direction
you thought it would be going
at the start of project?
Is that the direction
you want to be going in?
And then you can modify
your plan accordingly
and you start over
with another iteration.
The big savings you have
here and the way in which
agile management
tends to save time
over waterfall management
in this project
is you spend less time designing
features that people don't want
and more time working on the
features that people do want.
And that's actually where
the big time savings is.
Agile can't make you
write code faster.
What it can do is make sure
that the code you're writing
is the code you want
as opposed to the code
that you end up cutting
at the end of the project.
Some caveats before
we start actually
talking about how this applies
to you and your project.
Agile is good, not perfect.
Which means once you've
learned the tools and processes
for agile development,
you will want
to keep adjusting
and improving them.
You may discover
that we're going
to give you a set of outlines
and a baker's list of things
to follow and a recipe
to do project management.
And you may discover
that following
some portions of this
recipe does not work well
for the group you're in.
Well the right thing to do
is to set those pieces aside
and figure out a way
to work around it.
A good agile team is always
adjusting their processes
and trying to improve them.
Agile assumes that
all of your developers
are interchangeable,
which they're not.
Different programmers
have different skills.
And on a game project
especially, you
have people who can do art,
people who are better design,
you have people who are
better at x or y or z.
They're not all interchangeable.
Which means that
it takes more work
to set up what your task
set that you can get done
in any particular period
of time on a project
than pure agile was.
Agile says, OK, you've
got this list of tasks.
You've got enough
time to do them.
They'll get done.
When you're making
a game, you have
to look more closely
at the dependencies
and who can get each of
those tasks done to make sure
that you have not in fact
arranged for two of your team
members to do
nothing this sprint
and two of your team
members to do twice as much
as they actually have time for.
Sprint is the iteration cycle.
I will explain it again later.
I'm trying not to
jump ahead and use
jargon I haven't introduced,
but it's sometimes a challenge.
Let me know if I use a phrase
that you don't understand,
because I will explain it
or redefine it for you.
Finally, and this
is a problem you're
likely to run into a
little bit less in class,
but you are more
likely to run into when
you go into the outside
world and you work
on teams with different people.
People trained in
different disciplines
communicate differently.
They have different terminology.
On game teams, this
is really hard.
Because you will often
find, and I'm not actually
trying to stereotype all
programmers talk like this
or all artists talk like that.
But it is the case
that the people
who do programming
and the people who
are creating your assets, be
they art or design or audio,
often will talk past each
other on specific problems.
The artist will not
be able to explain
why they can't meet
the programmer's
technical requirements
and the programmers
will be unwilling
to figure out why
it is the artist can't meet
those technical requirements.
They've given the
technical requirements.
Why don't you just make
something that works in it?
Since agile depends on
really good communication
and the willingness to
solve problems like this,
this can create a huge tie up,
especially in an agile team.
It can pretty much stop
anything from getting done.
So that's another big red
flag to be aware of when
you're using these methods.
OK.
So there's more than
one agile system.
The one that we
use, that we have
the people work in our
labs [INAUDIBLE] use,
is called Scrum.
Is anybody familiar with Scrum?
Yay, there's a few people.
Anybody used it at internships
and things like that?
OK.
All right.
So you guys can help your teams
out a little bit hopefully.
So Scrum has three buzz
words, and I may as well
go ahead and call them buzz
words, because that's really
what the are, that are
supposed to define it
and let you understand
what it is about.
They are transparency,
inspection, and adaptability.
You can think of them as
Scrum's vision statement.
Much shorter than a document.
Essentially, if you
are doing Scrum right,
all of your decisions and
processes are transparent.
Everyone on the team who needs
to be involved in a decision
is and anyone on the team
who wants to understand
why something was done can.
No one on the team should be
able to say at any point, well,
no one told me about that.
Because it's both the
team's responsibility
to share information and each
team member's responsibility
to stay informed.
Everything done by the team
is inspected at some point.
Decisions, processes, team
actions, deliverables, code.
The team thinks proactively
about what they're
doing, how they're doing it.
And if the team
discovers a problem,
for example, the build keeps
being broken every night,
the team doesn't just say,
oh, we'll work around it.
Instead it takes responsibility
figuring out how, why,
and fixing not just
the broken build,
but the processes that
led to the broken build.
And finally, which feeds
back into the other two,
the team is willing to adapt
any processes and decisions
to the reality they're
actually dealing with.
When they find a
structural problem,
for example, how does art
assets getting in the game?
Well right now we're having the
programmers hand load them in
and we're losing six hours of
programmer time every week.
Instead they sit down and
say, well, how do we fix this?
Do we take 12 hours
next sprint to code up
a tool that allows the
artist to put it in,
and then we'll save all
that time going forward?
Do we teach the artists how
do put their art in directly?
I've had this discussion
on a team in which we
were losing an awful lot of
time to programmers putting art
in game.
And the programmers
were convinced
it would be faster to
just keep putting it in
because it would take too
long to teach the artists how
to do it, despite the fact
that it was eating eight or 12
hours of programmer
time every week.
I still think they were wrong.
Anyway.
Note that I keep saying
team and team members.
In Scrum, the responsibility
for project management
doesn't sit with a producer or
design lead or the programming
lead.
It's the team's responsibility,
guided by the team members,
to manage their own project.
That doesn't mean
that a Scrum team
gets to do whatever they want.
They still have constraints,
requirements, expectations,
project handouts handed down
to them from managers, clients,
instructors, and other people.
But in exchange for taking
responsibility for the project
management, Scrum
teams do get to explain
to the producers, managers,
executives, and outside forces
just how much they think they
can achieve in a given time.
So you can go ahead
and ask a Scrum team
for the sky, the earth,
the stars, and the moon,
and an experienced and
empowered Scrum team
will explain that, OK, in
that time and on that budget,
we can get you a terrarium
with a fancy night light.
So how does this work?
With vocabulary.
There may or may
not be a quiz later.
So the project cycle.
This is the cycle of a whole
project with the internal cycle
right there in the middle
where you can see it.
Looking at it from sort
of the whole project life,
you've got pregame sprint, which
is-- let me start with this.
Let me start with
what a sprint is.
So a sprint is the way that
a Scrum project divides up
its design iteration cycle.
Sprint length depends
on the project
and what the team wants.
One month was an early standard.
But a lot of people are now
using two weeks instead.
In this class, we
encourage one week sprints,
given the length of the
projects and the sort of reality
of how much you can or
can't get done in a week.
So a six month project can
be divided into six one
[INAUDIBLE] sprints,
12 two week sprints
depending on what
the team wants to do.
So much like a
waterfall project,
you've got your design
and vision time.
You've got your
development time and then
you've got your wrapper time.
Your vision time
is going to be when
you're coming up with the
idea and the overall outline.
In many ways, that's
what you did on Monday.
That was kind is
you formed teams,
you got a vision statement.
Some people were
even sitting around
and making feature lists.
That's really your pregame
staging sprint right there.
In the development
sprints, that's
when you're actually
making the game.
And you're taking a couple
of features every sprint.
You're getting them working,
you're testing them,
and then you're moving on and
grabbing a few more features,
getting them working,
and testing them
until it all comes together.
Product backlog.
Does anybody here know
what a product backlog is?
Go ahead and tell me.
AUDIENCE: [INAUDIBLE].
SARA VERRILLI: Exactly.
Actually not in a
sprint, in the--
AUDIENCE: [INAUDIBLE].
SARA VERRILLI: In
the overall project.
Yeah, the product
backlog is in fact
the feature list
for the whole thing.
Once you've got it,
you take bits of it
off to make your sprint backlog.
The sprint backlog is what
gets done in every sprint.
Eventually hopefully your
product backlog is at 0.
And some teams, I'm afraid
of your teams are probably
not going to have
luxury of this,
take what's called a
wrapper sprint or two
to kind of hardening.
You can think of it as
polish and hardening.
Taking the time where you're
not putting in any new features
but you're making sure that
all the systems really do work.
They're kind of shakedown crews.
So that is the
overall project plan.
What does it look like on
the inside of the spirit?
Let me see if I can see
what that looks like.
There we go.
So here we have our big
pile of definitions.
So since you're doing a little
bit of project planning, design
implementation and
testing in every sprint,
you have to figure out
when and where you're
doing those things.
Scrum has a fairly I
don't want to say rigid,
but they do have a very well
defined set of processes
and tools to do that with.
So to handle project
planning and communication,
every sprint involves a set
of standardized meetings.
Sprint planning, daily
Scrum, sprint review,
and the retrospective.
To handle the features
and task management,
Scrum teams create and
use a set of tools.
Artifacts is what it's called.
The product backlog, the
sprint backlog, the task list,
and a Scrum board.
At the start of its
development sprint,
the team turns to its
product backlog, which is,
like we said, the feature list.
Holds what's called a sprint
planning meeting in which they
decide just how many of those
items that can get done.
That list of items that they're
moving from their product
backlog becomes
the sprint backlog.
From there they
break those features.
Because features coming off of
a backlog, usually fairly large.
So they'll break them down
into much smaller items called
tasks.
A task is just a
chunk of work that you
can estimate fairly well.
Having gotten that
big list of tasks,
they start working
their way through it.
Every day while they're
working on the project,
you'll hold a
daily Scrum meeting
where you talk about what you're
doing, how you're doing it,
what you hope to get done.
At the end of the
sprint, you end up
having a sprint
view where you take
a look at what you've got done.
You compared what you wanted to
get done with what you actually
did.
You go ahead and you adjust your
product backlog if you need to.
And then you hold a
retrospective meeting.
And that's where instead of
talking about the product
and specifically you're
talking about the team
and the processes.
That's where agile
tries to improve
the way the team
is working together
is the retrospective meeting.
And then you're ready for a
new sprint planning meeting
and the whole thing
starts over again.
OK, I'm almost done
throwing vocabulary at you.
And then I'll go
back and make sure
that I actually did define
all the vocabulary I've used.
So on the team, I
claimed that the team
was responsible for all
of its project management.
That's not quite true.
Teams typically have
three kinds of members.
There's you're sort of
average everyday team
member, who's someone
on the team working
to keep things running.
The team has a product owner,
may have a product owner.
In classic Scrum, you
always have a product owner.
Your teams probably won't.
It's much harder to have a
product owner on a student
team.
And the reason for that is
because the product owner
is the person who holds the
sole vision of the product.
For classic Scrum
teams, the product owner
is the person who creates
the product backlog,
helps them prioritize
it, and lets
them know which of their
features are the most important
and whether or not the
features as implemented
are working the
way they need to.
Your team may be
lucky enough to have
someone who has a good
enough grasp of the project.
And if you do, it's
really, really valuable.
It's really helpful to have
one person who you can turn to
and say, is this going to
work or is this working
or is this what we had in mind?
And have one person answer that
instead of having a big debate
over whether it does or not.
But on student teams, it
can be really hard to have
someone in that position.
So that's your product owner.
The other unique person on
your team is a Scrum master,
and you will need one of those.
The Scrum master is the lucky
person who runs the meetings,
serves as the facilitator
and the mediator,
and is in charge of making
sure that Scrum is followed
and the team is working
reasonably smoothly.
They frequently get
stuck with updating
product backlog, sprint
backlogs, task lists, Scrum
boards.
Whatever record
keeping paraphernalia
the team feels it needs to have.
Setting up meetings and
making sure they happen.
Try to think of the Scrum master
as a bit of the team coach
and as the keeper of
documents rather than
as the producer or the person
in charge of the project.
Just trying to keep
the backlogs straight,
keeping meetings flowing, and
keeping communication following
is a lot of work for one person.
You don't also want
to burden that person
with being in charge
of leading the team
and making all the
final decisions.
They often end up
drifting together.
And we see a lot.
And we also make
a slip of calling
the person who's serving
is the team Scrum
master as the producer.
See if you can try to keep
those two roles separate.
If you can let the
Scrum master just
be the person keeping
the team running
and you can let someone else
step into that kind of vision
holder, guide the team role.
OK?
All right, I think
that that is, in fact,
what I have to say on that.
Everybody think they have at
least a definition or an idea
for all of these words?
Here's the quiz later you see.
AUDIENCE: [INAUDIBLE].
SARA VERRILLI: OK.
Should I be mean
and choose the one
that I haven't defined
that nobody admitted to?
OK, who can tell me
what a Scrum board is?
AUDIENCE: [INAUDIBLE].
SARA VERRILLI: That's
exactly what it is.
So what a Scrum board
is is it's frequently,
if you've got a team that
all works in the same place,
it's usually a
big physical board
that you have room to put cards
with all the tasks on it on.
And you just have it
divided up into sections
and show the status
of each task.
By using a Scrum board, teams
can figure out exactly how far
along they are, what the
state of their project
is by just looking at the board.
Teams that are going
to end up working in
a much more distributed
fashion and who
don't have a designated
place to sort of leave
a Scrum board set up.
For example, you
guys are not going
to be able to Scrum boards up
on the back of the classroom
and come in and check up on
them every couple of days.
There are a couple
of online options.
And I will talk about
them when I actually talk
about Scrum boards
a little bit more,
asking you to get one set up.
PROFESSOR: Just out of
curiosity, who has already
got something like that?
Like an online site with
all your tasks on it?
AUDIENCE: We're using Trello.
PROFESSOR: Trello uses
exactly a Scrum board style
visual representation.
AUDIENCE: There's
also a Scrum plug
in for Trello for Chrome
that we can get points
if you're [INAUDIBLE].
PROFESSOR: I did not know that.
That's new.
SARA VERRILLI: Oh, that's new.
AUDIENCE: It's called Scrum
for Trello or something.
PROFESSOR: OK.
PROFESSOR: Scrum for Trello.
I'll google that.
What else?
I thought I saw
another hand go up.
What are you using?
AUDIENCE: Asana.
PROFESSOR: Asana?
OK.
[INAUDIBLE]
So is that just [INAUDIBLE]
card like representation,
or is it more like spreadsheet?
AUDIENCE: It's more
like a [INAUDIBLE].
PROFESSOR: And
multiplayers can do this?
SARA VERRILLI: Yeah, I
haven't used that site.
PROFESSOR: I don't
know any alternatives.
SARA VERRILLI: I will actually
talk about Scrum boards
a little bit more when we
actually have gotten around
to making our sprint
backlogs and task lists
and talking about the techniques
you used to make them.
OK, so we're finally
actually getting
to the action part
of this story.
And I'm lying there.
I'm not actually talk about
time boxing right now.
I went back and
updated my lecture
without updating my slides.
But we are going to
talk about user stories.
So let's talk about how
you make a product backlog.
Because it is not
just a feature list.
There's actually some
very important differences
between a feature list
and a product backlog
that makes a product backlog
a project management tool
as well as a design tool.
So it's an organized,
prioritized feature list.
So the team always knows what
the most important next feature
is.
So if I actually sat down and
looked at one of the product
backlog you've turned in,
every feature in your game
should be described or mentioned
in the product backlog.
And each item should
have a priority status
indicating how important it is,
when are you going to do it.
Are you going to do it first
or you're going do it last?
Or is this the one
that's going to get cut
when you realize you don't have
time to finish the project?
So how do you decide what goes
into it and how do you estimate
and how do you prioritize?
There's the big question.
So here is a sample
project backlog.
It's not for a game
but it's for some sort
of log in page or something.
But it serves pretty
much the same purpose.
This is sort of the
minimum you should
have in your product backlog.
Some people get
fancier and include
lots of extra information,
but that's not necessary.
Keeping it simple,
especially to start,
will make your life
a little bit easier.
If you discover there's
more information
you want to track here,
go ahead and do that.
But start with the basics.
The basics are an ID number.
ID number's not its priority.
It's actually in the order
of which we thought up
the features.
This is the fifth
feature we thought of.
IDs come in useful when
you start moving tasks off
of your backlog and
into your sprint backlog
and breaking them down
into smaller tasks.
So you can use your ID number
to know, oh yes, this feature is
the same as it is on
the product backlog
and all of these eight
tasks that came out of it
are all related to each
other, because they all still
have the ID number that goes
back to the original product
backlog.
Then you need a description.
This backlog is
using user stories,
which I'll explain in a moment.
But they all have sort
of the same pattern.
As an authorized user, I
want to create new account.
As a authorized user I want to.
As an unauthorized
user, I want to.
So that.
So there's your description
of what the feature is.
Then you need an estimation
of how big a job this is.
For the product backlog,
we don't actually
recommend trying to do
really fine estimation.
They're using numbers
in this backlog.
I should make a new one that
uses my preferred system, which
is actually just using the word
small, medium, large, extra
large.
And how big is small?
I'm not really sure.
When you first
create your backlog,
you won't be really sure either.
But you could probably
tell the difference
between a small feature
and a medium feature
and an extra large feature.
So when you go through and you
write down all your features,
you can say what are all
the smallest features here
and call this small.
What's bigger than that?
That's probably a medium.
What's the biggest
feature I can see here?
Make that a large.
When you're making
the product backlog,
you don't want to
spend a lot of time
figuring out estimation
and trying to figure out
exactly how many hours
it's going to take
and how many subtasks
are involved.
What you want to
do is get a feel
for the overall size of
the features and a feel
for how big they are in
relation to each other.
Because if you're
fairly good at saying
this is about the same size
feature is this and this
is about the same
size feature as that.
Once you realize that feature
A took you three hours
and you have four
other small features,
it's not that hard
to go, oh, so that's
a total of about 12 hours
between those four features.
So that is the format
of a product backlog.
Are there any questions?
No?
OK.
PROFESSOR: Just want to
point out occasionally you
come across a feature that's
actually not one feature.
It's actually a whole
bunch all rolled up in one.
Like multiplayer or
something like that.
SARA VERRILLI: Networking.
AUDIENCE: It's not
a single feature.
It's a whole bunch
of different things.
If you come across features that
clearly warp everything else
that you've got
on your list, you
should try to bring those down
and do small and large chunks.
So you can be like
multiplayer [INAUDIBLE],
multiplayer matchmaking.
All of these things
are separate features.
SARA VERRILLI: But I
will say that when you're
making your first pass
at a product backlog,
it's OK to stick multiplayer
on there as a feature
and then right next to
it, extra, extra large.
And realize you're going to come
back and break it down later.
When you're making your
first product backlog,
you don't want to be
worrying about, well,
what are all the little sub
features of multiplayer?
But you do want to go ahead and
acknowledge that, oh my gosh,
we've just put something
ginormous on the list.
And using a very
rough estimation tool
lets you do that and move onto
getting all of your features
in.
And then you can come
back and honestly
estimate them a lot more
finely when you're actually
thinking that you
might put them in
or when you're
actually determining
what their overall priority is
and how badly you want them.
Because if you end up deciding
you want to drop multiplayer,
there's no point having
spent a lot of time
dividing it up into 12
or 14 different features.
All right, so I
mentioned user stories
and I did not actually
define them very well,
and that's because I was going
to come along and define them
here.
So a user story is just
a very specific way
to describe a feature.
It is, I think, unique to Scrum.
Although there may be
other agile methodologies
that have stolen it as a
way of describing a feature.
And we're going to ask
you use user stories
for project two at least.
Just to get you familiar with
it and understand why we think
they're a neat idea.
You may end up deciding that you
don't like them and that's OK.
But we want you to at
least experiment with them.
So the goal of the user story is
to help you phrase your feature
in a clearly testable
and understandable manner
to someone who did not help
you write the document.
OK?
So a user story
follows the formula
of as the person who is going
to use this feature, which
could be the user.
It could be the designer if
you're creating a level editor.
Could be the artist if you're
creating something for them.
It could be another
set of coders
if you're creating tools.
But the important
thing is to recognize
who are you making this feature
for and who is going to use it.
Then you want to describe
what it's going to do.
And that description should
be something you can test.
So that when someone goes ahead
and gets this completed feature
on the other end, they
can go in pretending
to be whoever that person
is, use that feature,
and confirm that it works.
Finally, you want
the end third, which
is so that-- explain the reason
why you want the feature there.
What is the purpose of
this feature in your game?
What is it achieving?
Can anybody think
about why this is
an interesting or useful format
for stating a feature in?
Can you see any benefits in it?
I can go ahead and tell you
what we think the benefits are,
but I'm wondering if you
guys can think of any.
AUDIENCE: It's testable
and focused on the player,
or other relative entity.
SARA VERRILLI: Yep.
That's one.
OK.
So it's testable,
which means that you
can confirm it's working.
It's focused on the person
who's going to use it.
We're going back to that
sort of user oriented
creation of product.
And finally, having
the reason there
means that if the person
who originally asked
for the feature did not
understand the game well enough
and asked for a lousy feature
or one that doesn't work well
with the game, the person
who is going to implement it
can come back and say, hey,
you asked for a physics engine.
But you want it so the player
can drop rocks into a pool
and watch the rocks sink.
That's the only use of
your physics engine.
We can make this a
lot faster and easier
if I write an animation hack
that shows this happening.
And we can give you
some sliders to control
how fast it falls depending
on the weight of the rock.
And people will often
say they want something
that is bigger or smaller
or doesn't actually
do what they want it to do.
It's really common when
you're writing features.
It happens all the time.
And so having that
reason there means
that the team can go back
and do a double check when
they actually go to implement
it that the thing that's
being asked for is something
that is really needed.
And so it puts a double check
right back in the feature.
And it's not as good as
going back and talking
to the person who
wrote the feature,
but it's at least a
warning signal telling you
that you might want
to go talk to someone
and make sure this is
really what they need
and really what they want.
So I think I already
just went over this.
So because user stories
have that check in them,
you can make sure
you're actually
doing the work you want to
do and not some other work.
One of the things that
agile is really trying to do
is focus on making sure that
you're not doing extra work.
You're not doing work that
doesn't need to be done,
that's going to
get cut later on.
And so a lot of the tools
and a lot of the processes
and a lot of the language
and a lot of meetings
are all about making sure
that before you go out and put
a lot of time into something,
it's really the thing that you
want to be doing.
And user stories are
just one more way
to add that check
into your process.
I'm going to skip on time
boxing right now because I've
got a better discussion.
It's more relevant to meetings.
And I'd rather talk
about it in meetings.
So we'll skip talking
about it there.
OK, that is actually
the first two thirds
of the lecture for today.
And I was going to propose
that we take a 10 minute break.
And when you come
back, it will be
time to make a product
backlog for your team.
I'm going to give you
half an hour to do it in.
And that half an hour
will also include the time
to prepare a two minute
presentation on what
the features for
your product are
and what an updated
vision statement
for your game, since things
may have shifted a bit when
you added new people.
No visual aids.
Just come up, talk
for up to two minutes.
It's OK if you talk for less.
The faster we get
through presentations,
the faster we get
to other things.
And then we'll move on to
talking about meetings.
AUDIENCE: Is there a sample
on Stellar, a sample backlog
on Stellar?
SARA VERRILLI: There is not
the sample backlog on Stellar,
I think.
We think there is?
AUDIENCE: If there
is, we'll put it up
by the time we get
back from break.
SARA VERRILLI: OK.
Yeah, in many ways I actually
recommend you go into Google
and create a Google spreadsheet.
Give it an ID and priority and
status and going from there.
But yeah.
OK.
AUDIENCE: [INAUDIBLE].
SARA VERRILLI: Is it there?
Yes, sample product backlog.
OK.
It is there.
Thank you, Rick.
I forgot to check on Stellar.
All right, that
said, it is 1:52.
Come back in 10 minutes and
start working on your product
backlogs.
But go stretch your
legs a little bit.
OK so it's 2:02.
If you are not already sitting
in your project groups,
you should probably go
ahead and get together
in your project teams.
At 2:32.
2:35, we'll give you
some to move around.
2:35 we will go ahead and we'll
make a list for signing up
and we'll run through
the presentations.
OK?
If there any questions or you
want to know what's going on,
if you'd like some advice, we'll
be all hanging on down here.
So please feel free
to come and ask us
for any advice or any
help or anything you need.
OK?
OK.
One moment.
We don't need that
plugged in right now.
OK.
So let's go ahead.
I'm guessing everybody's
ready for presentations.
OK.
Then let's ask Comcastic
to come on down.
STUDENT 1: OK.
So the goal of
Comcastic is to be
able to place internet
service stations into towns
so that you can service
neighborhood and get money.
And then eventually you want
to build your monopoly cable
empire to become very wealthy.
And so the core features
that are necessary
in order to enable us are being
able to look at the town map.
You need to be able
to place pieces.
You need to be able
to rotate the pieces
because the orientation
does matter.
You also need to be able to
have some kind of [INAUDIBLE],
so you want like an end turn
button or something that
happens when you place a piece.
And that will also give you the
money results for that turn.
You also need to be able to
know how much money you have
and be able to place
pieces only on legal spots
and to be able to
start the game,
quit the game, things like that.
So those are the core
features of Comcastic.
SARA VERRILLI: Thank you.
[APPLAUSE]
All right, Blind Alien.
STUDENT 2: Blind
Alien's team goal
is to create a creepy
and enthralling game.
In order to do
that, we first need
to have really basic
structure, which is what we're
going to focus on this week.
We're going to focus on having
first a start menu, where
we can just say the
instructions really fast
and input the number of
aliens, which is going
to be important for testing.
Because you need to be able
to change things quickly.
And then we're going to have
the main screen, a character,
character movement,
aliens, alien movement,
and then this
weekend we're going
to get up together and
work on the interactions
of those aliens
and the character
and then work on shooting.
So that's what
we're focusing on.
Thank you.
[APPLAUSE]
SARA VERRILLI: All right.
Plunder Winds.
STUDENT 3: Hi.
So for Plunder Winds we're
implementing a similar game
to our paper prototype.
So we're a grid based, or
tile based, turn based game.
And built around
three core mechanics.
Our mechanics are a
random encounter mechanic
where every square possibly
has either treasure or pirates.
A exploration mechanic
where you revealed
the risk level of nearby tiles.
And so that can
change what pirates
will do to you if you actually
land on that square, something
like that.
And then a wind
mechanic, which controls
which directions you can move.
And so our goals
for this week are
to try and implement as much as
our core mechanics as possible
so that we can possibly
look into stretch goals
for our games, like possibly
implementing one or two
unique abilities to improve
playability over next week.
SARA VERRILLI: Thank you.
[APPLAUSE]
Lost Underground.
STUDENT 4: Lost Underground.
Scared for a second.
The overall goal is to create
a game that people will like.
It'll be random and
will allow exploration.
Our goals for the
weekend are to create
the basic bare bones you
could walk around a map,
you can drop bombs.
Make the most basic part
out and then build up
on everything else.
The features that we're
thinking of planning.
The most important
features of the game,
which are the ones we'll
be working on this weekend,
will just be being
able to move around
the board, a board, a general
board, dropping bombs,
and possibly the most basic,
nice looking art that we can.
[APPLAUSE]
SARA VERRILLI: Beaver Evolution.
PROFESSOR: Just a quick
point, the most basic art
that you can make is
probably not the nicest
looking art you can make.
So just [INAUDIBLE].
STUDENT 5: All right,
so Beaver Evolution
is a 2D turn based game
where you're trying
to progress your beaver colony.
And one of our main core
mechanics of this game
is that you have three
different choices
you can make every turn
in order to progress
to one of the many wind
conditions we have in the game.
So this is going to be
one of our main focus
for this weekend.
We want to be able
to implement a board,
want to be able sort of
select how to build our dams,
and we want to
make it really easy
to incorporate the three
different choices we
have every turn.
So our main focus will be
also on creating a UI, which
makes it really to sort of
figure out what you can do,
what sort of resources
you have, like how far
is your beaver
colony progressing.
And I think our
second main mechanic,
which is including
the randomness
factor, such as the disasters
and that kind of stuff.
That sort of stuff can be
added later in the projects.
We don't need to focus on that.
Right now we just
want to focus on being
sure we can play
through the game,
make sure that's not
confusing to the player,
and that you can
do it without sort
of adding any sort
of the features that
require more balance.
[APPLAUSE]
SARA VERRILLI: Magi Dice.
STUDENT 6: Hi, we're Magi Dice.
We want to make a fun,
engaging puzzle games where
the player moves around
dice on a board to try
and using modular arithmetic
create 0's and set
of combo chains.
So our goal for the first
week is, first of all, just
set up the board and the
dice so that the player can
see what they're doing.
And then our immediate
following goal
is to incentivize
players to create combos
that multiple moves earn them,
like, create 0s in a row.
And we want to do this by
giving them more points
and having a pretty UI
so they're incentivized
to set up and do fun stuff.
[APPLAUSE]
SARA VERRILLI:
Sparkly Redemption.
STUDENT 7: OK,
Sparkly Redemption.
2D real time game
where you shoot
monsters and pick up sparklies.
And the important thing is that
when you pick up sparklies,
you either get a different
weapon or the monsters
change their behavior.
That means the core thing
we really need to implement
is to have a [INAUDIBLE] you
can move around, have monsters
with at these two
different behaviors,
because the swapping
is important,
and have sparklies
that you can pick up.
[INAUDIBLE] needs at least
two different attacks.
So that's probably what we're
going to focus on at this time.
I guess it'll also be sort of
important to have it be easily
visible at a glance
the difference
what the current
monster behavior is,
what your current
attack is, and I guess
how many sparklies you have.
And so I guess it's not the
most, most critical thing
to have this week, but
we're probably also going
to try and get it so that
you can see what's going on
and not just have to
sort of guess at it.
[APPLAUSE]
SARA VERRILLI: All right.
OK.
So you did product backlogs.
On Monday you did a fair
chunk of your planning sprint.
You finished up sort of the
second half of that today
by getting your product
backlog pulled together.
To close out today, I'm going
to talk about the meetings that
are involved in Scrum.
We're not actually going
to have you hold them
all here because A, they
wouldn't be very useful.
It would take a lot of time.
And because we're introducing
Scrum alongside the project,
the timing doesn't fall
well as we introduce things,
would be the right
way to put it.
We are hoping you will use
these meetings in project three
as you start planning
out your project
and figuring things out.
So I do want to
talk about how you
run the meetings we
talked about that
occur within a Scrum cycle.
But first I'm just going
to talk about meetings.
And meetings as a force for good
as opposed to how most of us
probably think of
them, which is, let's
be honest, as a force for evil.
As a force for evil, they
suck away a lot of time.
If you have a six person
team and you have a one hour
meeting, that's six
hours of work gone.
So you want to make sure
that those six hours of work
are actually good and
useful hours of work.
There are three primary
tools to do this that we're
going to talk about here.
We're going to talk about time
boxing, having a clear agenda,
and having involved
participants.
Has anybody here
heard of time boxing
and do you know what
that concept is?
OK.
Timeboxing is when you decide
before you have the meeting
or before you start any
particular activity how
much time you're
going to let it take.
You give the task a
time budget and you
don't exceed that time budget.
For example, sprints are
just one big time box.
You're defining that.
Here's the set of things
we're going to get done,
we have a week to do them in.
When we're done with
that week, we're
going to stop and see
how much we got done,
and we're going to move on
from there and reevaluate.
Meetings can do this too.
And all meetings in Scrum
should be time boxed.
It's one of the
classic Scrum rules
is that meetings are time boxed.
They have a limited amount
of time you spend on them.
Time boxing acknowledges
that there's
sort of a maximum
amount of time you
can spend on any particular
problem before any time
after that is wasted.
It does mean that
you won't always
reach the perfect solution.
Because if you've given yourself
an hour to discuss a problem
and you've talked
about it for an hour
and you haven't quite
come to a great solution,
you stop talking anyway.
You decide what the
most reasonable solution
you've talked about is and
you go ahead and do that.
It's sort of an
implementation of a theory
that the perfect is
the enemy of the good.
It may be that if you went ahead
and talked for another hour,
you would find the perfect and
ideal solution to the problem.
But it's also very
possible that you're just
going to spend another
hour talking about it.
It may be better and
it usually is better
to go ahead with the
best solution you
came up with and start
implementing that
and see how it works.
So that's the idea
behind time boxing.
Clear agendas.
If you don't know why
you're having a meeting,
you probably shouldn't
be having it.
The meetings that
Scrum recommends
come with a built in agenda
for what you want to do.
You'll probably have
to have other meetings.
Because at point you'll
have to talk about
to figure out how your
version control is working
or how this feature is working
or how the art assets go
into the game or what
kind of sound assets
you're going to have.
Before you go ahead
and have that meeting,
make sure you know
what the goal of it
is, what you want to come
out of it with, and honestly,
leading into the next
point, who actually need
to be there at the meeting.
Not all meetings
require the whole team.
A lot of meetings are really
good as just one on one
conversations or just a
small group of people,
a subgroup of people who are
working on a particular task
and get together
and talk about it
without including everyone else.
The other half of
involved participants
is if you are in a
meeting, be in the meeting.
Don't be coding
in the background.
Don't be checking your cell
phone and texting something.
Don't work on a problem set.
Go ahead and be there.
Accept that you have dedicated
the next 15 or 20 minutes
to working with your
coworkers to solve
this particular problem.
Get the problem solved, get the
meeting over, and then get back
to doing useful things.
So those really are the
ways to make meetings useful
and to make them work for
you rather than working
against you.
All right, that
said I'm now going
to go ahead and talk a little
bit about each of the meetings.
So starting at the
sprint planning meeting,
which you've actually
already mostly done.
We will do it in class
on-- you've already
done a good chunk of that, which
is making the product backlog.
We're going to do
this on Monday.
We're actually going to go ahead
and take your product backlog
and break it down into
a sprint task list
and start making tasks.
So we will have a in class
sprint planning meeting
for your next sprint next week.
But a sprint planning
meaning sets the team's goals
for the sprint and has
the deliverable, its goal,
of a sprint backlog
and an estimated task
list for the sprint.
So you know exactly
how many hours of work
you think you are going to
get done over the next week.
And it is time boxed
to one to two hours.
For a team your size,
one hour's probably good.
For an inexperienced
team your size,
1 and a half hours might
actually be better.
So the more you do
this, the faster
you get at it because
the easier it gets.
At the end of the sprint,
on the other side of it,
is the sprint review meeting.
It has the deliverables of
demonstrating your working
product, in this case
your finished project two.
It is a chance for your team
to stop and review and evaluate
your product and decide if
that's actually what you want.
If you have clients to go
ahead and say yes, that's
what we want, keep
working in that direction.
Or to say, oh my gosh,
this is exactly not
what we were thinking of.
Quick, change everything.
So the other thing you do
in the sprint review meeting
after you've
reviewed the product
is change and update
your product backlog.
Because it may be
some of the features
that you thought were
really important before you
went into this sprint
have turned out
to be less important.
Or it might be that you
thought of five new features
that you really need
to put into the game
and that it's worth cutting
some of the other features you
already had on the list.
So the sprint review meeting
sets up your sprint planning
meeting by getting your
product backlog in shape
to go and prepare
for the next sprint.
It also is time boxed
to about one hour,
again, for a team your size.
The other end of sprint
meeting is the retrospective,
which is not the same
as the sprint review.
A lot of teams try to
smash a sprint review
meeting and a retrospective
meaning into the same one.
And they have very
different purposes.
Sprint review meeting is all
about reviewing your product.
The retrospective is about
reviewing your process.
It's about talking
about the team.
Ideally, it kind of
recognizes the things
that went right, the
things that went wrong,
and generates a short list,
at least one or two items,
of things to do
differently next time
because they will improve
the things that happened.
So it's a forward looking
meeting despite its name.
The name is retrospective.
It's looking back at
what happened in the past
to see what you can do
better in the future.
If you do your team
retrospective well,
it actually will
be a lot of what
we're asking for in our
postmortem write ups.
Because really that's what we're
looking for in the postmortems
is understanding what
you did, why you did it,
how it could be improved.
We want to know what
sinkholes you fell into
and how you climbed
out of them and how
you would build a bridge
over the sinkhole next time
so you don't fall into it.
Finally, there's
the daily Scrum.
And this is the meaning
that happens it regularly
over the sprint.
Every day, or if your team
is not meeting every day,
every time your team meets.
The goal of the daily
Scrum is to keep
the team accountable
to each other
and to encourage
communication across the team.
If everyone's being
honest at the daily scrum,
there's really no
excuse for anyone
to not know the full state
of the project, especially
when it's combined with a Scrum
board with all the tasks up.
Daily Scrum are
also actually called
daily standups,
because a lot of teams
do them standing up in
order to keep them short.
Classically it's time
boxed at 15 minutes.
For teams your size,
five to six minutes
is probably actually enough.
Because all each
person has to do
is stand up and answer
these three questions.
What did you yesterday or
since our last meeting?
So what have you gotten done?
What are you going to do today?
What's on your task list?
And finally, what is keeping
you from getting things done?
What's blocking you?
How come you can't
get things done?
And sometimes the
answer is nothing
and sometimes the answer
is something, in which case
it needs to get dealt with.
The place where daily Scrum
often go wrong and end up
taking longer than their
five minutes or 15 minutes
is when people start mentioning
what they're being blocked by
and everyone jumps in to
help them solve the problem.
That's not actually what
you do at a daily Scrum.
You don't solve the
problem at the daily Scrum.
You mention it, someone
makes a note of it
so everyone's aware of it,
you get the meeting over,
and then the people
who actually need
to be involved to
solve the problem
talk to solve the problem.
Once again, it's invoking
that principle of,
if you don't need to be at a
meeting, don't be at a meeting.
So that is my comment
on daily Scrums.
And I was going to have you
guys try and do one today,
but I actually don't think
that would be very useful.
I think you've already really
probably done a lot of that
in sitting down and talking
about your product backlogs.
So I think I would prefer
to go ahead and close out
my lecture here and give
you the rest of the hour
to continue working in your
teams on your projects.
PROFESSOR: One thing
we can recommend
is that since most
of your teams seem
to be planning on meeting
up sometime between now
and Monday-- and I
certainly encourage
that-- plan to do this
during that next meeting,
if it's on the weekend, if it's
on Friday, if it's tomorrow.
Whenever that is, do this
and ask every single person
these three questions.
And be prepared,
personally prepared,
to answer all of
the three questions.
The thing that could be
blocking you is you've
got a horrible head cold.
Your computer just fried.
[INAUDIBLE]
I have a problem with
my web game engine.
And there's probably
somebody else
on the team who can help
you figure that out.
[INAUDIBLE]
It could be another class
that's giving you problems.
That's also a
perfectly fine answer.
You want your team to
know what's preventing you
from getting stuff done.
SARA VERRILLI: The other thing
you should do over this weekend
and have chosen by the
time you come in on Monday
is a Scrum master for your team.
And from the instructor's
point of view,
that's the person
who is primarily
responsible for
uploading documents,
vision documents, product
backlogs, design change
logs, making sure that we
have a link to your project
when the project is done.
Because we don't need
everyone on the team
to do the joint team turns.
We really only need
one person to do it.
From the team's point of
view, should be the person
helping you do Scrum.
And that's all I have for today.
So do you have
anything else, Rick?
RICK EBERHARDT: Deadlines.
So turn in your
vision documents,
the ones you just
worked on, that you
updated with you new team.
Turn them into Stellar by the
end of class today please.
SARA VERRILLI: I
was telling people
since we had the date wrong,
in case something went horribly
awry, they had until the
end of the day today.
