3.

3 Key Concepts of Agile: There are some key concepts that you need to
understand, the terms used in the agile methodologies are:

3.3.1. User Stories:

 User stories are the product features, requirements that can add value
to the customer. As a user, we need to describe what I want, why, who,
acceptance criteria, and Story points.

 The stories can be taken in active sprints according to priorities and

requirements. The remaining user stories are available in the product
backlog list, which can be further taken in other sprints.

A key component of agile software development is putting people first, and a

user story puts end users at the center of the conversation.

These stories use non-technical language to provide context for the

development team and their efforts. After reading a user story, the team
knows why they are building, what they're building, and what value it creates. 

User stories are one of the core components of an agile program. They help
provide a user-focused framework for daily work which drives collaboration,
creativity, and a better product overall.

A user story is the smallest unit of work in an agile framework. It’s an end goal,
not a feature, expressed from the software user’s perspective.

A user story is an informal, general explanation of a software feature written

from the perspective of the end user or customer. 

The purpose of a user story is to articulate how a piece of work will deliver a
particular value back to the customer. Note that "customers" don't have to be
external end users in the traditional sense, they can also be internal customers
or colleagues within your organization who depend on your team.

User stories are a few sentences in simple language that outline the desired
outcome. They don't go into detail. Requirements are added later, once agreed
upon by the team.
Stories fit neatly into agile frameworks like scrum and kanban.

In scrum, user stories are added to sprints and “burned down” over the
duration of the sprint.

Kanban teams pull user stories into their backlog and run them through their
workflow.

It’s this work on user stories that help scrum teams get better
at estimation and sprint planning, leading to more accurate forecasting and
greater agility.

User stories are also the building blocks of larger agile frameworks like epics
and initiatives.

Epics are large work items broken down into a set of stories, and multiple
epics comprise an initiative.

These larger structures ensure that the day to day work of the development
team (on stores) contributes to the organizational goals built into epics and
initiatives.

Why create user stories?

 For development teams new to agile, user stories sometimes seem like an
added step. Why not just break the big project (the epic) into a series of steps
and get on with it? But stories give the team important context and associate
tasks with the value those tasks bring.
User stories serve a number of key benefits:

 Stories keep the focus on the user. A To Do list keeps the team focused on
tasks that need checked off, but a collection of stories keeps the team focused
on solving problems for real users.
 Stories enable collaboration. With the end goal defined, the team can work
together to decide how best to serve the user and meet that goal.
 Stories drive creative solutions. Stories encourage the team to think critically
and creatively about how to best solve for an end goal.
  Stories create momentum. With each passing story the development team
enjoys a small challenges and a small win, driving momentum.  
 Working with user stories

Once a story has been written, it’s time to integrate it into your workflow.
Generally a story is written by the product owner, product manager, or
program manager and submitted for review.

During a sprint or iteration planning meeting, the team decides what stories
they’ll tackle that sprint. Teams now discuss the requirements and
functionality that each user story requires. This is an opportunity to get
technical and creative in the team’s implementation of the story. Once agreed
upon, these requirements are added to the story.

Another common step in this meeting is to score the stories based on their
complexity or time to completion. Teams use t-shirt sizes, the Fibonacci
sequence, or planning poker to make proper estimations. A story should be
sized to complete in one sprint, so as the team specs each story, they make
sure to break up stories that will go over that completion horizon.  

How to write user stories

Consider the following when writing user stories:

 Definition of “Done” — The story is generally “done” when the user can

complete the outlined task, but make sure to define what that is.
 Outline subtasks or tasks — Decide which specific steps need to be completed
and who is responsible for each of them.
 User personas — For Whom? If there are multiple end users, consider making
multiple stories. 
 Ordered Steps — Write a story for each step in a larger process.
 Listen to feedback — Talk to your users and capture the problem or need in
their words. No need to guess at stories when you can source them from your
customers.
 Time — Time is a touchy subject. Many development teams avoid discussions
of time altogether, relying instead on their estimation frameworks. Since
stories should be completable in one sprint, stories that might take weeks or
months to complete should be broken up into smaller stories or should be
considered their own epic.
 
Once the user stories are clearly defined, make sure they are visible for the
entire team.
 User story template and examples

User stories are often expressed in a simple sentence, structured as follows:

“As a [persona], I [want to], [so that].”

Breaking this down: 

 "As a [persona]": Who are we building this for? We’re not just after a job title,
we’re after the persona of the person. Max. Our team should have a shared
understanding of who Max is. We’ve hopefully interviewed plenty of Max’s.
We understand how that person works, how they think and what they feel. We
have empathy for Max.
 “Wants to”: Here we’re describing their intent — not the features they use.
What is it they’re actually trying to achieve? This statement should be
implementation free — if you’re describing any part of the UI and not what the
user goal is you're missing the point.
 “So that”: how does their immediate desire to do something this fit into their
bigger picture? What’s the overall benefit they’re trying to achieve? What is
the big problem that needs solving?
For example, user stories might look like:

 As Max, I want to invite my friends, so we can enjoy this service together.

 As Sascha, I want to organize my work, so I can feel more in control. 
 As a manager, I want to be able to understand my colleagues progress, so I can
better report our success and failures. 
This structure is not required, but it is helpful for defining done. When that
persona can capture their desired value, then the story is complete. We
encourage teams to define their own structure, and then to stick to it.

Getting started with agile user stories

User stories describe the why and the what behind the day-to-day work of
development team members, often expressed as persona + need + purpose.
Understanding their role as the source of truth for what your team is
delivering, but also why, is key to a smooth process.
Start by evaluating the next, or most pressing, large project (e.g. an epic).
Break it down into smaller user stories, and work with the development team
for refinement. Once your stories are out in the wild where the whole team
can see them, you’re ready to get to work.

2. Story Points:
 Story points are a relative unit of measure which tells us that the story is
big or small. You can use different scales to measure the story, for
example 1, 3, 5, 8, 13 (Fibonacci series), which defines the complexity
level of the story.

User stories are key to Agile, helping define product functions and managing
requirements; to estimate these stories, we use story points.

If you’ve ever been to Beirut (or Cairo for that matter), you know that the time
it takes to get anywhere in the city is subject to so many factors other than
distance. Traffic could be extreme, or not; the rain could flood the city, or not;
construction, road blockage, time of day, random threat somewhere, overall
feeling of the population, and so on, are all variables you’d have to consider.

Similarly, the items in your product backlog are subject to a number of

variables, which makes agile planning not as straightforward as one may wish it
to be.

The basics of using story points

So what is a story point anyway?
A story point is a metric, more abstract than say ‘an hour’, used in agile project
management to figure out the implementation difficulty of a certain user story.
Fundamentally, it's a number that tells everyone on the team how challenging
a story is, based on factors such as its complexity, risks and efforts involved.

How are story points decided upon?

Typically, story point estimation happens during product backlog grooming
sessions with development and testing teams looking into the product backlog.
The product owner and team will try to ‘groom’ the backlog before sprint
planning happens; if you’re interested.
 Why would developers use story points?
Estimation is hard, especially for software developers; so many factors have to
be taken into account as product owners make decisions that affect the entire
team. Story points are meant to make estimating easier, and so instead of
estimating in hours, teams look at how much effort a product backlog item will
need relative to other items; hence the term relative estimation.
How to estimate story points

Story point estimation is based on three main components:

 Risk includes demands that are vague, dependencies and random changes.

 Complexity is related to how difficult a feature is to develop.
 Repetition is determined by how well the team member knows a feature and
how monotonous the tasks are.
3 steps to estimating story points
Step 1 — Use Fibonacci sequence numbers
There are two types of scales used for creating estimation matrices: the linear
scale and Fibonacci sequence.  

The latter is used when estimating absolute values is difficult such as

estimating the exact number of hours required for a given task.

It’s like trying to differentiate between 7 and 8, as opposed to 5 and 8; the

latter difference is simply more pronounced.

To put it this way, the Fibonacci sequence is used when we're looking for a
better estimate of the complexity of a project.

But keep in mind that you can still use a linear scale if you’d rather that; many
do.

The Fibonacci Sequence and its Golden Ratio Phi

The Fibonacci sequence is a series of numbers with each number being the
sum of the two previous numbers: 0, 1, 1, 2, 3, 5, 8, 13, 21 and so on.

For Agile, the sequence is typically modified to 0.5, 1, 2, 3, 5, 8, 13, 21 and so

on.
Step 2 — Create a story point estimation matrix

Story Point Estimation Matrix

 Your baseline is hereby included in the matrix as 1; this represents the
story that has the least amount of risk, complexity, and repetition.
 From there, you start building the story point estimation matrix or
estimation table as a way to measure effort more concretely, not just
with respect to time.
 Once the first story point is set, you can fill the table with other stories in
relation to this first.
 Each story point value may have more than one story connected to it.

Step 3 — Play planning poker to decide on story points

Planning poker is a great way to have the team agree on the correct story point
approximation for every item in the backlog.
 Prioritization Planning Poker (on the way)

 During the sprint planning meeting, each developer receives a set of cards
depicting the Fibonacci sequence.
 The backlog item is then brought to the table to be discussed and clarified.
 Each developer and tester privately gets to select the card they feel reflects
best their estimation for that item.
 The estimators reveal their cards at the same time and once consensus is
reached amongst the whole team, then we move on to the next backlog item.

It’s useful to set a maximum limit beyond which tasks can be split into smaller
items. Also, if a task is smaller than 1 or 0.5, it can be incorporated into
another task.
By the end of priority planning poker, the matrix should be filled and tasks
divided into rows based on their story points.
How to convert story points into hours?

How to convert story points to hours

 If you’re wondering how to convert size estimates into hours, let us wait
until the first sprint is over so we can track team velocity as it
progresses.
 Remember, Agile is all about iteration.
 As soon as the first sprint is done, we’ll know how many story points a
team can complete per sprint, which then allows us to forecast the
team’s performance for the next sprints.
 Given all backlog tasks are already estimated in story points, we now
know how many sprints we will need to complete the project and
convert these abstract units into real timelines.

Benefits of using story points?

 Estimating with story points in Agile is quick and accurate, and offers
understanding when it comes to the relative effort required for stories
that you’ve never dealt with before.
  Estimation is relative to already completed product backlog items in the
first sprint.
 Story points allow you to estimate without giving specific time
commitment.
 They help embrace the uncertainty that tags along with estimation; it is
what it is.
 Story points are accurate enough to plan sprints ahead, allowing you to
better manage time expectations for future work.

Common mistakes to avoid when using story points

 Story points represent complexity, uncertainty and risk together, and
should not be influenced by one variable alone.
 Sometimes when translating story point to hours, we get a false sense of
accuracy.
 Avoid averaging story points; the idea is not to be 100% accurate, but
accurate enough to be able to plan ahead of time.
 Do not story point bugs that are part of the original estimation.
 Avoid story pointing small tasks that are easy to estimate time-wise.
 When developers leave the team, don't forget to establish a new
reference to make sure everyone is on the same page given the work
context has changed.
 Estimation is a team effort, so make sure it stays that way.
 Don't ignore story-pointed issues that were made incorrectly; use the
retrospective to discuss them.

3. Product Backlog: An ordered list of everything (all features, requirements,

tasks) which is needed in the product.
In Agile development, a product backlog is a prioritized list of deliverables (such
as new features) that should be implemented as part of a project or product
development.

 It's a decision-making artifact that helps you estimate, refine, and

prioritize everything you might sometime in the future want to
complete.

 It helps ensure the team is working on the most important and valuable
features, fixing the most important bugs, or doing other important work
critical to product development.

 The backlog, therefore, is tremendously useful in situations when you

are unable to do everything being asked (so, most situations), or in
contexts when even a small amount of planning will help a lot (so, in
most contexts).

 Many think of this backlog as a to-do list, and define it in exactly this
way, as a list of things you must do to deliver your product to market.

 In truth, it is not necessarily a to-do list. Think of it as a wish list.

Think of a product backlog as a wish list — not a to-do list.

Why?

 When we think about the backlog as a wish list, we invite flexibility and
change.

 In doing so, we enable true agility and give the organization a power
that’s necessary to win in the marketplace today: the power to change
its mind.

In this context, the purpose of the backlog can be reduced to three simple
goals.
  Develop a common ground to align stakeholders and teams, so that
teams implement the most valuable user stories.
 Provide flexibility to adapt to new needs and realities.
 Improve the accuracy of product release forecasts by creating a
common denominator across many teams collaborating on one
product.

This backlog is often fed by a strategic roadmap, then divided into themes,
epics, sprints, and user stories. Most include items that would be completed
within the next quarter or fiscal year.

Below is a product backlog example for a social media game. It’s organized by

themes, features, and user stories.
4. Sprint Backlog:
 The list of features that are selected to be delivered in the sprint over
the period.
 The sprint backlog is a container for work the team is committed to
doing, either right now as a part of the sprint (typically a one- to four-
week period).
 It is an output of a sprint planning meeting attended by the team.
 The sprint backlog, ideally, doesn’t change at all for duration of the
sprint.
 It consists of user stories that the team has committed to delivering
within the next sprint’s timeframe.
 But it can also include bugs, refactoring work, and so forth.
 It is usually more granular, and broken down into tasks, focusing on the
technical implementation of a user story.
 It is the range of the scrum master and team.

Agile Product Backlog vs. Sprint Backlog

Content, granularity, and immediacy are three key differences between the
product backlogs and sprint backlogs.
5. Defects : Defects are the failure of the product requirements that usually
occur after testing the product requirement mismatch. A bug or defect is
stored in the Product Backlog for sequencing and scheduling.

6. Velocity : A number of story points that are to be delivered at the end of the
sprint are called Velocity in agile.

The story points define the capacity of the team to deliver stories in the sprint.

7. Swimlanes: A visual representation of the story vs the status of Kanban/Agile

board.

8. Minimum Viable Product (MVP) : A minimal product that meets the client’s
expectations, the MVP can help the product team receive user feedback as
quickly as possible to iterate and improve the product.

9. Release/Version Control : It contains of several iterations or sprints.

3.4 Agile Project Management Vs. Traditional
Project Management
Steps to create online Project plan

Why Agile is preferred over traditional project management

What is Traditional Project Management

 Traditional project management is an established methodology

where projects are run in a sequential cycle.
 It follows a fixed sequence: initiation, planning, execution, monitoring,
and closure.
 The traditional project management approach puts special emphasis
on linear processes, documentation, upfront planning, and
prioritization.
 As per the traditional method, time and budget are variable and
requirements are fixed due to which it often faces budget and
timeline issues.
 For every step, there are tools and techniques defined by
the standard methodology PMBOK® which are followed by project
managers.
 Interestingly, it also includes other methodologies such
as PRINCE2 which is followed by various organizations under UK
government and private companies like Vodafone, Siemens and
others.
 It is also called the Waterfall model.

Benefits of traditional methodology

 Clearly defined objectives
 Controllable processes
 Clear documentation
 More accountability
What is Agile Project Management
While Agile is a general approach used for software development, it relies
heavily on teamwork, collaboration, time boxing tasks, and the flexibility to
respond to change as quickly as possible.

The agile manifesto has four important values:

1. More focus on individuals and interactions than processes and tools
2. Working software is more important than comprehensive
documentation
3. Customer collaboration is more vital than negotiation
4. The process should respond to change rather than blindly following a
plan

Benefits of agile project management

 Flexible prioritization
 Early and predictable delivery
 Predictable costs and schedules
 Improves quality
 More transparency

Agile follows an iterative process where projects are divided into sprints of
the shorter span. Unlike the traditional approach, less time is spent on
upfront planning and prioritization as agile is more flexible in terms of
changes and developments in the specification.
Traditional v/s Agile project methodology
The table down below shows the major differences between the traditional
and agile project methodology.

Characteristics Agile approach Traditional approach

Organizational
Iterative Linear
structure

Scale of projects Small and medium scale Large-scale

Clearly defined before

User requirements Interactive input
implementation

Involvement of
High Low
clients

Development
Evolutionary delivery Life cycle
model

Customers get involved

Customers are involved from
Customer early in the project but not
the time work is being
involvement once the execution has
performed
started

Escalation When problems occur, the

Escalation to managers
(growth) entire team works together to
when problem arise
management resolve it

Traditional model favors

Model preference Agile model favors adaption
anticipation (expectation)

Less focus on formal and More serious about

Product or process
directive processes processes than the product

Test Tests are planned one sprint

Comprehensive test planning
documentation at a time

Project manager provides

Scrum master facilitates and estimates and gets approval
Effort estimation
the team does the estimation from PO for the entire
project

Reviews and Reviews are done after each Excessive reviews and
approvals iteration approvals by leaders
Selection of the correct approach

Below down are some factors you can take into consideration while
choosing the right methodology for your project.

 Take a look at the project requirements. Are the requirements clear? If

project requirements are unclear or tend to change, choose the agile
methodology. And, the traditional methodology fits best to a situation
where the requirements are clearly defined and well understood from
the first go.

 Consider the technology involved in the project. The traditional project

management methodology is more appropriate if no new technology
or tools are involved. Agile methodology, being more flexible than the
former allows more space for more experimentation with the new
technology.

 Is the project prone to unwanted risks and threats? Considering the

rigid nature of the traditional methodology, it’s not advisable to go
this methodology. However, risks can be addressed sooner in the agile
approach, it seems like a better option in terms of risk management.

 Another important factor is the availability of resources. The traditional

approach works best with big and complex teams and projects.
Whereas an agile team usually consists of a limited number of
experienced team members.

 The criticality of an end product depends a lot on the nature of the

chosen project management methodology. As the traditional method
involves a documentation, it is very much suitable for critical products
as compared to the agile project management methodology.
Chapter 4: Agile Teams, Size and Schedule

4.1 Dynamic System Development Method

The Dynamic Systems Development Method (DSDM) -Agile
Methodology

 It is an agile project delivery framework, primarily used as a

software development method.
 It is a framework which embodies much of the current knowledge
about project management.
 DSDM is rooted in the software development community, but the
convergence of software development, process engineering and
hence business development projects has changed the DSDM
framework to become a general framework for complex problem
solving tasks.
 The DSDM framework can be implemented for agile and traditional
development processes.

DSDM is a,

 Straight forward framework based on best principles to start

implementing a project structure.
 Simple
 Extendible
 But not calming to be the solution to all kind of projects.

Why use DSDM?

 Results of development are directly and promptly visible

 Since the users are actively involved in the development of the
system, they are more likely to embrace it and take it on.
 Basic functionality is delivered quickly, with more functionality
being delivered at regular intervals.
 Eliminates bureaucracy and breaks down the communication barrier
between interested parties.
 Because of constant feedback from the users, the system being
developed is more likely to meet the need it was commissioned for.
  Early indicators of whether project will work or not, rather than a
nasty surprise halfway through the development
 System is delivered on time and on budget.
 Ability of the users to affect the project's direction.

DSDM Development Process

Definition of dynamic systems development method

(DSDM)
 Like the wider agile family of methodologies, dynamic systems
development method is an iterative approach to software
development but adds additional discipline and structure to the
process. Central to DSDM is the principle that “any project must be
aligned to clearly defined strategic goals and focus upon early
delivery of real benefits to the business.”
Key principles of the dynamic systems development
method
1. Focus on the business need: DSDM teams must establish a valid
business case and ensure organizational support throughout the project

2. Deliver on time: Work should be time-boxed and predictable, to build

confidence in the development team.

3. Collaborate: DSDM teams must involve stakeholders throughout the

project and empower all members of the team to make decisions.

4. Quality: To ensure high quality, the level of quality should be agreed

with the business at the start of the project. This is enforced through
continuous testing, review, and documentation.

5. Build incrementally from firm foundations: Teams must do enough

design work up front (EDUF) to ensure they know exactly what to build,
but not too much to slow development.

6. Developer Iteratively: Take feedback from the business and use this to

continually improve with each development iteration. Teams must also
recognize that details emerge as the project or product develops and they
must respond to this.

7. Communicate continuously and clearly: Holding daily stand-up

sessions, encouraging informal communication, running workshops and
building prototypes are all key DSDM tools. Communicating through
documents is discouraged - instead, documentation must be lean and
timely.

8. Demonstrate control: The project manager and team leader should make

their plans and progress visible to all and focus on successful delivery.
Advantages of dynamic systems development method
 Projects are delivered on time, whilst still allowing flexibility

 Progress can be easily understood across the organization

 Business cases are at the core of the DSDM model, ensuring

delivered projects have real business value

Disadvantages of the dynamic systems development

method
 Large management overhead and costly implementation makes this
unsuitable for small organizations

 DSDM can be restrictive and inhibit developer creativity. Projects

are likely to be completed exactly as specified, even if more elegant
solutions are available.

Is DSDM right for your team?

Every development methodology has its strengths and weaknesses. If your team values
predictability, consistency and tight control of costs, DSDM might be a good fit. However,
you'll lose creativity and flexibility, which may not be best suited to smaller startups.

DSDM Project Structure

The DSDM project consists of 7 phased steps which are organized and embedded in a rich set
of roles and responsibilities and are supported by several core techniques.

 Roles and Responsibilities

 Team Organization and Size
 7 Phases to Rule Them

1. Pre-Project
2. Feasibility Study
3. Business Study
4. Functional Model Iteration
5. Design & Build Iteration
6. Implementation
7. Post-Project

Core Techniques Used in DSDM

1. Time boxing: Traditional Project Management uses milestones where as DSDM uses
timeboxing technique. Is an interval, usually no longer than 2,4 or 6 weeks, where a given set
of tasks should be achieved.

Timebox

 Can contain several tasks.

 At the end need to deliver a product.
 Are subject to change since tasks are defined, not what to be
delivered.
  Can change the tasks during time box iteration which allows for
rapid response to business needs.
DSDM drops functionality in flavor of delivering in time.

2. MoSCoW Rules: DSDM projects are concerned to be in time and on budget and
users are heavily involved in the development process. So it is mandatory to keep on watch
on what users need the most.

User requirements may change (during the process) ;

 Aware of new technical possibilities

 User work environment changes

The DSDM techniques to weight the importance of requirements are the MosCow rules. And
the rules are as follows,

1. Must have: All features classified in this group must be

implemented and if they are not delivered, the system would simply
not work
2. Should have: Features of this priority is important to the system but
can be omitted if time constraints endanger.
3. Could have: These features enhance the system with functional
items which can easily be reassigned to a later timebox.
4. Want to have: These features only serve a limited group of users
and are of little value.

3. Prototyping: Evolutionary prototyping in DSDM projects satisfy 2 principles,

 Frequent Delivery
 Incremental development
Implements critical functionality first so can discover difficulties early in the development
process and allow having early deliverable to get user feedback.
The necessary feedback-loop is provided by a workshop which is the last important technique
in a DSDM project.

DSDM differentiates on the following for types of prototypes,

1. Business Prototype: Allow assessment of the evolving system

2. Usability Prototype: Check the user interface
3. Performance Prototype : Ensure solution will deliver performance or
handle volume
4. Capability Prototype: Evaluate possible options
Key Success Factors
The DSDM consortium has compiled 10 most important factors from its members:

 Acceptance of DSDM philosophy before starting work.

 The decision making powers of users and developers inside the
development team.
 The commitment of senior user management to provide significant
end-user involvement.
 Incremental delivery.
 Easy access by developers to end-users.
 The stability of the team.
 The development team skills.
 The size of the development team.
 A supportive commercial relationship.
 The development technology.

4.2 Value-Driven Delivery in the agile world

What is value?

We need to define what a value is before dwelling into how to go about value
driven delivery in the agile software development. The value could be defined
in terms of monetary benefit, compliance adherence, an answer to the
competition in the market etc. The term value can differ for each client based on
what the client is expecting the product/software to accomplish. The end
product of a project is a value to the customer.

In the agile way of project management, always the requirements are prioritized
based on what adds more value to customer delivery. For projects with
monetary benefits, value is commonly calculated using methods such as return
on investment (ROI), internal rate of return (IRR), and net present value (NPV).

How do you deliver value to the customer?

The value-driven delivery is a combination of value adding and risk reducing

activities. The value-driven delivery can be achieved by following some best
practices as below:
 1. Identity value, a monetary value, competitive value etc.
2. Prioritize the requirements so that high value is delivered to the
customer fast.
3. Deliver the value to the customer iteratively so that the return on
investment (ROI) is rapid.
4. Receive the feedback and work on things which need improvement,
which can provide more value to the customer
5. Collaboration with all the stake holders is the key in identifying what
adds more value to the overall project, to the client and to the whole
process.
6. Review of what is being delivered in each iteration. The project
requirements, the environment around it keep changing. We need to
have an eye on what is changing, re-look at priorities, and re-order
them.
7. Identify risks and have a plan to reduce them in the course of the
development. Risks are anti-value and they have the potential to
reduce the value delivered to the customer.
8. Whenever there is a new requirement, it has to be compared with the
whole priority list so that we don’t divert in our objective of providing
highest value to the customer. If the new requirement adds more value
to the deliverable, then that should move to priority list.
9. We need to see what are the Minimum Marketable Features (MMFs)
that should be there in the early releases to potentially increase the
value delivered to the customer.
10.Experiment early so that we fail fast and rethink on our approach very
early in the development stage.
11.The feedback of each value prioritized can be tracked through
prototyping, simulation, providing demonstration etc.

When not to have plan driven delivery?

The value-driven delivery beats the plan drive delivery in many ways:

1. Plan driven delivery thrives on planning and estimation which cannot

be done early when the nature of the project is complex. In agile
world, as the releases are in iterations, elaborate planning is not
required.
2. Requirements keep changing and planning early would lead to lot of
re-work. Value driven delivery decides what adds more value to
customer with a given set of requirements and implements the same. If
there is a change request that adds more value to client, then the
change request can be easily accommodated in this agile way.
4.3 Team and roles of an Agile Team
4.3.1 Scrum Master
4.3.2 Product Owner
4.3.3 Development Team