This is the ‘Value-Driven Delivery - Kanban Board and Earned Value Management’ tutorial, of the PMI-ACP Certification course offered by Simplilearn. We will learn about other aspects of Minimum Marketable Feature(MMF), Earned Value Management or EVM, Kanban Board and Agile Contracts.

Objectives

After completing this lesson, you will be able to:

Explain MMF and the steps involved in project planning using MMF

Explain Kanban card and JIT

Describe incremental delivery and feedback techniques

Describe Agile compliance and the focus areas

Discuss how to apply EVM to Agile projects

Explain various EVM metrics and terminologies

Explain the various Agile contracting methods

Minimum Marketable Feature

A Minimum Marketable Feature or MMF is the smallest set of functionality that provides maximum value to the project, in line with Pareto’s law which states that 80% of benefits come from 20% of the requirement. By focusing on MMF, the maximum value can be delivered early in the project cycle, and it helps improve the predictability and flexibility of a project.

The steps involved in project planning using MMF are as follows:

Determine the MMF based on the inputs from business stakeholders.

Introduce a sufficient amount of slack to ensure that the team delivers the MMF even if there are schedule slippages.

Manage change, that is, ensure changes suggested by the business stakeholders are incorporated into the solution.

Increase the MMF that is, once the team gains a good understanding of the solution architecture, their velocity also increases. In such cases, increase the number of features that can be accommodated in the MMF.

Accommodate the New Feature that is, add new features proposed by the business into the MMF and track the delivery. Note that incrementally delivering the features, which are part of MMF, provide maximum value to the stakeholders.

The first step is to determine the MMF. This is to define the minimum set of features with which a team is prepared to launch the product. In the given image, the feature numbers from one to four constitute the MMF. In the normal planning process, the schedule or budget cut-offs would be determined based on these four features.

The second step is to introduce some “slack,” “contingency,” or “buffer,” which depends on several factors. Some of them are the duration of the project, how many change requests are typically raised during the projects in the organization, how reliable is the organization at delivering products on schedule, and the type of project being undertaken.

The buffer is represented in terms of how long it would take to implement some nice-to-have features, in addition to the MMF (feature buffer). In the given image, feature number five and six are considered as contingency or “nice-to-have” features. The schedule and cost projections would now be based on feature number six and not on feature number four. However, the team understands that among these six features, the first four are the minimum marketable features.

The third step is to manage change. When the project is initiated, there will be a need to manage changes in the requirements. As depicted in the Agile Triangle, cost, schedule, and quality are fixed. The only variable aspect is scope or feature. Hence, any new requirement added as part of change management would result in increasing the MMF, which is managed by either reducing the slack or by dropping a low priority feature. We can also observe in the image that initially, there were only 4 features that constituted the MMF. Now, a new feature is added, that needs to be accommodated as part of the MMF itself, given the priority of the requirement

The fourth step is to increase the MMF. When a priority change request comes in from the customer, a ‘New Feature’ is added to the existing minimal marketable product. It is important to deliver the new feature within the available schedule and budget, and it has to be positioned according to the customer’s prioritization. Since the priority of the new requirement falls between Feature 2 and 3, it is added in between as depicted in the image, resulting in the increase in the requirements that constitute MMF.

The last step is to accommodate the new feature. The ‘New Feature’ which is accepted will be accommodated and becomes a part of the minimal marketable product. In the given image, instead of four, now there are five features that make up the MMF. This new feature can be added by reducing the slack or contingency, and in this case, the schedule or budget cut-off would not change Notice that Feature 7 has been dropped to add the new feature, assuming that the budget and cost of the project cannot be changed. So, this change will be absorbed by reducing the buffer and not by extending the timeline or increasing the cost.

What are Kanban Boards?

Kanban is a concept related to Lean and Just-In-Time or JIT production. The Kanban board is divided into segments reflecting key activities. The number of segments in the Kanban board depends on the nature, complexity, and architecture of the project. Inputs from the team and business representatives are considered to finalize the segments on the Kanban board.

The stories are represented by index cards or post-it notes. The status of a card is represented by its location on the board and moved as the work progresses from beginning to end. A Kanban board helps the team realize how they are working and what has to be done next. This makes the team self-directing.

Kanban Cards

Each card on the Kanban board is referred to as a Kanban card. They are used to show progress through an iteration. The cards on a Kanban board reflect work items that move through different phases of the development cycle. The cards reflect everything that needs to be tracked, such as User Stories, Defects, and Tasks. The progress level to be tracked should be decided by the team in collaboration. Stakeholders assess the number of segments that the user story has to pass through before it is termed as complete. It is done by understanding the segment type needed by the project.

Simple Kanban Board

An example of a simple Kanban board is given here. It has three columns, ‘To Do,’ ‘In Progress,’ and ‘Done.’ Tasks are represented by cards and the status of the cards are posted under one of the three columns. This indicates how much work is piled up, at what stage. Thus, team members do not require effort to interpret the chart.

Detailed Kanban Board

When the user story goes through the process, that is, the activities between backlog and Release Ready as depicted in the image, it is termed as “Work In Progress”. The points to be considered in a detailed Kanban board are as follows: The Work in Progress limit allows the downstream processes to determine when they can consume more work. If WIP exceeds the threshold limit, the assembly line stops until the bottlenecks are removed.

It helps to focus on the bottlenecks in the system and triggers the appropriate corrective action. Work in upstream processes halts if a WIP is met. Further, sub-workflows can be used to better illustrate when a card is complete and ready for the transition to the next queue.

The given image represents a sample detailed Kanban board.

It shows the technical and functional aspects of a user story that needs to be addressed to call a story as ‘Release Ready.’ ‘Work in progress’ or ‘Work in process’ limits are set for each segment of the Kanban board. This ensures that at any point in time, there are only as many user stories picked up, as mentioned in the Work In Progress limit set for that segment.

Kanban and JIT

The Just-in-Time or JIT has been very popular in the manufacturing industry, where the production system develops, delivers, or consumes only what is required at a particular point in time, instead of stacking the workflow. JIT helps in maintaining minimal inventory in the system. It is also used in software projects to keep the system lean.

Some of the key aspects of JIT are as follows:

Kanban is a Pull or JIT system, wherein the flow of resources is controlled by replacing only what has been consumed. In other words, pull only the work that the team is capable of delivering at a particular point in time.

By visualizing and showcasing the user stories that will be addressed in the upcoming Sprint through the Kanban boards, Product Owners can ensure the user stories meet the ‘Definition of Ready’ in a JIT manner.

This ensures the team has a complete understanding of the requirement and acceptance criteria on a JIT basis, thereby avoiding any semantic gaps, which in turn helps in delivering value.

Siemens Health Services-Example

Siemens Health Services, a unit of Siemens healthcare IT, is a global provider of enterprise healthcare information technology solutions. Their systems provide new capabilities based on new technologies to stay ahead of the competition. The challenges, while meeting the committed release dates, were:

deadlines characterized by intense pressure and overtime

difficulty in planning and completing stories in timeboxed Sprint increments hectic last week of each Sprint, where teams would try to claim as many points as possible

making measures such as “cycle time” and “throughput” tangible, unlike relative story points and velocity. The given image shows the Kanban board used at Siemens Health Services. It showcases the various processes a requirement goes through before it is finally termed as done.

As seen in the table, the cycle time, throughput, and stories completed have increased drastically after a few Kanban iterations. Thus visualizing the work performed by the team, in the form of a Kanban board, helps identify bottlenecks, which can be addressed as uncovered, to improve the overall project delivery.

Incremental Delivery

Incremental delivery refers to the process of building products that can be deployed at the end of one or more iterations. Partial deliveries of the final product are made as early as possible if they are beneficial to the business. Incremental delivery helps build more features on the previously accepted solution.

This ensures the entire project is built on a strong foundation. The benefits of incremental delivery are as follows: It provides early feedback to the project, which helps improve the development of the rest of the product. It provides early Return on Investment, which can be used to finance the rest of the project. This is a significant advantage to the organization. Further, incremental delivery facilitates the moving of product into service. As they are addressed prior to adding further increments, it becomes cost-effective.

Reviews and Feedback Techniques

Feedback is a circular process where some proportion of a system’s output is returned or fed back to the input. This is often used to control the dynamic behavior of the system. Also, the team engaged in the production is termed as System, which requires a feedback loop. Some of the commonly used feedback techniques are a prototype, simulation, demonstration, and evaluation.

Note that, feedback can be obtained and corrective action can only be taken when the current work is showcased, as stated by the Acronym IKIWISI, which means ‘I-will-Know-It-only-When-I-See-It’. Additionally, business value can be confirmed and enhanced through these frequent reviews and feedbacks. The feedback systems built into the Scrum methodology are daily feedback on Sprint planning, process feedback during the retrospectives, and product feedback after each Sprint.

Benefits of Review and Feedback

Frequent review and feedback sessions help improve the internal quality of the solution, identify the risks at an earlier stage in the project lifecycle, minimize waste and project cost, and tailor the overall operating process, product, or services.

Reprioritization or Relative Prioritization

Dynamic requirements characterize agile projects. Priorities associated with requirements must be constantly revisited as new requirements emerge, while the existing requirements become obsolete.

Some of the points to remember are as follows:

Reprioritization of requirements in the product backlog must happen periodically to reflect changes in the environment, and stakeholder needs or preferences to maximize the business value.

The reprioritized Product Backlog should be reviewed by the business sponsors and related stakeholders, to ensure it is aligned with the overall vision of the project.

As shown in the image, the Product Backlog is a living artifact, whose content changes frequently.

New requirements are added, while the existing requirement undergoes change. In addition, the priority associated with the requirement also changes. Agile methods are flexible in accepting changes late in the project cycle; however, it is not feasible to keep adding features without compromising on the low priority features. Hence, the Product Backlog needs to be revisited at regular intervals to ensure that they remain updated and showcase the team’s objectives within the given budget and timeline.

As new requirements emerge and the priority of existing requirements change, some low priority requirements need to be dropped, so that the overall capacity of the release is not altered. As shown in the image, since the change request feature has a high priority and is included in the Product Backlog, it results in pushing Feature 13 below the Schedule or Budget Cut-Off. Hence, feature 13 moves to low priority.

Prioritization List

The best practice is to ensure there is a single prioritized list to ease the process of prioritization and planning. The list may contain functional requirements, non-functional requirements, defects, and change requests.

Agile Compliance

Agile Compliance is a concept which necessitates that the Agile projects adhere to the prescribed regulations or rules. Compliance guarantees that a product reaching the market will satisfy the rules that regulate the market or are stipulated by the company. These rules are set either by the market, the government or dictated by internal compulsions.

The key drivers of Agile compliance are as follows: Organizations have compliance standards ranging from branding and messaging to the features and quality of its products. For instance, an organization may want its operations to be governed by CMMi Level-5 standards of ISO 9000 standards.

Further, Governments require compliance in areas involving finance, security, and standards for products that could affect human health or safety. For instance, products in the healthcare industry must comply with Health Insurance Portability and Accountability Act or HIPAA, products in the federal government in the United States must follow certain rules, and products in the pharmaceutical industry have to satisfy the terms of pharmaceutical audits. An optimal level of security and compliance without compromising business agility or violating legal and moral responsibilities.

Some of the key points in Agile Compliance are as follows:

It is necessary to manage human and organizational factors that impede agility and compliance.

Agile projects demonstrate that they can satisfy these compliance requirements, by mapping requirements to corporate and governance compliance mandates.

It is important to find the correct path to ensure Agile compliance in an organization.

Earned Value Management(EVM) for Agile

Earned Value Management or EVM is a technique that shows the progress of a project using ratios and metrics. In EVM, story point is used as the basic measure to showcase how planned work is tracked against actual work performed. The end of the iteration is used as a checkpoint to calculate the earned value and determine the status with respect to the plan.

In Agile, the definition of EVM includes the following:

The story point is used as the measure of work planned and work performed.

Each Sprint boundary is established as the 'measuring point' to re-baseline any changes or work added or removed from the plan and re-evaluate the earned value results.

A comprehensive EVM may not be applicable to Agile projects. However, there are many aspects that ensure that value is earned consistently, such as, through the frequent involvement of business owners and reduced timeboxes.

EVM Terminologies

Some of the important terminologies used in EVM are as follows:

Planned Value or PV represents, the value of work planned to be accomplished based on the budget, either in dollars or number of hours.

Earned Value or EV represents the integrated value of work actually accomplished based on the budget, either in dollars or number of hours.

Actual Cost or AC represents the actual cost incurred for that increment of work that was accomplished at a certain point in time.

Budget at Completion or BAC represents the budget assigned to complete the work.

Some more terminologies used in EVM are as follows:

Estimate to Complete or ETC represents the forecasted amount to complete the remaining work based on past performance, either in dollars or number of hours.

Estimate at Completion or EAC represents the forecasted total amount for all the work in the project plan based on past performance.

Planned Story Release Point or PSRP represents the story points that are defined at the Product Backlog level for the release.

Expected Percent Complete or EPC represents the proportion of work that is expected to be completed by the end of a certain iteration. It is measured by dividing Current Sprint by Total Planned Sprints.

Actual Percent Complete or APC represents the proportion of work that is completed by the end of a certain iteration. It is measured by dividing Story Points Completed by Total Planned Story Points.

Earned Value Metrics with Formulae

Formulae for calculating earned value metrics and the metrics analysis are given in the table. It is recommended to go through the contents of the table for a better understanding.

Earned Value - Planning Parameters

Budget calculations can be made using the Agile parameters as follows:

Budget at completion can be calculated by multiplying the Product Backlog and the total cost to deliver each story point.

The planned number of iterations is calculated by dividing the product backlog by the team’s baseline velocity.

EVM for Agile

Agile projects often focus on the following key EVM definitions:

Product Backlog in Points: This is the total scope of development for the project, presented in a number of points. It is the total of story point estimate for all the stories planned in a given release.

Baseline Velocity: This is the amount of work done in story points per iteration by the team. It is the planned value of the total number of points planned to be delivered or completed during each iteration.

Cost Per Point: This is an estimated cost for delivering a single point. This would normally be based on past performance of the delivering organization. It can be calculated based on the historical data about the cost incurred to deliver certain functionality in terms of story points.

Agile Earned Value Metrics - Example

Consider the following information about a project:

The total product backlog is 200 points, the velocity of the team is 25 story points, and the cost required to deliver a story point is $1,600. Calculate the budget at completion, number of iterations required, planned percentage complete per iteration, and planned value per iteration.

Based on the given information about the project and using the formulas, the following can be concluded: Budget at Completion is $320,000 The number of iterations is 8 Planned percentage complete per iteration is 12.5% Planned value per iteration is $40,000 Assume that at the end of the first iteration, 20 story points, that is, 10% of the backlog was delivered and $30,000 was actually spent as actual cost.

Agile Contracts

Agile contracts contain the Agile nature of a project. An Agile contract must contain the following:

Objectives: Objectives of the project and cooperation between the companies.

Project Structure: Scrum process, key roles, and any differences from Scrum which apply. Also, an outline of the structure of the project and the process. Key roles would be identified and their responsibilities defined.

Key Personnel: Personnel responsible for the operational and escalation levels and their requirements. Identification of key personnel on the project like escalation hierarchy.

Payment Terms: Payment and billing, including any bonus and penalty clauses.

Termination Clause: Clauses governing the normal and early termination of the project.

Legal Details: Civil liability limit, venue, severability, and others based on local law and legal customs.

Agile Contracting Methods

Agile methodologies can work with any form of contracts. Some of the contract types are as follows.

Fixed Price or Fixed Scope

Time and Materials often referred to as T and M

Time and Material with Fixed Scope and a Cost Ceiling

Time and Material with Variable Scope and a Cost Ceiling Bonus or Penalty Clauses

The illustration given here shows the relationship between the effort and the revenue or profit for a Fixed Price with a Fixed Scope contract.

In this contract, the amount charged by the vendor is fixed, so the revenue is fixed. The profit decreases as the effort on the project increases. Therefore, the risk of cost escalation is borne by the seller.

The illustration given here shows the relationship between the effort and the revenue and profit for time and materials contract. In a T and M contract, the seller’s revenue is directly proportional to the effort. Each unit of the effort includes a profit margin, the profit also increases linearly with the effort. Therefore, in this contract, the risk of cost and effort escalation is borne by the buyer.

T and M with Fixed Scope and Cost Ceiling: The illustration given here shows a variant of the Time and Material contract, where the scope is fixed and the amount that the seller is allowed to bill for it, is capped at a certain ceiling. The seller’s revenue and profit increases until the cost ceiling are reached beyond which the profits start diminishing. The buyer is warranted against the indefinite extension of the project and a penalty is imposed on the seller if there is an extension beyond the agreed point.

T and M with Variable Scope and Cost Ceiling: This illustration given here shows a variant of the T and M contract wherein the scope is variable, but the amount that the seller is allowed to bill for it, is capped at a certain ceiling. The seller’s revenue and profit increases until the cost ceiling are reached. The project stops at this point as no more billings are allowed. Essentially, the project stops at the point of maximum profit, unlike the T and M with fixed scope and cost ceiling. The seller tries to restrict the cost and is willing to limit the scope when the budget is exhausted.

Bonus or Penalty Clauses Bonus or Penalty Clauses are variants of a fixed-price contract, which states the following: If the project is delivered on time, there is neither a bonus nor penalty to the seller. If the project is delivered prior to the deadline, the seller is liable to get an additional amount as a bonus, as agreed with the buyer.

If the project is delivered post the deadline, the seller is liable to pay a penalty to the buyer, as the buyer is impacted due to the delayed delivery. Note that, the time and money contracts can also be tailored with bonus and penalty clauses, whereby the hourly rates paid per resource would change depending on whether the team completes the work earlier or later than the specified timeline.

Summary

Let us summarize the topics covered in this lesson:

MMF is the smallest set of functionality that provides value to both internal users and external customers.

A Kanban board shows the current status of all the tasks to be done within this iteration. The tasks are represented by cards or post-it notes and their statuses are seen by their location on the board.

Agile recommends an incremental delivery, backed up by continuous feedback from stakeholders through Prototypes, Simulations, and Demonstrations.

Agile projects must demonstrate that they satisfy the market, organization, and government’s compliance requirements.

EVM for Agile projects can be done on the basis of stories sized in relative terms using story point units.

An Agile contract should encompass the Agile principle of “Customer collaboration over contract negotiation,” and cater to the Agile nature of the project.