AGILE

A typical project may take six sprints, or twelve weeks, to complete. This may seem short, but
remember, agile approaches are particularly useful when there is an urgent need to produce a product
that can be delivered in an incremental approach.

 You’ll schedule a sprint planning  meeting to plan the goals of the current sprint
 You’ll have quick daily scrum  meetings to touch base with your team and find out what they did
yesterday, what they’ll do today, and if there is anything standing in their way.
 You’ll have a retrospective  meeting to evaluate what went well during the sprint, and where the
team can improve.

Create Your Sprint Schedule

Let’s say your team agrees on two-week sprints, running from Monday, to the Friday of the following
week.

Schedule a two-hour sprint planning  meeting for Monday morning. Everyone on the team must attend.

Schedule a 15-minute daily scrum  meeting for every day. Mornings are a good time if the team agrees.

Schedule a retrospective  meeting for the following Friday afternoon.

The Goal

You and your team will create a product backlog. A product backlog  is a list of all the work that
needs to be done. As the project progresses, it gets refined on an ongoing basis.

The backlog items will guide the creation of the project’s deliverables. It can be displayed on a wall using
sticky notes or managed digitally with software.

Create Your Project Backlog

In agile, work is broken down into chunks that are small enough to create, test, and deliver within
a sprint .

Work is broken down into these main categories:

Feature
The main functionality of the final product.

Epic
A way to break features into smaller chunks of work. If an epic is too large to be delivered in one
iteration, it needs to be further broken down.

User story
A user-centric way to capture requirements and break down epics. The user story is small enough to be
designed, coded, and tested in one iteration.
Task
Individual units of work to be performed.

Create User Stories

The Goal

A user story  is a tool used in agile software development to capture a description of a software feature
from an end-user perspective.
A user story describes the type of user, what they want, and why.

Basics Of A User Story

What
It describes a feature (or component of a feature) and is short and simple.

Who
It’s from the perspective of the person who will use the feature.

Why
It incorporates the “value” of the feature so the team knows what is driving this request.

When
User stories are prioritized in terms of when they’ll be completed.

Create User Stories

You and your team will create and capture user stories in a specific format.

“As a… I want… so that…”.

As a…
This describes who the user is. You might design a feature differently if you know that the end user is
tech-savvy versus one who is not.

I want…
This expresses what the user is trying to accomplish. Understanding the feature request is critical to
delivering the right thing.

So that…
This is perhaps the most critical part of the user story format. Why the user wants to accomplish
something can be very enlightening to the goal just described.
Here’s what a good user story looks like:
As a gardener, I want to control greenhouse conditions from my phone, so that my plants will stay happy
while I’m away.

The Sprint Planning Meeting

The Goal

You’re about to populate your Scrum board  with sticky notes that display all the work that will be
accomplished during this sprint .

The idea is to have all the work up on the wall, visible, organized, and accessible by the team, so they all
understand what they’ll be working on this sprint, and who is accountable for each piece of work.
You’ll be organized, prioritized, and ready to hit the ground running when the sprint begins.

Create Tasks and Assign Points

The Sprint Review

In the sprint review  meeting, the team demos the product to show the results of the  sprint .

The goal of the sprint review meeting is to receive feedback from the  sponsor  on the user stories  that
are being delivered, and to find out if they meet the desired goals and value.
It’s also a time for you to revaluate the vision if you realize it’s off-track or lacking in some way.

Prepare for it

This is where the team will showcase its abilities. You want to build your  customers ’ confidence in your
team, even if your customer is your sponsor. It’s good practice to spend the morning before the sprint
review preparing.

 Assign each team member an area to present. Team members should prepare a brief demonstration and be
ready to answer questions and provide a rationale for any decisions made.
 The team should block off an hour to do a complete sprint review run-through before the meeting, to make
sure everyone knows exactly what they should be doing, and can successfully demo the completed work.
 The team should provide as much relevant data as necessary to create a compelling discussion.
 The Retrospective

The Goal

The goal of the retrospective  is continuous improvement. Consider all aspects of how the team
functioned during the sprint  and identify things that went well. It’s also a time to make any changes
necessary to improve the functionality of the team, the quality of the product being produced, and the
team’s velocity.

Open And Honest

The retrospective  is a private meeting where team members can be open about their struggles and pain
points.

Although the sponsor  is not invited to this meeting, he or she will be interested in how the team is
functioning and whether he needs to provide support in any way.
Be prepared to share action items from the retrospective with the sponsor that they might be able to help
execute.

Being Agile
Measuring the Madness

Keep an eye out for these patterns, and change them, if they arise.

 Work is completed before the sprint is complete because the team isn’t committing to enough
work.
 The team doesn’t complete their forecasted work because they’re committing to too much.
 The  burndown   line makes steep drops because the work hasn’t been broken down into small
enough chunks.
 Scope  is added or changed mid-sprint. Beware of scope creep .

Meet The Burndown Chart

This handy guy is for someone who wants to track progress with a simple line chart.

A sprint burndown  chart tracks the completion of work throughout the sprint. The x-axis represents time,
and the y-axis refers to the amount of work left to complete, measured in  story points .

Release to Operations

Wrapping It Up

Make sure to refer to your initial goals and objectives before closing the  project .

Take time to review all your lessons learned with your team. In addition to celebrating your
achievements, consider celebrating your failures.
They are key learning opportunities for the team. Even though the project will soon be closed, your
product will continue to delight your customers.
Keep an eye out for these patterns, and change them, if they arise.
What You Will Produce

You still need to make certain that all documents and deliverables are up to date and archived, and that
all issues are resolved.
Next, put all your documentation out on a central library where people outside the team can reference it.
Your team will likely stay together and take on another product. Make sure to celebrate this big win.