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

Using small units of work might not be an ideal method in other approaches.

Let’s look at a few drawbacks of using small units of work:

+ With small units of work, come longer iterations. Any feedback given will be very late once the work item is realized.
+ It results in irregular iterations. 
+ Only one work item is realized per iteration, which removes flexibility from the project.
+ It results in low productivity. This is because, in case of any unplanned activity (new or changing requirement), it will take longer to counter the problems.

However, the classic use cases the project manager uses for their project planning are too large. In Agile projects, it’s essential to choose a small unit of work so that several can be realized during a single iteration. In the following sections, we’ll look at why we need to use small units of work for an Agile project.



During an audit of an insurer, a project manager was proudly talking about the use of iterations. Interested, we asked how long they were. He said that the current iteration takes four months, and the next three. Surprised, we looked at him and asked about the next iteration. He replied that it would last five months, and the next one three again. Although he appeared to be very impressed by his own schedule, we didn’t understand what it was based on. He explained that they were working on the basis of use cases. During each iteration, we’re realizing one use case.

+ **Prioritizing:**
Being able to reorganize and prioritize the work items in every iteration is crucial. Work items with a low granularity provide the flexibility to do so. The granularity of classical use cases doesn’t.

+ **Dividing:** Working on several smaller work items simultaneously provides better work distribution. The domain expert prepares two work items, the developers are working on two other work items, and the tester tests another one.
+ **Delay:** Sometimes, the productivity of a team is unexpectedly lower. For example, a server can be down for two days or the team can be working on multiple work items at the same time. A delay means that perhaps not all planned work items can be completed, but some can be.
+ **Switching:** Sometimes a team gets stuck during the development of a work item. For example,the requirements may not be clear enough. Or, it must wait until another team or organization delivers certain functionality. If an iteration consists of multiple work items, the team can now switch to another work item. So, a single work item is rarely blocking the team from doing work.


## Which unit of work?

The key question is, what’s the correct unit of work? For now, we’ll always use the term work item, which is an abstraction. Agile approaches each have their own unit of work. Extreme Programming and Scrum are user stories. Smart defines smart use cases. Feature-driven development speaks about features. We use the following criteria to choose:
+ **Recognizable:** The work items must be recognizable for everyone on the team, from stakeholders to testers. The unit of work is also the unit of conversation.
+ **Granularity:** The granularity determines the flexibility. Always choose a unit of work of which several can be fully realized during a single iteration, from analysis to acceptance. This also enables a fast and practical measurement of progress.
+ **Traceable:** We think it’s important for work items to be directly traceable from the wishes and requirements of the customer. This increases the involvement of the customer and facilitates acceptance.
+ **Early:** Because the realization of work items starts almost immediately, work items need to be available early in the projects. This makes traditionally-used units like entities or tables unsuitable.
+ **Estimable:** The size or complexity of work items should be easy, early, and repeatedly estimable to enable reliable estimates and planning, and for the determination of the proper amount of work per iteration.
+ **Realizable:** Select a unit of work that can be realized in one go. Realizing work item after work item provides rhythm and translates into good modularity of the code. This increases software maintainability.
+ **Testable:** The early and individual testability of work items is important. This increases software quality enormously.
+ **Acceptable:** The same applies to the acceptability of the work items. The user, product owner, or domain expert should be able to accept individual work items.


+ **Dividing:** Working on several smaller work items simultaneously provides better work distribution. The domain expert prepares two work items, the developers are working on two other work items, and the tester tests another one.
+ **Delay:** Sometimes, the productivity of a team is unexpectedly lower. For example, a server can be down for two days or the team can be working on multiple work items at the same time. A delay means that perhaps not all planned work items can be completed, but some can be.
+ **Switching:** Sometimes a team gets stuck during the development of a work item. For example,the requirements may not be clear enough. Or, it must wait until another team or organization delivers certain functionality. If an iteration consists of multiple work items, the team can now switch to another work item. So, a single work item is rarely blocking the team from doing work.


# Which unit of work?

The key question is, what’s the correct unit of work? For now, we’ll always use the term work item, which is an abstraction. Agile approaches each have their own unit of work. Extreme Programming and Scrum are user stories. Smart defines smart use cases. Feature-driven development speaks about features. We use the following criteria to choose:
+ **Recognizable:** The work items must be recognizable for everyone on the team, from stakeholders to testers. The unit of work is also the unit of conversation.
+ **Granularity:** The granularity determines the flexibility. Always choose a unit of work of which several can be fully realized during a single iteration, from analysis to acceptance. This also enables a fast and practical measurement of progress.
+ **Traceable:** We think it’s important for work items to be directly traceable from the wishes and requirements of the customer. This increases the involvement of the customer and facilitates acceptance.
+ **Early:** Because the realization of work items starts almost immediately, work items need to be available early in the projects. This makes traditionally-used units like entities or tables unsuitable.
+ **Estimable:** The size or complexity of work items should be easy, early, and repeatedly estimable to enable reliable estimates and planning, and for the determination of the proper amount of work per iteration.
+ **Realizable:** Select a unit of work that can be realized in one go. Realizing work item after work item provides rhythm and translates into good modularity of the code. This increases software maintainability.
+ **Testable:** The early and individual testability of work items is important. This increases software quality enormously.
+ **Acceptable:** The same applies to the acceptability of the work items. The user, product owner, or domain expert should be able to accept individual work items.


Learn about the different units of work in Agile.

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

The Unit of Work

The problems with small units of work