Hi, this is Ray Sheen.
I've been talking in the abstract about the Agile Scrum Process.
It's now time to get more specific and describe the process.
Whenever I am discussing project management,
it seems that the first question is about schedule.
So let me explain how an Agile/Scrum project is organized from
a schedule perspective.
An Agile/Scrum project uses a series of time boxed sprints.
The Sprints are usually two to four weeks in duration, and
each has a set of deliverables associated with it.
If you're not familiar with the term time box,
it is a scheduling approach that sets a finite amount of time for an activity.
When the time is up, the activity stops at whatever state it is.
The scope of that portion of the project is not fixed.
Rather, it expands or contracts to fit within the time box.
So the project is charted with an overall time box.
The project end date is fixed before the scope and resources are clarified.
Often, the project will be divided into a set of releases.
Each release has a minimally viable product definition,
that is what the team will strive for.
That means that the early releases will not have all the bells and whistles or
finishing touches, but it will be something that works.
Theoretically, it could be released or
commercialized to get feedback from the customers and users.
Many times, the early releases are provided to a small subset of users
with the understanding that the project is not finished but
in order to get feedback on the performance of what is being created.
On a small project there may only be one release.
Releases are often organized into a series of Sprints.
A Sprint is a primary planning and
execution block of work in an Agile/Scrum project.
It is time boxed, usually for two to four weeks.
Most releases will have several Sprints.
The Sprints are managed through the daily scrum meetings and activities.
Each day at the scrum meeting, the work that has been completed is summarized and
acknowledged.
So that is how the overall schedule looks, let's get into the steps of the process.
The numbers for
the steps I'm using is consistent with that used by the Scrum Alliance.
However, I believe, we need this first step which I call step zero.
This is the vision of the future state of the product or
process, that the team will work with.
It provides an alignment direction for their activities.
Its not detailed requirements document, it's more like a statement of
business impact.
Step one is to create the product backlog.
I will spend a lot more time talking about the product backlog, but for
now, consider it to be a list of the wants and
needs that are expressed in a prioritized list of deliverables.
Step two, is to assign a Scrum team.
if you are doing multiple Sprints, the team often stays in place from Sprint to
Sprint, but sometimes an individual will be swapped out or added to the team.
This team is dedicated to only work on the Sprint during the time of the Sprint, so
they need to be identified in enough time that their schedules can be cleared.
Step three is Sprint planning.
I'll spend several sessions discussing techniques for organizing and
estimating the work in the Sprint.
We won't be using the standard project planning tools, so
we have a number of new tools to introduce.
Step four is to execute the Sprint.
Again, we will spend several sessions talking about how this is handled and
how we assess our progress during the Sprint.
Step 5 is the Sprint Demo.
This is the time when the Scrum Team demonstrates the deliverables that
have been created.
It can often take hours and involves many people.
It is the only major external review of the Sprint activities.
Step six is the Sprint Refinement.
Each Sprint only does a subset of the overall project deliverables.
But after the completion of the Sprint and the Sprint Demo,
there are often changes to the product backlog based upon both customer and
stakeholder feedback and experience gained during the Sprint.
The definition of some items in the backlog and
the prioritization of those items are revised and updated.
The final step, step 7 is the Sprint Retrospective.
This is a meeting by the Scrum Team to determine what went well and
what needs to be improved.
Essentially, the lessons learned or after action report for the Sprint.
The organization of a project into releases and Sprints and the steps for
conducting a Sprint provide the framework for
how to plan and control an Agile/Scrum project.