User Icon

CDP Agile Courseware

Welcome to the Agile Courseware website. Here, you will be able to review topics learned in the methodology courseware, refresh your knowledge with interactive quizzes and watch instructional videos. Please sign in to access your profile information.

Select a lesson. Take the quiz at the end to move on to the next topic.

Select A Lesson

Lesson 1

What is Agile?
How to be Agile

What Is Agile?

The basis of "Agile" has it's roots in software development, going all the way back to 1957 by some accounts. At it's core, Agile is a combination of several methods for completing projects which is centered on the idea of constantly adapting requirements and solutions in incremental chunks. It promotes adaptive planning and an evolutionary delivery cycle (as opposed to a one time, all-or-nothing delivery cycle) which encourages rapid releases and promotes flexibility. The actual term Agile was coined in 2001 when a group of software developers conceived the Agile Manifesto.

For a manifesto, it is extremely short. The entire Agile Manifesto reads as so:

We are uncovering better ways of developing software by doing it and helping others do it. Through this work we have come to value:
  • Individuals and interactions over processes and tools
  • Working software over comprehensive documentation
  • Customer collaboration over contract negotiation
  • Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.

So what does that mean?

An Agile approach to development, marketing, creative, planning etc. is focused on constant communication and constant production.

By breaking a project into chunks or stages of what would be the final product, it allows the customer/stakeholder to see progress on the work being done and add feedback. This way, the customer feels involved in the process. It also allows them to point out changes early instead of at the end, thus minimizing the amount of "Why didn't they say that before" moments.

The Creative World Is Changing Fast, We Need To Change Faster

Collaboration is the key to Agile. A team working on a project would be cross-functional and self-organizing with more emphesis on creating the product and less on titles and hierarchy. Team members take on the responsibility of tasks, as well as learning the skills required to complete the tasks ahead.

With collaboration comes communication, and many Agile teams often work in close physical proximity to one another. When this is not possible, the use of tools such as online chat or web conferencing is vital to the team remaining flexible.

The Daily Scrum

The most common practice is the daily scrum, which is a face-to-face meeting among team members. It is brief, daily, and intended to uncover issues and bottlenecks.

The daily scrum is usually no more than fifteen minutes where each team member simply answers three question:

  • What have I done since yesterday?
  • What do I plan to do today?
  • What roadblocks may be getting in my way of reaching my daily goals?

How not to do a daily standup

Bottlenecks that arise after the daily scrum are handled off-line and not during the meeting itself. This makes the meeting efficient by not having a room of twelve people spend fifteen minutes on issues that only affect two members of the team at a time.

Becoming T-Shaped
Today's definition of a "creative" goes beyond the Mad Men-era partnership of art director and copywriter. Expand your core team's skill set by including developers, digital experts, and freelance specialists based on project needs.

The T-Shaped Mindset came from out of a focus more on problem-solving than individual tasking. A T-Shaped team is comprised of members who are highly skilled in at least one area and are highly collaborative. They display empathy of different perspectives and are interested in a variety of fields while also taking input from others and applying it to their discipline.

Benefits »
The Benefits of Agile
The Benefits of Agile

The Benefits Of Agile

We now know what Agile is. However, what are the advantages of using and Agile approach to the production process?


When you have a team that's meeting daily, issues are addressed daily and roadblocks are identified instead of being held in secret. When a client has weekly or bi-weekly "releases" there is much more useful communication between the team, the project manager and the client about the needs of the project and how to address them.

Having that much transparency is unusual and possibly unsettling for some organizations, but it's extremely freeing in the long run and improves on ROI substantially.

Faster ROI
The trick to achieving faster ROI is simple. Build a functional product across iterations, get it out to market early with limited features, continue adding features and then launch the fully functional version. Agile is the perfect methodology to gain the 'first mover' advantage.

Production on the project begins immediately. The framework for the final product (especially in software development/web development) is handled through wireframing and UI discovery. Since the final product will go through several releases and iterations, structural problems/issues can be identified and handled earlier.

After a few iterations, a ready for market product is available, even though it isn't the final product.

Constant Feedback

Because Agile requires frequent releases of the product, market risk is reduced. The client is able to give feedback on a regularly scheduled basis, knows what to expect, and can see progress on their concerns within a timeframe that's managable for both them and the team.

No Frills, More Quality

Daily stand-up meetings and scheduled releases strip out meaningless meetings and irrelevant paper trails. With the team constantly in contact, having hour-long "check in" meetings that wander are virtually eliminated.

A Minimum Viable brief is a product that's quickly built with only the core features, ideas, copy and concepts required to make the end product functional. An MVB can be built in a day and covers only what is needed.

« What Is Agile
Agile vs. Waterfall »
Agile vs. Waterfall
Old and Busted vs. New Hotness

The Agile vs. Waterfall Debate

Remember the days when you started a project, it went into these private groups that did stuff for five weeks then handed to your team without letting you see or know what they were doing? Then, you had to work on it and they didn't know what you were doing. No one told the client anything except for "it'll be ready on the 5th!". And then, when the first review comes around, there are six dozens things that each team hates that the other team did, the account manager is trying to see why things were so miscommunicated, and the client doesn't think anyone listened to anything they asked for?

In fact, is that still how it usually goes?

Well, that's an exaggerated (but not by much) example of the Waterfall approach.

Agile vs. Waterfall - The New Annoying Debate You'll Be Hearing About

What Is Waterfall Best Used For?

Waterfall is an approach that most of us are familiar with. It is an assembly line approach where the process of creating the end product goes through steps that go from department to department in a linear fashion.

In the creative world, the steps are usually as follows:

  • Requirements
  • Design
  • Implementation
  • Verification
  • Maintenance

The benefits of the Waterfall process are precise documentation and a clear understanding of team responsibilities.

A downside of this approach however is that changes are often highly costly.

For instance, your team builds a web banner and goes through the entire process of requirements, concepting, design, development, testing and then deliver to the client only to find out that there are fifteen changes needed. This can be extremely costly as the design may have to be redone, the technology may have to be rethought, and scope creep cannot be identified early on.

Why Is Agile Better For Rapid Changes

As it's name implies, Agile is suited for handling multiple changes in a managable fashion.

Since the project is broken up into shorter releases, and then presented to the stakeholder who gives feedback, changes can be handled well before the due date. Scope creep can be assessed early on as well.

Imagine you are on the first iteration which happens at the end of week one of a three week project, and the client decides they want massive amounts of changes based on iteration 1. Since there are more iterations to come, the team can re-estimate the time and cost of making these adjustments and the project manager can accurately inform the client on how much this adds to the project's scope.

This also encourages the production team to create in a more flexible manner, keeping in mind that things can (and likely will) change before the final iteration is completed.

The downside of Agile is that it can be a drastic change for those who are used to the Waterfall approach. It is also a change in how projects are structured and how teams work together. With everyone having equal share and equal say, as well as having to display empathy for teammate's disciplines, more I-Shaped workers are less likely to adopt the Agile process (without lots of teeth pulling).

Which Is Better?

Agile is not better all around than Waterfall. For short, smaller projects, the Waterfall approach is better suited because these types of projects do not require multiple iterations. They also are not subject to major structural changes throughout the project lifecycle. These types of projects are usually updates to banners, changes in copy, updating logos etc.

Waterfall is not well suited for larger projects with multiple moving parts that are subject to constant changes by the stakeholders. Although it has been said that Agile can work for any sized project or team, it seems to be more effective for more complex projects than straight updates or one-offs.

« Benefits
Summary »


In this lesson, we covered the core concepts of Agile as it applies to software development, creative and project planning. From it's beginning in the software development world up to today's Agile Creativity, we detailed why this emerging methodology is useful in the rapidly changing digital and creative world.

Takeaways from this lesson were:

  • The Agile Manifesto
  • By breaking a project into chunks or stages of what would be the final product, it allows the customer/stakeholder to see progress on the work being done and add feedback.
  • Collaboration is the key to Agile
  • The Daily Scrum and the three questions it asks
  • The concept of T-Shaped team members
  • The benefits of constant feedback between team members and stakeholders
  • What the differences are between Waterfall and Agile

Proceed to the next section to take a brief quiz on what you've learned.

« Agile vs. Waterfall
Lesson 1 Quiz »
Next Question »

Lesson 2

Corkboards and Tape
Corkboards and Tape

Before There Was Software ...

When Agile was first being adopted in offices and studios, it was difficult to manage all these tasks by using email or notes on paper. Although that's how every project starts, such a precise system needed a more visible and dynamic mechanism for organizing the tasks that go into each sprint.

The nature of doing a Sprint is to gather all the tasks that are needed for the project.

Now, this could result in a large pile of papers or some unweildy spreadsheet that no one would want to look at, nor could they move tasks from "To Do" to "In Progress" or to "Done".

Instead of doing that, the use of a corkboard was started to categorize different tasks, or "agile cards", for each sprint. A typical sprint corkboard is shown below:

Agile Corkboard

As you can see though, the corkboard can become messy when you have a lot of tasks. However, a number of companies have developed software that will simulate an Agile Corkboard.

In this course, we are going to use Atlassian Software, in particular JIRA, to handle our Sprint tasking board. It has a plug-in called GreenHopper that is a powerful scrum task board program.

But, before we get to the software, it may be time to refresh our memory on what a Sprint is.

What is a Sprint again?

We touched on Sprints in the last lesson but let's go into more detail.

A Sprint is a unit of time (it could be a week, two weeks, three days, one month) in which a set of tasks in a project are slated to be completed. You could have one Sprint for a project or multiple Sprints.

At the beginning of each Sprint, the team sits down in an initial Sprint Overview and figures out what tasks they need to complete and how long the Sprint should last. Stories are a general overview of a macro project tasks that describe who, what and why. For instance, a Story would be "The Development Team needs to create eight banners for the upcoming Blue Campaign". Stories are compiled in a list. Once that has been determined, the most important Stories are assigned to the current Sprint while others are placed in a Backlog.

The team then works on the tasks in the current Sprint until the Sprint ends. Again, Sprints can be a few days or a few weeks. Typically, they're one to two weeks in a creative environment.

Team members will move each task card from "To Do" to "Done" as they work on each one. Along the way, they log the time to complete each task.

At the end of the Sprint, a fully functional version of the end product should be available. This does not mean it's the FINAL product. It means we have a banner that could be used, or a website that does function or an ad that could be put into market.

The team then evaluates the Sprint, what tasks were completed, what tasks are outstanding, what needs to be done on the next Sprint etc. There is also the Product Review, where the stakeholder (whether internally or the external client) is presented with the product that resulted from the Sprint and can make comments, report issues, make changes etc. This is also the time when the Project Lead or Account Exec can add new tasks to the next Sprint.

The next Sprint starts the same way as the last one did. This cycle continues until the project is completed, with each Sprint building on and improving the product.

Next, we will dive into JIRA and see how to set up a project.

Atlassian Software JIRA »
The Atlassian Suite of Products

Atlassian Software JIRA and Confluence

One of the more popular software suites for collaboration and Agile projects is the Atlassian suite of tools, specifically JIRA and Confluence.

JIRA is an online tasking tool that allows teams to create projects, assign tasks, build estimates, and create Agile Sprints using it's GreenHopper plugin.

Confluence is a collaboration tool that can act as a repository for project briefs, documentation, meeting notes, and an intranet in general.

How To Use JIRA for Sprints

The following section details how to start using JIRA. First thing, go to CDP's JIRA Site or download the free trial from Atlassian's website at if you do not currently have JIRA in the workplace or want to test it for yourself using your own server/network.

Your username and password should have been sent in an email before this lesson. If not, contact the webmaster to obtain one.

You will then be introduced to the landing page of JIRA.

Agile Tab

For the purposes of this training exercise, we are only going to be concerned with the Agile tab. Click on the down arrow next to "Agile" in the main navigation and you'll see a list of options. You want the "Training Class" option, so click on it.

Click the Agile tab

This will take you to the Scrum board for this project. We discussed how the team gathers all their tasks and prioritizes them in the initial meeting. This is where those tasks, stories, bugs etc. are all put into a list and prioritized. Any current sprints are on top and your Backlog is at the bottom. Once the team has agreed to and prioritized this list, you can create a Sprint.

Click on "Create Sprint" on the right side of the Backlog section. You can name this Sprint whatever you want. To add tasks to this Sprint, you can drag and drop them from the backlog into the box or slide the box over the list of tasks. As you slide the Sprint box, it will injest the tasks you hover over and update the estimate in the lower right hand corner.

Add tasks to a Sprint

Once the team has filled up the Sprint with all the tasks they think they can complete within the Sprint timeframe, click "Start Sprint". JIRA will then create the Agile Board for you and place all items on the board. This is the screen the team will use most of the time when working on the project. It can be as simple as moving items from "to do" to "in progress" to "done" as they make progress on their task list or more experienced users can get into the features of JIRA.

JIRA Scrum Board

Some of the features would be assigning Watchers to a task (so co-workers who should know about the status of a particular task can be notified via email when changes are made or comments are left), updating your time and so on. A more comprehensive lesson on how to use JIRA's features is beyond the scope of this Agile course, but during training they will be explained in more detail. Below are also a series of links on how to use the task pages in JIRA.

Project managers, Team leads and Scrum Masters can check on the progress of the team using the Report section. You'll see the team's progress in a series of charts that can be used for a number of purposes. The most commonly used are the Sprint Report and the Burndown Chart. These charts have a Guideline, which shows the trajectory we want our project to follow towards completion. The red line shows how close (or far) your team is to staying on track with the project timeline.

Burndown Chart

Many more updates are listed underneath the chart with details on what happened day-by-day. These charts can also identify scope change and mark it in the project tmieline. These tools provide an excellent way to monitor a team's progress and identify if there are adjustments that need to be made.

« Overview
Your First Sprint »
Your First Sprint
Ready, Set, Sprint!


You can create your own Sprint Board for this project easily. In the main menu, click on the down-arrow next to "Agile" and select "Manage Boards".

You will see a list of current boards that are being used. To create a new board, click on the Tools down arrow and select "Create Board".

Choose SCRUM from the two options (Kaban is another tutorial entirely), and then enter a Board Name and select a project or projects you want to associate with this board.

Now that you've created your board, you'll see the Backlog displayed on the left. Here are all the tasks, stories, bugs etc. that are in the backlog but unassigned to a sprint. So, the first thing we want to do is create a new Sprint.

  • Click on Create Sprint
  • A new Sprint board will appear. You can change the name of the Sprint to whatever you want.
  • Click
  • Drag and drop cards from the Backlog into the Sprint box that you want.
  • Once you have added all the cards you want for the next Sprint, click "Start Sprint".
  • A screen will pop up which will allow you to choose a Sprint Name, set a Start and End date for your Sprint.
  • Click "Start".

That's it. You've now created your Sprint Board. From here, team members can update different tasks, move them from "To Do" to "In Progress" to "Done" as they complete each tasks during the Sprint.

Advantages of Sprint Boards

The biggest advantage of a Sprint Board is that it organizes the tasks of a project. By creating estimates per tasks, and then grouping tasks to be complete in a time period, you can make more accurate estimates and track scope creep early on.

It also provides transparency. Since all team members can view the Sprint Board, all team members will know what's going on with the project in real time.

There are many features in JIRA that help with making Sprint Boards, reports, time estimates etc. which are dealt with in more detail in the video below.

« The Atlassian Software Suite
Confluence Overview »
What Is Confluence?

Confluence Overview

So outside of JIRA there's a software that goes with it called Confluence. So what is Confluence?

Confluence connects teams with the content and co-workers they need to get work done, faster.

Give your team one place to collaborate on content and projects without the bottlenecks that hold you back.

Put email and shared network drives to rest. Meeting minutes, requirements, project plans, documentation – create and share it all in Confluence.
Humorous Video On Confluence in the workplace

In essence, Confluence is another website that allows team members to collaborate and document important information about clients, projects, meetings, etc. It comes with a lot of macros, which are plug ins that allow you to import Google calendars, projects from other software programs, embed pdfs, export meeting notes and times, and for this tutorial attach JIRA project tasks to a Confluence page.

Confluence In Our Workspace

For CDP, you can login to Confluence by going to Once there, you can use your JIRA login to get into the website. Your dashboard has a variety of recent updates as well as a quick tutorial/video on how to use Conluence.

For us, this represents a more robust intranet and documentation space. By documenting project issues, client specifics etc. in this format, it provides a place where other members of the team can easily search and retrieve information that is historical to CDP.

This provides an advantage because instead of wondering what the history of a project is, it will be chronicled online. If you need to find out what the specs are for banners, or who our list of freelancers are, or what problems existed on a prior project with a client, it can be documented here for other people to view without having to dig through piles of papers. It also helps to not be short of information because the people who worked on a project are no longer at the company.

JIRA & Confluence

You can embed JIRA issues with Confluence.

So, say you have a documentation write up of a project for EverBank®, you can embed the tasks or project Sprint from JIRA into a page in Confluence.

You can also link JIRA tasks to historical data that's in Confluence.

Confluence also allows for simple tasking for projects. If you have a meeting and out of the meeting there are five tasks to be done, that don't need to be put into a full-on JIRA Project, you can assign tasks in Confluence that are as simple as "call the client for specs". Confluence's much simpler tasking abilities make it ideal for non-production issues that don't require full on Sprints.


For ongoing projects, a great advantage of Confluence is that the mobile version is simple to use and can allow tasks to be one on the fly, outside of the office. As opposed to trying to track project status via sixty emails, fifty of them may be unrelated, software like Confluence keeps project information located in one place and is easy to sort.

Other Atlassian Software and Comparable Companies

There are many other software products, free plug ins and more provided by Atlassian. Not to mention, there are plenty of other companies making similar software. A little Googling will show the vast world of collaborative tools that have emerged over the last few years and have been adopted by top level firms and companies like Skype, Cisco, UPS, ABC, Nike and many more.

« Your First Sprint
Summary »


In this lesson, we reviewed Atlassian Software – in particular JIRA and Confluence – that aid in the Agile collaborative process. JIRA is the tasking system that comes with an enormous amount of tools that help teams move more efficiently through the lifecycle of a project.

Confluence is a compliment to JIRA, more of an intranet and repository of information where team members can collaborate and share information.

We also learned about Sprints, how to set up a Sprint board, how to use JIRA to create a project and start a Sprint, and the process of running an Agile project within a team.

Takeaways from this lesson were:

  • How to set up a Sprint Board
  • Gathering tasks in a Backlog
  • Using JIRA to create projects
  • Setting up a Sprint Board
  • Confluence is a robust intranet/documentation/collaboration tool
  • Integrating Atlassian Software to make team-based Agile projects more dynamic
  • Touched on the wide world of related and alternative Agile software products

Proceed to the next section to take a brief quiz on what you've learned.

« Confluence Overview
Lesson 2 Quiz »
Next Question »

Lesson 3

The Client Brief
Sammy Smart - A Happy Client

Meet Sammy Smart

Sammy Smart is a local business owner who started shining shoes as a kid outside of Oriole Park at Camden Yards. Years later, his love of making meatloaf sandwiches gave him an idea. He started selling sandwiches to his customers while he shined their shoes.

Ten years later, Sammy's Sandwiches and Shoe Shine has fifteen stores across the Mid-Atlantic region bringing in $15 million a year in revenue. Sammy wants to expand his business now and has a goal of opening ten more stores in Maryland and three more in Virginia.

Who You Gonna Call? CDP!

Ellen has done the pitch, Jamie has gotten the contacts, the creative team has come up with some concepts and Dennis has crunched the numbers. Now it's time to figure out how we're going to deliver materials to Sammy and plan out a schedule with the team that's going to work on Sammy's Sandwiches and Shoe Shine.

Shoe shine

Now, Sammy is a very demanding client. He wants to see everything, comment on everything, and know what's being done and how much money is being spent. The four things Sammy wants most from CDP are the following:

  • A brand new website
  • A newspaper ad to run for a month in three different sizes
  • An online banner campaign
  • One giant digital billboard off of i-83

Like most clients, the timeline for this is very short. Sammy wants the website and banner ads up in a month and needs the billboard and newspaper ad in two months to coincide with the next two store openings in Maryland.

There are a lot of moving parts here, and several disciplines and schedules to be considered. We've gathered the team and for this exercise, each member of the class will represent one particular group. These groups would be: creative, accounting, development, digital strategy and management.

What's the First Step?

In Agile, the first step is to have the Sprint Planning Meeting. In the next section, we will into detail about how to do that.

Sprint Planning Meeting »
Sprint Planning Meeting
Sprint Planning Meeting

Sprint Planning Meeting

So, in the previous lesson we got into how to use JIRA and how to plan out a SCRUM. Now, we have to put this into practical use.

The Sprint Planning Meeting is a term used sometimes to describe the first meeting of the team before the first Sprint. It is a meeting that should last long enough to establish a few things:

  • What are our deadlines
  • How long should sprints be
  • What tasks are assigned to which team
  • What do we want to have accomplished at the end of each sprint
  • Create Agile Cards with Stories to be placed in the Backlog
  • Pick which cards we want to tackle in our first Sprint

Scrum team roles

It is at this point where there Scrum Master would typically for CDP be the account manager. The Scrum Master is in charge of making sure the team is on point, removing obstacles that keep team members from completing their Sprint tasks, and making sure that the team is adhering to the Agile framwork.

The Product Owner in CDP would usually be management. This person is a stakeholder who usually represents the client (think Jamie, Ellen, etc.). They will take part in the initial parts of the first Sprint Planning Meeting but will not be involved past making sure the client's needs are being addressed. They do not participate in daily scrums or Sprint reviews unless there is a demonstration to be presented to either them or the client.

The Team is the rest of us, from digital artists to developers to print designers to media tracking.

Developing the Backlog

In this first meeting, the team creates a series of Stories - which again are general requirements for the features wanted to the project. The team sits together and tries to come up with everything they can think of that will be needed to complete the project. After we have created the Stories for the entire project, we pick which ones we want to tackle in our first Sprint. These Stories in the Backlog are then broken up into tasks.

Tasks should be no more than five hours of work – this forces the team to think more critically about the actual work being done and allows to give more accurate estimates. These tasks populate the backlog. When planning the first Sprint, we go through the backlog and look at the tasks that the team thinks can be accomplished by the end of the first Sprint. Once the scope of the Sprint is defined, the Product Owner is informed and makes sure that what will be produced by the end of the Sprint meets the client's requirements.

It is important that the Product Owner and the Scrum Master communicate with the client to set expectations for releases. By setting expectations and letting the client know that they will be receiving periodic updates, most of which will be functional materials, the team can usually avoid a client being disappointed with the project progress.

Team members then choose which tasks they will tackle. Instead of having tasks assigned to each team member, the team members choose which order they will tackle in what order. This done because of the belief that those working on the tasks know best how they can tackle them, and what order they should be in since they are usually the subject matter expert for that task.

Adding Items In JIRA

JIRA can be used to build the backlog and start the first Sprint, as we did in the last lesson. The time estimate features in JIRA can quickly and easily allow everyone on the team to see if their estimates will meet the budgeted time, if we're out of scope, or if we're light on tasks. JIRA can also print out cards to be used on a physical Sprint Board. It's sometimes good to have physical Sprint Boards so Product Owners can look at the progress of the project by simply going by the meeting room or for those who don't like to use the internet as much as having a physical board to look at.

In the next section, we'll briefly go over the daily SCRUM.

« Sammy Smarts
Daily SCRUM »
First Scrum
The First SCRUM

What Do We Do Now?

At this point, we've gathered together stories, made up tasks for our first Sprint, set up our backlog, gotten a general view of estimates and the team should be ready to go.

So now what?

Your First SCRUM

Depending on how your team has estimated its time, the first day of the first Sprint begins with the Daily SCRUM. Again, the Daily SCRUM is a brief meeting lasting no more than fifteen minutes. The team reviews the Sprint board (updates it if needed), and each team member answers three questions:

  • What did I do yesterday?
  • What do I plan to do today?
  • What roadblocks stand in my way?

Any items that go beyond answering these three questions should be taken offline. The Scrum Master is in charge of keeping track of where the team is and who on the team may need help. The Team must be open and honest with where they are in the project. After a few daily SCRUM's, it will be clearly obvious who needs help based on where they are in completing the tasks assigned to them in the Sprint.

It is also key to know that as always, the client will have changes and additions. These should not be added to the current Sprint. These items should be tabled until the next Sprint and labeled as critical in the product backlog. When the next Sprint begins, new requirements, bugs, issues etc. can be addressed in the next round. This is where it becomes critical for the Product Owner and Scrum Master to communicate expectations to the client.

We're ready to go. The rest of this class should be devoted to the team having a Sprint Planning Meeting and continue until the first Sprint has been set up.

« Sprint Planning Meeting
Summary »


In this lesson, you learned about Sammy's Sandwiches and Shoe Shine, found out what Sammy wants for his new campaign, and reviewed how to start an Agile project to handle Sammy's requests.

Takeaways from this lesson were:

  • Who is Sammy Smarts
  • How to conduct a Sprint Planning Meeting
  • Using JIRA to create projects
  • Making Stories
  • Creating tasks
  • Staring your first Sprint

Proceed to the next section to take a brief quiz on what you've learned.

« The First SCRUM
Lesson 3 Quiz »
Next Question »

Lesson 4

Sprint Review
Sammy has changes!

The Sprint Review Meeting

So, the team has gone through the first Sprint. Some parts went smoothly an others didn't.

The design team did not complete all their tasks assigned for the Sprint and claim to need a total overhaul of their concepting phase. The development team handled it's tasks but thought of some issues that might come from the type of server the client wants to use. The account team kept in communication with the client and explained that concepts might not be totally complete but they do have something to show.

The Sprint Review Meeting

This meeting is either done with the client or solely with the team. It is where the produced materials at the end of a Sprint are displayed. Note: incomplete work is not to be displayed. The team should present what it has accomplished with minimal interruption. After they are done, the stakeholder (whether it's the client or the Product Owner) can give critiques. These are captured by the Scrum Master.

So how did this go with Sammy?

Sammy was shown the initial concepts the design team had completed with the disclaimer that it is still a work in progress. Sammy loves the idea of the Shoe Sandwich and wants the design team to come up with a few more iterations. The website wireframes meet the client's expectations but they are less concerned with that because it's just a wireframe. However, Sammy sounded disappointed that none of the billboard concepts were completed.

Overall, Sammy is pleased with what has been done in this first iteration. A few disappointments on the billboard aside, Sammy is very happy. He even gave a few suggestions during the sprint that the Scrum Master and Product Owner kept from the team during the Sprint.

So Now What?

Friday comes, the meeting with Sammy is over, happy hour has passed, and now the weekend is here. Monday morning though, the team has to address Sammy's disappointments, the technical issues development sees coming down the line, and how to address the billboard concepts.

The first thing the Scrum Master has to do is set an agenda for Monday's Sprint Retrospective Meeting.

Sprint Retrospective Meeting »
Sprint Retrospective Meeting
Assess and Reload

The Sprint Retrospective Meeting

What do you do in a Sprint Retrospective Meeting? This is where the team takes in what was gained at the end of the Sprint Review Meeting. We should be answering two questions: what went well during the Sprint and what could be improved?

During this time, the team assess itself as to how well it did in completing the tasks assigned during the last Sprint. For instance, the design team did not complete the concepts for the billboard and are requiring more time to concept. They would then start thinking about how they can get this accomplished and stay on target for finishing the banner ads.

After all teams have given their assessment, the Scrum Master introduces notes from the stakeholder. These could be additions the client wanted, changes to technical specifications, updates to copy, etc. It is important that the Scrum Master does not inject these items during the previous Sprint unless it is absolutely necessary. The team should be building collateral with the idea in mind that changes will happen and the Scrum Master should be managing incoming changes so the team does not become overwhelmed.

These meetings are very important and should not be skipped over. It is where the team gets an idea of where they are and if the project is going over budget and time, or, if the project is right on schedule or ahead of schedule. This allows the team to understand what the upcoming Sprint will need to look like. Without this, you could be assigning tasks without addressing the reality of where the project is.

The Rules

Here are a few rules about the Sprint Retrospective meeting:

  • Ensure that everyone can speak freely
  • It is not the place for advocating personal agendas
  • Do not play the blame game (ie. do not harp on design not having the billboards done)
  • Make suggestions for improvements and implement the best ones in the next Sprint

As you will come to understand, each team for each project is different, and new methods and tactics can be adopted with each Sprint. There is no holy grail for Scrum Development. Like the project itself, the process is ever improving and evolving over iterations. The Retrospectve Meeting is where those improvements can be brought up and assigned.


After this meeting is over, the Backlog is updated with items that the clients wants to see in the next Sprint Review Meeting, backlog items that were not completed in the last Sprint, new items from the Backlog and any other tasks that should be added for completing the next Sprint. It is also the time where the Backlog is reviewed to see if new tasks need to be added. For instance, development may need a check on the software the client has asked for, which may require three more tasks. This is the time to add them to the Backlog and assign them to the next Sprint if possible.

« The Spring Review Meeting
Setting Up the Next Sprint »
Next Steps
Setting Up The Next Sprint

Notes for Setting Up the Next Sprint

In this section, you should take your time to set up the next Sprint. Keep in mind what the project needs to get back on track, ways to help the design team meet it's goals for the billboard, what to do about technical challenges and how to keep the client's expectations in check. Sammy is happy but can become upset if the billboards have zero progress by the next Sprint Review Meeting, so perhaps you should address those first.

Sammy also gave you a laundry list of suggestions for copy and design changes that you should address in the backlog.

Overall, take this time to think through where you are now at the beginning of the Sprint and what the client would want to have by the end of it.

In the next section, we're going to use JIRA to move items around in a backlog and setting up a new Sprint.

« The Spring Retrospective Meeting
The Next Sprint in JIRA »
Working in JIRA
Backlog stuff in JIRA

Using JIRA for Your Sprint Planning

We've used JIRA in a previous lesson to set up a Sprint. Now we'll look at how to use it to create a new Sprint.

Backlog Backlog Backlog

The Backlog is your friend. It keeps everything you need to do so don't treat it lightly. This is where you move tasks and stories that were not completed from one Sprint to another, perhaps move some into the Backlog and pull others out. Think of it as the bucket where you store all the tasks. You want that bucket to become emptier with each passing Sprint.

Sometimes, it can get filled up again. That's when you know you're project is creeping way out of scope. Generally though, you can measure how well you're doing by the reduced amount of items in your Backlog.

Burndown Charts

A great feature of JIRA is the burndown chart. Take time to study them and how they work. Their main purpose is to show you how well the team is doing on the project.

A burn down chart is a graphical representation of work left to do versus time. The outstanding work (or backlog) is often on the vertical axis, with time along the horizontal. That is, it is a run chart of outstanding work. It is useful for predicting when all of the work will be completed. It is often used in agile software development methodologies such as Scrum. However, burn down charts can be applied to any project containing measurable progress over time.
Sprint Burndown Chart

The burn down chart can be a lifesaver. When the team is putting in accurate documentation of their time and progress the burn down chart is useful for seeing where the team is.

JIRA Administration Demo

Administrators are key to setting up projects. Here's a video about how to set up JIRA project in admin.

Take some time now to try and schedule your next Sprint in JIRA. Try doing this a few times to get the feel of it.

« Setting Up the Next Sprint
Summary »


In this lesson, we discussed how to conduct a Sprint Review Meeting, a Sprint Retrospective Meeting, and how to go about starting your next Sprint.

Takeaways from this lesson were:

  • A Sprint Review Meeting is where you demonstrate completed work to the stakeholder
  • How to conduct a Sprint Retrospective Meeting
  • What to do with tasks that are not completed during a Sprint
  • How to start your next Sprint
  • Using JIRA to move items around to and from your Backlog into the next Sprint

Proceed to the next section to take a brief quiz on what you've learned.

« Using JIRA
Lesson 4 Quiz »
Next Question »