Delve into Agile methodologies, compare them with Waterfall, explore planning techniques, and discover tools like SCRUM and Kanban. Gain insights into solving common problems with Agile.

This course is designed to help learners build an understanding of Agile’s process model and its different approaches and techniques.

To understand the advantages of implementing Agile techniques, the course begins with a comparison of Agile methods and the traditional Waterfall model. Then, you’ll get to know about different planning approaches to help users effectively adjust deadlines. Next, there’s a discussion on backlogs and different visual techniques, such as burn-down charts and burn-up charts, that help increase the efficiency of projects.

You will also learn Agile methodologies including SCRUM, eXtreme Programming, DSDM, Smart and Kanban, as well as the differences and similarities between these approaches. Finally, you’ll look at some common problems and learn ways to solve them using Agile methodologies.

Learn Agile Methodologies from Scratch

## Introduction

Estimation poker, also often referred to as planning poker, is a
good technique for a team to estimate points. In order to do
this, a workshop is scheduled with the team. The raw material
is the work items to be estimated. Each individual work item
is now estimated using the following interesting procedure:

### Explain

   One of the participants will take the lead and
explain each work item, what needs to be realized, and,
if possible, what techniques, platforms, and services are
to be used.

### Estimates


  Each participant has a set of cards that depict the values of the applied scale. This can be a set of playing cards, but predefined sets of cards are often available for known scales. After a work item is explained, all participants will lay a card from their own set down on the table that specifies which value they attach to this work item. This value represents the total complexity or amount of work that must be done to complete that work item, not just the amount of work for a certain role.

### Evaluate

   Once the cards are on the table, they’re evaluated. If the range of values is close to each other, the evaluation is simple. For example, if only fours and fives are showing, there’s nearly consensus. The team now simply chooses one of these values.

### Explain

   When the values are further apart, something more needs to be done. The two participants furthest apart now briefly explain why they chose their values. Keep in mind that neither of the selected values is wrong, even though their opinions differ. Maybe the customer opted for a two, and a developer for an eight. Perhaps the customer underestimated the complexity, or the developer misinterpreted the work item.


### Re-estimate

   If the values differ, the participants take their cards back from the table and again put a card on the table which represents the value for complexity based on the new insights. It’s likely that the values are now closer together. An estimate is then achieved.

If the values still differ strongly, the evaluating, explaining, and re-estimating can be repeated. If, after several rounds, no consensus is reached, this is usually because the work item requires further investigation. In Agile projects, this is indicated by choosing the maximum value from the scale.



# Introduction

Estimation poker, also often referred to as planning poker, is a
good technique for a team to estimate points. In order to do
this, a workshop is scheduled with the team. The raw material
is the work items to be estimated. Each individual work item
is now estimated using the following interesting procedure:

## Explain

   One of the participants will take the lead and
explain each work item, what needs to be realized, and,
if possible, what techniques, platforms, and services are
to be used.

## Estimates


  Each participant has a set of cards that depict the values of the applied scale. This can be a set of playing cards, but predefined sets of cards are often available for known scales. After a work item is explained, all participants will lay a card from their own set down on the table that specifies which value they attach to this work item. This value represents the total complexity or amount of work that must be done to complete that work item, not just the amount of work for a certain role.

## Evaluate

   Once the cards are on the table, they’re evaluated. If the range of values is close to each other, the evaluation is simple. For example, if only fours and fives are showing, there’s nearly consensus. The team now simply chooses one of these values.

## Explain

   When the values are further apart, something more needs to be done. The two participants furthest apart now briefly explain why they chose their values. Keep in mind that neither of the selected values is wrong, even though their opinions differ. Maybe the customer opted for a two, and a developer for an eight. Perhaps the customer underestimated the complexity, or the developer misinterpreted the work item.


## Re-estimate

   If the values differ, the participants take their cards back from the table and again put a card on the table which represents the value for complexity based on the new insights. It’s likely that the values are now closer together. An estimate is then achieved.

If the values still differ strongly, the evaluating, explaining, and re-estimating can be repeated. If, after several rounds, no consensus is reached, this is usually because the work item requires further investigation. In Agile projects, this is indicated by choosing the maximum value from the scale.



Get an idea about giving the best estimates of an Agile project.

Getting Started

Why does the Waterfall Process model not work?

What is Agile?

Short Iterations in Agile

Collaboration in Teams

Collaborating Roles

Agile Requirements

Estimating

Planning

Implementing Agile

Issues in Using Agile

Choosing the Most Appropriate Process Model

Conclusion

Estimation Poker

Introduction

Explain

Estimates