Transcript Agile

SECTZG652 : Agile Software Process
Session – 01: Introduction to Agile
1
Introduction




Traditional approaches of software development
Need for Agile
Benefits of Agile
Why agile projects work better
2
Traditional Model
Feasibility Study
User Requirements
Analysis
System Design
Detailed Design
Coding
Testing
Deploy and Maintain
3
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Traditional approaches - Objective

In the face of changing requirements, traditional project management "best
practices" suggest that we try to
 Lock down requirements to form a baseline
 Implement change control and
 Fall back on the documented requirements or the contract as means to enforce the
change control.
 All-at-once delivery

Success of a project depends on ‘Triple Constraints’
 Ending the project within schedule
 Finishing under budget
 Completing entire scope

Results of projects differed based on the choice
 Lenient and allowing too much change to the baseline without triggering the change
control processes (in the interest of customer satisfaction) - may go way over
budget and may be late due to additional features being added
 Too strict and refusing to accept changes to the baseline. Sometimes leads to irate
customers - may go over budget and may be late due to the extra work and delays
4
caused by assessing the changes to the baseline and the often contentious
negotiations with the customers.
Waterfall Model
5
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Waterfall Model

Pros
 The model is straight forward
 Very formal and disciplined model
 The model is rigid and each of the phases has certain deliverables and a review
process immediately after a particular phase is over

Cons






Assumes everything is predictable at once
Expects all requirements to be captured upfront
Changes to requirements would be very expensive
Bugs are expensive to fix and new requirements are expensive to incorporate.
Problems are not discovered until system testing
It is not suited for long or complex projects or projects where the requirements can
change
 You do not see a working version of the software until late in the life cycle
6
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Incremental Model

Incremental model
 In incremental development, we break up the work into smaller pieces, schedule them to be
developed over time and integrate as they get completed
 The system is developed in different stages with each stage consisting of requirements, design,
development, and test phases (a waterfall)
 In each stage, new functionality is added
 Each increment should deliver something of value to the customer
 Allows the user to see a functional product very quickly and allows the user to impact what
changes are included in subsequent releases

Pros
 Allows for a very complex project with incomplete initial understanding of requirements since
development is done in small, incremental phases where each phase consists of requirements,
design, implementation and test
 Feedback from early increments improves the later stages
 Users see value early

Cons
 Requirements should be quite stable because it is expensive to go back and redesign
something that has already been delivered in a previous increment - Known a software
breakage
 Each phase of iteration is rigid and does not overlap each other
 All the requirements are not gathered up front for the entire software life cycle which can create
problems at the later stages in the design and development cycle
7
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Incremental Model
Increment 1
Increment 2
Increment 3
Requirement
Design
Requirement
Feedback
Build
Design
Test
Build
Design
Test
Build
Requirement
Feedback
Test
8
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Iterative Model

Iterative model
 An iterative lifecycle model does not attempt to start with a full specification of requirements – It
can evolve over time
 Development begins by specifying and implementing just part of the software, which can then
be reviewed in order to identify further requirements
 Value to cost ratios can be used to decide priorities
 This process is then repeated, producing a new version of the software for each cycle of the
model

Pros
 Allows requirements to evolve based on user feedback
 Customers see value at the end of every iteration
 Facilitates the support for changes within the life cycle

Cons
 The communication overhead for the project team is significant
 It is difficult to freeze requirements, and they may continue to change in later iterations because
of increasing customer demands. As a result, more iteration may be added to the project,
leading to project delays and cost overruns
9
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Iterative Model
Requirement
Evaluation and
refinement
Design
Initial Planning
Deploy
Test
Build
10
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Need for Agile Development
• Client not sure how the end
• Requirements are evolutionary
product should look like
• Need for end user feedback for
• Need for having the best features
delivering better functionalities
for better marketability
Why
Agile?
• Shorter release cycles required
• Identify and follow
optimal processes
• Improve productivity
to get continuous feedback
• Working software to reach the
customers faster
11
Agile Model
High Level Requirements
Analysis (Business
Requirements
Domain Model)
Define Program Roadmap
Key Features
Release …N
Release 2
unclear/continuously evolving
Release 1
• Release Goal
• Features
Identification
Product Backlog
Creation
(High Level
Feature Sets,
Prioritization)
• Requirements are
• Requirements &
Architecture
Elaboration
• Sprint Zero (Pre-Game Phase)
Sprint …N
Sprint 2
Sprint 1
Sprint Execution
Planning
Refine
Requirements &
Architecture
Design By Feature
Code By Feature
Test By Feature
Certify By Feature
(UAT)
Sprint Review and
Closure
• Release
Integration
• System &
Performance &
User
Acceptance
Testing
Daily Standup Meeting
High Level Architecture
Analysis
• Production
Rollout
• Warranty
Support
12
• Unproven technology is used
• Frequent customer-project team
interaction
• Usage of Cutting edge
Technology architecture & Initial
iterations may evolve architecture,
UI frameworks etc
• Suited for large duration
projects;
• Software is developed in
numerous releases by globally
distributed teams ;Release to
production can combine one or
more iterations
Benefits of Agile

At a strategic level, Agile benefits include










Ongoing risk management: This is achieved by regularly confirming and adjusting requirements according to
[17]
ongoing interactions with the customer and by delivering fully functional and fully tested software features
Ongoing control of budget expenditure: by providing decision makers with the opportunity to review and
assess the business value of deliverables at each iteration, and with the option to adjust, postpone or stop
ongoing funding based on the return on investment (ROI) of delivered work.
Rapid delivery of tangible outcomes: by focusing team efforts on regularly producing fully functional, fully
tested, production-ready software features that can be used by the organization well before the end of the
project timeline.
Strong alignment with business requirements: by directly involving the customer in the initial and ongoing
review of developed software, and by incorporating their feedback throughout the process.
Focus on the highest-priority features: by continually working with the customer to confirm and adjust the
work undertaken by the project team to align with the most current priorities of the organization.
Responsiveness to business change: by adjusting work throughout the process to incorporate organizational,
industry and technology changes.
Transparency in status tracking: by regularly providing tangible outputs for customer review, combined with
the use of open communication forums and centrally available real-time status-tracking tools.
Substantially higher-quality outputs: by incorporating rigid testing regimes throughout the process and by
working regularly with the customer to confirm the usability and business value of delivered features.
Greater employee retention: by creating work environments that are based on high communication,
empowering the team, trusting their expertise, encouraging innovation, and regularly acknowledging their
[18]
contribution to the organization .
Minimized whole-of-life software costs: by incorporating usability, quality and extensibility into solutions
throughout the delivery process – thereby reducing both development costs and support and maintenance 13
overheads – and by providing a less risky and more cost-effective platform for additional functionality to be
integrated into the solutions.
Benefits of Agile

Tactical benefits of Agile








The production of more valuable outputs per resource hour:
Earlier identification of technical issues
Less rework and “throw-away” work
Reduced need to create – and maintain – detailed documentation
Greater flexibility
Greater opportunity for innovation
Reduced dependency on paper status reports
Reduced demand for ongoing support and maintenance
14
Traditional Vs Agile Development
Category
Visibility
Traditional Development


Adaptability


Agile Development
High Involvement of client during
Requirement elicitation
Little or no visibility until the build
is ready for UAT testing
•
Active involvement of client through out the
life cycle
Define detail requirement in
advance
Difficult to change requirement
due to longer delivery cycles


Adapt requirement at each iteration
Quickly respond to business and process
changes
Business
value
•
Little or no Business value is
delivered until the system is
complete
•
Deliver small usable components through
out the iteration process
Risk
•
Risk remains high until the
system is delivered
•
Identify issues earlier in the process,
eliminating risk in the earlier cycle
15
Traditional Vs Agile Development
Traditional
Detailed requirements are frozen before execution begins.
(BDUF)
The entire scope of the project is attempted to be defined in
the project scope document.
Agile
Iterative. Only detailed requirements for an upcoming sprint/iteration
needs to be frozen.
The entire scope of the project is defined in a simple-to-use product
backlog which has a specific owner too (product owner).
Emphasis on documentation (Req., Design)
Emphasis on creating working software iteratively with minimal
documentation.
When the project is in execution phase, for any scope change, A change management process is followed only if the sprint backlog
a change management process needs to be followed.
is changed.
Team works as per plan passed on to them by the project
Team picks up features for a sprint/iteration from prioritized release
manager, managing the project goes by the intuition of project backlog and works collaboratively within themselves and with the
manager
client. Project Manager is more in guiding and monitoring role at the
sprint level.
Productivity of the team remains almost constant throughout Productivity of the team increases as the project progresses and
the project duration.
teams working on Agile projects prefer not to work on traditional
projects.
Problems in the project become visible late in the project when Problems are exposed early and the team gets the opportunity to fix
the first demo is given to the client.
them early in the project.
Lessons learnt are discussed after the phase completes.
Retrospection is done after each iteration / sprint completes.
The opportunity to apply phase specific learning comes only
with the next project.
Client sees the end product when the project is near
completion.
Client does not interact with the teams and hence may have
concern on not being informed if the project delays.
Lessons learnt are adopted upfront in the upcoming iteration / sprint
itself.
Client sees the product getting built every iteration and can
change/reprioritize the requirements, if business demands.
16
Product owner is up-to-date on the project status since he attends
the daily standup meeting as part of the composite team.
Challenges
•
•
•
•
By only looking at small pieces (increments) of the software, we may have to
do massive rework, which might have been avoided if we analyzed or
designed the whole system correctly.
We might "paint ourselves into a corner;" that is, we can get a system that is
incapable of supporting some new requirement.
We may be unable to add global requirements, such as alternate language
support, performance, and security. A typical example is trying to retrofit
"security" to an application that was not designed with this requirement in
mind.
We might go slower because we have to restart analysis and design sessions
for each increment, instead of doing it once at the start of the project.
17
References
I.
Managing Agile Projects Kevin Aguanno / Multi-Media Publications 2004
(Available in Books 24X7) – Chapter 1
II. Agile Project Management for Dummies - Mark C. Layton/ John Wiley &
Sons - 2012 (Available in Books 24X7) – Chapter 1
18
SECTZG652 : Agile Software Process
Session – 02, 03: Basics of Agile Software
Development, Principles of Agile
19
Introduction





Iterative Planning
Agile Development
10 Lean Best practices
Agile Manifesto
Agile Principles
20
Iterative Planning

Risk Driven Development
 Chooses the riskiest, most difficult features for the early iterations
 High risks are surfaced and mitigated early

Client Driven Development





Choice of features for next iteration comes from the client
Focus is on getting highest business value items implemented
Adaptively plan for the next iterations based on their latest insight
Client has ongoing control and choice as fresh information is available
Recommended approach
 Both have to be applied.
 Client do not always appreciate what is technically hard or risky.
 Developers do not appreciate what has high business value
21
Iterative Planning

Time-boxed Iterative Development
 Fixing the iteration end date and not allowing it to change
 Overall project may be time-boxed as well
 If chosen requests (scope) cannot be met within the iteration end date scope is
reduced by moving out the low priority items back to the wish list
 No changes to be made to the scope of the iteration once it has started
 Team itself is allowed to reduce the scope of an iteration if the deadline cannot be
met

Evolutionary Iterative Development
 Requirements, plan, estimates and solution evolve, are refined over the course of
the iterations
 A detailed schedule is not created beyond a relatively short time horizon and level
of detail and commitment is commensurate with the quality of information
 Consistent with the pattern of unpredictable discovery and change in new product
development
 Captures feedback regarding installed product and uses it to guide the next delivery
 Helps best meet some difficult to predict requirements
Agile Development

Adaptive Development
 Elements adapt in response to feedback from prior work – feedback from users,
tests, developers, etc.
 Very similar to evolutionary but more onus is on the feedback response mechanism
 Agile Development
 Applies time-boxed iterative and evolutionary development, adaptive planning,
promote evolutionary delivery
 Includes other values and practices that encourage Agility – rapid and flexible
response to change
 Motto is to embrace change; Strategy is maneuverability
 Most of the Agile practices are nothing new. Instead, the focus and values behind
Agile Methods differentiate them from more traditional methods
 Promotes practices and principles that reflect an agile sensibility of Simplicity,
lightness, communication, self-directed teams, programming over documentation
and more
10 Lean Best Practices – Application to
Software Development





Eliminate waste - eliminate or optimize consumables such as diagrams and models
that do not add value to the final deliverable
Minimize inventory - minimize intermediate artifacts such as requirements and design
documents
Maximize flow - use iterative development to reduce development time
Pull from demand - support flexible requirements
Empower workers - generalize intermediate documents, tell developers what needs
to be done, not how to do it

Meet customer requirements - work closely with the customer, allowing them to
change their minds



Do it right the first time - test early and refactor when necessary
Abolish local optimization - flexibly manage scope
Partner with suppliers - avoid adversarial relationships, work towards developing the
best software

Create a culture of continuous improvement - allow the process to improve, learn
from mistakes and successes
24
Agile Manifesto




Individuals and interaction over process and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan

That is, while there is a value in the items on the right, the items on the left
more are valued more

Where traditional approaches emphasize a rigid plan, avoiding change,
documenting everything, and hierarchal-based control, the Manifesto focuses
on




People
Communications
The product
Flexibility
25
12 Agile Principles
1. Our highest priority is to satisfy the customer through early and continuous
delivery of valuable software.
2. Welcome changing requirements, even late in development. Agile processes
harness change for the customer's competitive advantage.
3. Deliver working software frequently, from a couple of weeks to a couple of
months, with a preference to the shorter timescale.
4. Business people and developers must work together daily throughout the
project.
5. Build projects around motivated individuals. Give them the environment and
support they need, and trust them to get the job done.
6. The most efficient and effective method of conveying information to and within
a development team is face-to-face conversation.
7. The most efficient and effective method of conveying information to and within
a development team is face-to-face conversation.
8. Working software is the primary measure of progress
26
12 Agile Principles
9. Agile processes promote sustainable development. The sponsors, developers,
and users should be able to maintain a constant pace indefinitely.
10. Continuous attention to technical excellence and good design enhances
agility.
11. Simplicity — the art of maximizing the amount of work not done — is
essential. The best architectures, requirements, and designs emerge from
self-organizing teams.
12. At regular intervals, the team reflects on how to become more effective, then
tunes and adjusts its behavior accordingly
27
Where We Are Now
17–28
•
Traditional PM versus Agile
Methods
Traditional PM Approach
– Concentrates on thorough, upfront planning
of the entire project.
– Requires a high degree of predictability to be
effective.
• Agile Project Management (Agile PM)
– Relies on incremental, iterative development
cycles
to complete less-predictable projects.
– Is ideal for exploratory projects in which
requirements need to be discovered and new
17–29
Traditional Project Management versus
Agile Project Management
Traditional
Agile
Design up front
Continuous design
Fixed scope
Flexible
Deliverables
Features/requirements
Freeze design as early as possible
Freeze design as late as possible
Low uncertainty
High uncertainty
Avoid change
Embrace change
Low customer interaction
High customer interaction
Conventional project teams
Self-organized project teams
17–30
TABLE 17.1
Project Uncertainty
17–31
FIGURE 17.1
Agile Project Management
• Agile PM
– Is related to the rolling wave planning
and scheduling project methodology.
• Uses iterations (“time boxes”) to develop a
workable product that satisfies the customer and
other key stakeholders.
• Stakeholders and customers review progress and
re-evaluate priorities to ensure alignment with
customer needs and company goals.
• Adjustments are made and a different iterative
17–32
cycle begins that subsumes the work of the
Iterative, Incremental Product Development
17–33
FIGURE 17.2
•
Agile Project Management
(cont’d)
Advantages of Agile PM:
– Useful in developing critical
breakthrough technology or defining
essential features
– Continuous integration, verification,
and validation of the evolving
product.
– Frequent demonstration of progress
to increase the likelihood that the
end product will satisfy customer
needs.
17–34
Agile PM Principles
Focus on customer value
Iterative and incremental
delivery
Experimentation and
adaptation
Self-organization
Continuous improvement
17–35
Popular Agile PM Methods
Scrum
Crystal Clear
Extreme
Programming
RUP (Rational
Unified Process)
Agile Modeling
Agile
PM
Method
s
Rapid Product
Development
(PRD)
Dynamic
Systems
Development
Method (DSDM)
Lean
Development
17–36
Agile PM in Action: Scrum
• Scrum Methodology
– Is a holistic approach for use by a crossfunctional team collaborating to develop a
new product.
– Defines product features as deliverables and
prioritizes them by their perceived highest
value to the customer.
– Re-evaluates priorities after each iteration
(sprint) to produce fully functional features.
– Has four phases: analysis, design, build, test
17–37
Key Roles and Responsibilities
in the Scrum Process
• Product Owner
– Acts on behalf of customers
to represent their interests.
• Development Team
– Is a team of five-nine people with crossfunctional skill sets is responsible for
delivering the product.
• Scrum Master (aka Project Manager)
– Facilitates scrum process and resolves
impediments at the team and organization
17–38
Applying Agile to Large Projects
• Scaling
– Is using several teams to work on
different features of a large scale project
at the same time.
• Staging
– Requires significant up-front planning to
manage the interdependences of
different features to be developed.
– Involves developing protocols and
defining roles to coordinate efforts and
assure compatibility and harmony.
17–39
Limitations and Concerns of
Agile PM
• It does not satisfy top management’s need
for budget, scope, and schedule control.
• Its principles of self-organization and close
collaboration can be incompatible with
corporate cultures.
• Its methods appear to work best on small
projects that require only five-nine
dedicated team members to complete the
work.
17–40
Key Terms
Feature
Iterative incremental development (IID)
Scrum meeting
Scrum Master
Sprint backlog
Product Backlog
Product Owner
Scaling
Agile PM
Self Organizing Team
17–41
SCRUM –
Agile Project Management
Joint Advanced Student School
Maria Belkina
Jennifer Schiller
Maxim Masunov
Vycheslav Filippov
April 2006
Agenda
–
–
–
–
–
–
–
–
–
–
Introduction
Agile Project Management
What is Scrum?
History of Scrum
Functionality of Scrum
Components of Scrum
• Scrum Roles
• The Process
• Scrum Artifacts
Scaling Scrum
Evolution of Scrum
Scrum & XP
Conclusion
JASS 2006
Agile Project Management Scrum
43
Introduction
• Classical methods of software development have many
disadvantages:
- huge effort during the planning phase
- poor requirements conversion in a rapid changing environment
- treatment of staff as a factor of production
 New methods:
Agile Software Development
JASS 2006
Agile Project Management Scrum
44
Manifesto for Agile SD
• Based on the Manifesto for Agile Software
Development
–
–
–
–
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
Responding to change over following a plan
JASS 2006
Agile Project Management Scrum
45
Agile Methods
• Agile methods:
–
–
–
–
–
Scrum
Extreme Programming
Adaptive Software Development (ASD)
Dynamic System Development Method (DSDM)
…
• Agile Alliance
– A non-profit organization promotes agile development
JASS 2006
Agile Project Management Scrum
47
What is Scrum?
Definition from rugby football:
a scrum is a way to restart the game after an
interruption, where the forwards of each side come
together in a tight formation and struggle to gain
possession of the ball when it is tossed in among
them
JASS 2006
Agile Project Management Scrum
48
Scrum - an agile process
• SCRUM is an agile, lightweight process for managing and
controlling software and product development in rapidly changing
environments.
– Iterative, incremental process
– Team-based approach
– developing systems/ products with rapidly changing
requirements
– Controls the chaos of conflicting interest and needs
– Improve communication and maximize cooperation
– Protecting the team form disruptions and impediments
– A way to maximize productivity
JASS 2006
Agile Project Management Scrum
49
History of Scrum
•
1995:
– analysis of common software development processes  not suitable for
empirical, unpredictable and non-repeatable processes
– Design of a new method: Scrum by Jeff Sutherland & Ken Schwaber
– Enhancement of Scrum by Mike Beedle & combination of Scrum with
Extreme Programming
•
1996:
introduction of Scrum at OOPSLA conference
•
2001:
publication “Agile Software Development with Scrum” by
Ken Schwaber & Mike Beedle
 Successful appliance of Scrum in over 50 companies
Founders are members in the Agile Alliance
JASS 2006
Agile Project Management Scrum
50
Functionality of Scrum
JASS 2006
Agile Project Management Scrum
51
Components of Scrum
– Scrum Roles
– The Process
– Scrum Artifacts
JASS 2006
Agile Project Management Scrum
52
Scrum Master
• Represents management to the project
• Typically filled by a Project Manager or
Team Leader
• Responsible for enacting scrum values
and practices
• Main job is to remove impediments
JASS 2006
Agile Project Management Scrum
53
The Scrum Team
• Typically 5-10 people
• Cross-functional (QA, Programmers, UI
Designers, etc.)
• Members should be full-time
• Team is self-organizing
• Membership can change only between
sprints
JASS 2006
Agile Project Management Scrum
54
Product Owner
• Acts like one voice (in any case)
• Knows what needs to be build and in
what sequence this should be done
• Typically a product manager
JASS 2006
Agile Project Management Scrum
55
The Process
•
•
•
•
Sprint Planning Meeting
Sprint
Daily Scrum
Sprint Review Meeting
JASS 2006
Agile Project Management Scrum
56
Sprint Planning Meeting
• A collaborative meeting in the beginning of
each Sprint between the Product Owner,
the Scrum Master and the Team
• Takes 8 hours and consists of 2 parts
(“before lunch and after lunch”)
JASS 2006
Agile Project Management Scrum
57
Parts of Sprint Planning Meeting
• 1st Part:
– Creating Product Backlog
– Determining the Sprint Goal.
– Participants: Product Owner, Scrum Master,
Scrum Team
• 2nd Part:
– Participants: Scrum Master, Scrum Team
– Creating Sprint Backlog
JASS 2006
Agile Project Management Scrum
58
Pre-Project/Kickoff Meeting
• A special form of Sprint Planning Meeting
• Meeting before the begin of the Project
JASS 2006
Agile Project Management Scrum
59
Sprint
• A month-long iteration, during which is
incremented a product functionality
• NO outside influence can interference with
the Scrum team during the Sprint
• Each Sprint begins with the Daily Scrum
Meeting
JASS 2006
Agile Project Management Scrum
60
Daily Scrum
• Is a short (15 minutes long) meeting,
which is held every day before the Team
starts working
• Participants: Scrum Master (which is the
chairman), Scrum Team
• “Chickens” and “Pigs”
• Every Team member should answer on 3
questions
JASS 2006
Agile Project Management Scrum
61
Questions
• What did you do since the last Scrum?
• What are you doing until the next Scrum?
• What is stopping you getting on with the
work?
JASS 2006
Agile Project Management Scrum
62
Daily Scrum
• Is NOT a problem solving session
• Is NOT a way to collect information about
WHO is behind the schedule
• Is a meeting in which team members
make commitments to each other and to
the Scrum Master
• Is a good way for a Scrum Master to track
the progress of the Team
JASS 2006
Agile Project Management Scrum
63
Sprint Review Meeting
• Is held at the end of each Sprint
• Business functionality which was created
during the Sprint is demonstrated to the
Product Owner
• Informal, should not distract Team
members of doing their work
JASS 2006
Agile Project Management Scrum
64
Scrum Artifacts
• Product Backlog
• Sprint Backlog
• Burn down Charts
JASS 2006
Agile Project Management Scrum
65
Product Backlog
• Requirements for a system, expressed as a
prioritized list of Backlog Items
• Is managed and owned by a Product Owner
• Spreadsheet (typically)
• Usually is created during the Sprint Planning
Meeting
• Can be changed and re-prioritized before each PM
JASS 2006
Agile Project Management Scrum
66
Estimation of Product Backlog Items
• Establishes team’s velocity (how much Effort a
Team can handle in one Sprint)
• Determining units of complexity.
– Size-category (“T-Shirt size”)
– Story points
– Work days/work hours
• Methods of estimation:
– Expert Review
– Creating a Work Breakdown Structure (WBS)
JASS 2006
Agile Project Management Scrum
67
Product Backlog
• Is only a FORECAST!-> is not exact
JASS 2006
Agile Project Management Scrum
68
Sprint Backlog
• A subset of Product Backlog Items, which
define the work for a Sprint
• Is created ONLY by Team members
• Each Item has it’s own status
• Should be updated every day
JASS 2006
Agile Project Management Scrum
69
Sprint Backlog
• No more then 300 tasks in the list
• If a task requires more than 16 hours, it
should be broken down
• Team can add or subtract items from the
list. Product Owner is not allowed to do it
JASS 2006
Agile Project Management Scrum
70
Sprint Backlog
• Is a FORECAST!
• Is a good warning monitor
JASS 2006
Agile Project Management Scrum
71
Burn down Charts
• Are used to represent “work done”.
• Are wonderful Information Radiators
• 3 Types:
– Sprint Burn down Chart (progress of the
Sprint)
– Release Burn down Chart (progress of
release)
– Product Burn down chart (progress of the
Product)
JASS 2006
Agile Project Management Scrum
72
Information Radiator
• "Two characteristics are key to a good
information radiator. The first is that the
information changes over time. This
makes it worth a person's while to look at
the display... The other characteristic is
that it takes very little energy to view the
display."
JASS 2006
Agile Project Management Scrum
73
Burn down Charts
• X-Axis: time (usually in days)
• Y-Axis: remaining effort
JASS 2006
Agile Project Management Scrum
74
Sprint Burn down Chart
• Depicts the total Sprint Backlog hours
remaining per day
• Shows the estimated amount of time to
release
• Ideally should burn down to zero to the
end of the Sprint
• Actually is not a straight line
• Can bump UP
JASS 2006
Agile Project Management Scrum
75
Release Burn down Chart
•
•
•
•
Will the release be done on right time?
X-axis: sprints
Y-axis: amount of hours remaining
The estimated work remaining can also
burn up
JASS 2006
Agile Project Management Scrum
76
Alternative Release Burn down Chart
• Consists of bars (one for each sprint)
• Values on the Y-axis: positive AND
negative
• Is more informative then a simple chart
JASS 2006
Agile Project Management Scrum
77
Product Burn down Chart
• Is a “big picture” view of project’s progress
(all the releases)
JASS 2006
Agile Project Management Scrum
78
Scaling Scrum
• A typical Scrum team is 6-10 people
• Jeff Sutherland - up to over 800 people
• "Scrum of Scrums" or what called "MetaScrum“
• Frequency of meetings is based on the
degree of coupling between packets
JASS 2006
Agile Project Management Scrum
79
Scaling Scrum
JASS 2006
Agile Project Management Scrum
80
Scaling Scrum
JASS 2006
Agile Project Management Scrum
81
[email protected]
Scrum is an effective project management
wrapper for eXtreme Programming
development practices, which enables
agile projects to become scalable and
developed by distributed teams of
developers.
JASS 2006
Agile Project Management Scrum
82
Pro/Con
• Advantages
• Drawbacks
– Completely developed and
tested features in short
iterations
– Simplicity of the process
– Clearly defined rules
– Increasing productivity
– Self-organizing
– each team member carries a
lot of responsibility
– Improved communication
– Combination with Extreme
Programming
JASS 2006
– “Undisciplined hacking” (no
written documentation)
– Violation of responsibility
– Current mainly carried by the
inventors
Agile Project Management Scrum
83
Conclusion
• Thanks for you attention!
• Any questions?
JASS 2006
Agile Project Management Scrum
84
Cyreath.co.uk
Empirical Pragmatic Testing
An introduction to
SCRUM
Agile Project Management
Mark Crowther – Empirical Pragmatic Tester
[email protected]
Copyright ©Mark Crowther 2009
Cyreath.co.uk
Empirical Pragmatic Testing
About this slide pack.
This slide pack provides a brief overview of the SCRUM Agile Project
Management Methodology.
Contact Mark Crowther to learn how Testing within a SCRUM driven project
can be effectively achieved and how it can be utilised to help make your Agile
projects more successful.
Copyright notice
This document is copyright of Mark Crowther - © Mark Crowther 2009. The content and trademarks are the property of and copyright of their
respective owners. All rights reserved.
You may not, except with the express written permission of Mark Crowther make derivative works or commercially exploit the content or the
publication. Nor may you transmit it or store it in any website or other form of electronic retrieval system except as permitted by this copyright notice.
Any redistribution or reproduction of part or all of the content or publication in any form is prohibited other than the following:
you may print or download the complete document or extracts of the content to a local hard disk and you may transmit it to an individual third party for
personal and non-commercial use only; but only if you acknowledge Mark Crowther as the source of the publication and provide this copyright notice
intact.
For more information contact Mark Crowther.
Copyright ©Mark Crowther 2009
An introduction to SCRUM
Cyreath.co.uk
Empirical Pragmatic Testing
SCRUM is an
Agile Project Management Methodology
Characteristics of an ‘Agile’ methodology are:
• ADAPTIVE, not PREDICTIVE
• LIGHTWEIGHT, not HEAVYWEIGHT
• DESCRIPTIVE, not PRESCRIPTIVE
Copyright ©Mark Crowther 2009
An introduction to SCRUM
Cyreath.co.uk
Empirical Pragmatic Testing
SCRUM has the following ELEMENTS:
• A project team called a SCRUM Team
• A Product Backlog of all known Requirements
• A Sprint Backlog of requirements being worked on
• A period of work referred to as a Sprint
• Daily Stand-up Meetings with the SCRUM Team
• A Burndown Chart to track progress of the Sprint
• An Incremental Delivery at the end of each sprint
Copyright ©Mark Crowther 2009
Cyreath.co.uk
An introduction to SCRUM
Empirical Pragmatic Testing
A Model of SCRUM
Burndown Chart
Daily
SCRUM
Product Backlog
Sprint
Sprint Backlog
Incremental Delivery
2 - 4 Weeks
Copyright ©Mark Crowther 2009
An introduction to SCRUM
Cyreath.co.uk
Empirical Pragmatic Testing
The SCRUM Team
•
•
Is all the people who will COMMITTED to the
delivery of the backlogs
One role is ‘SCRUM Master’ who is in practice the
PM
•
Is staffed by PMs, BAs, Developers, Testers,
Support – i.e. ALL the typical project staff
Copyright ©Mark Crowther 2009
An introduction to SCRUM
Cyreath.co.uk
Empirical Pragmatic Testing
Product Backlog
Contains all the currently known requirements
for a product
•
•
Is managed by the Product Owner and can
change as needed
Copyright ©Mark Crowther 2009
An introduction to SCRUM
Cyreath.co.uk
Empirical Pragmatic Testing
Sprint Backlog
•
Contains the set of prioritised Product Backlog
items that are currently being worked on
•
Are not to be changed during the Sprint
Copyright ©Mark Crowther 2009
An introduction to SCRUM
Cyreath.co.uk
Empirical Pragmatic Testing
Sprint
• Is a fixed period of development and testing
• Results in an incremental delivery of usable
product
• Usually lasts 2 to 4 weeks
Copyright ©Mark Crowther 2009
An introduction to SCRUM
Cyreath.co.uk
Empirical Pragmatic Testing
Daily SCRUM Meeting
• Brief ‘Stand-up’ meeting each morning with
SCRUM Team only
• What value did you add yesterday?
•
•
What value will you add today?
What will stop you making progress?
Copyright ©Mark Crowther 2009
An introduction to SCRUM
Cyreath.co.uk
Empirical Pragmatic Testing
Burndown Chart
•
•
Charts delivery of the Sprint Backlog against
Sprint Duration.
Simple, at-a-glance view of progress showing
velocity and traction
• Easy to keep updated
Copyright ©Mark Crowther 2009
An introduction to SCRUM
Cyreath.co.uk
Empirical Pragmatic Testing
Incremental Delivery
• Output of the Sprint
• Working functionality that can be deployed
• Delivered every 2 to 4 weeks, tested and working
Copyright ©Mark Crowther 2009
An introduction to SCRUM
Cyreath.co.uk
Empirical Pragmatic Testing
What SCRUM isn’t
•
It isn’t a Development Methodology, SCRUM
doesn’t say how to write or manage the writing
of code.
•
•
It isn’t suitable for every project and every
organisation.
It isn’t a way to drop sound Project Management,
Development, Testing Practice, etc.
Copyright ©Mark Crowther 2009
Conclusion
• Thanks for you attention!
• Any questions?
JASS 2006
Agile Project Management Scrum
98
Agile Project Management
Presented by Carter Engelhart
– PMI-SVC I80 Roundtable Moderator.
– January 2007 Meeting
• Excerpts extracted from the book Managing
Agile Projects by Kevin Aguanno, PMP, MAPM
• ISBN 1-895186-11-0
• See www.mmpubs.com
• Paperback and PDF editions available.
• Endorsed by PMP’s as well as Staff of The
Project Management Institute (or PMI).
What is Agile?
• Agile is used to denote the ability of Agile
Methods to respond to changing
requirement in a controlled but flexible
manner
• Agile methodologies can equip
experienced Project Managers with new
tools to manage projects that are set in
environments of constant change.
Why do we need new Project
Management Methods?
• Information Technology (as well as other
industries) are continuously being challenged
by emerging technologies and requirements.
• Traditional Project Management “Best
Practices” suggest that we should lock down
requirements and setup a change control
system up front.
• Traditional Project Management practices
also tend to refer back to the original
requirements (and/or the contract) when
enforcing change control.
Traditional Project Management
Practices can Lead to….
• Chaos – Junior Project Managers tend
to either:
– allow too much uncontrolled changed to
take place (to ensure customer
satisfaction)
– or are too strict in allowing for change
(resulting in irate customers).
Traditional Project Management
Practices can Lead to….
• Dramatic Project Underperformance –
According to the Standish Group’s Chaos
Reports, only 16 percent of IT projects are
successful, the remainder are:
– Late.
– Over Budget.
– Deliver only a fraction of original scope in order to
meet budget restrictions.
– Cancelled.
What Is Different About Agile
Methods?
• They are all about managing the impact
of change on a project.
• They allow change to be introduced into a
project in a orderly way that that attempts
to maximize the benefits for the
sponsor.
• They control the risks that the change
introduces.
What is different about Agile
Methods?
• Iterative and Incremental development that
break down development into a number of
repeating cycles called Iterations
• Short iterations are used to keep the feedback
flowing (allowing for increased responsiveness
to change and reducing the risk of building the
wrong thing).
• Open, Flexible and Extensive design using
open standards whenever possible
What is different about Agile
Methods?
• Empowered Teams – Experienced specialists
are encouraged to work out the detail design on
their own.
• Personal Communication – Rather than relying
on written documentation to communicate
design decisions, technical approaches and
other typically documented items, agile method
suggest that the team work in the same physical
space (co-location). Use of white boards in the
work area is encouraged rather than lengthy
formal detail design documentation.
The Benefits of Being Agile
• Reducing Risk – The benefits from improved
control and improved communication lead to
reduced risks. Examples of risks include:
– Risk of building (or doing) the wrong thing. Did the
sponsor get what they asked for but not what they
actually wanted?
– Risk of building the right thing poorly. For
example, was the product poorly crafted. Was it
thoroughly tested as a part of each iteration? Is the
final produce extensible?
– Risk of being placed into an endless cycle of
design updates and reviews due to changing
requirements or high levels of complexity
The Benefits of Being Agile
• Relief from continual design revisions - Agile Methods are of the most benefit
when applied to projects where the
requirements are either unclear or
evolving
The Benefits of Being Agile
• Improved Control – Agile methods allow
the Project Manager to their control over
the project in high change environment.
Utilizing less rigid, yet structured agile
methodologies, control is through a
number of mechanisms.
The Benefits of Being Agile
(Improved Control)
• Frequent delivery of working code allows
progress to be objectively measured.
• Early and frequent stakeholder feedback allows
the Project Manager to redirect project priorities
when needed to ensure that real value is
delivered.
• Misunderstandings are cleared up early in the
project life-cycle.
• The sponsor is able to end the project earlier
than scheduled and still receive value.
The Benefits of Being Agile
(Improved Control)
• Short daily meetings allow team members to
share both successes and problems with each
other. Each team member should share:
– What they have just completed (so that team
members working on dependent tasks are notified).
– What are they going to work on next (allows other
team members to contribute information that may be
helpful to the task).
– Issues that are slowing down or halting their progress
(so that other team members and/or the Project
Manager can provide assistance).
Waterfall (traditional) way to
plan a software project.
•
•
•
•
•
•
Analyze the problem
Design the solution
Implement the code (Execution)
Test the code
Deploy the code.
Done
Agile method of planning a
software development project.
• Initial Analysis
• Initial Design (When problems are identified
they are pushed back into the analysis step,
to improve it).
• Initial coding, push back identified design
problems back. Perform another iteration of
design to improve it.
• Initial Testing. Identified problems are feed
back into another iteration of coding.
• Integration and deployment. Feedback any
problems you encounter into the process.
• A system of incremental/continuous
improvement.
Agile methods are all about
incremental progress
• Working incrementally allows the most critical
portions of the product to be delivered earlier.
• Working incrementally can help reduce risk
by receiving stakeholder feedback in
increments rather than at the end.
• Working incrementally allows project teams to
continuously make small corrections along
the way. Each incremental corrections
contributes to the overall quality of the entire
project.
Agile – Sweat Spots
•
•
•
•
•
Dedicated developers
Experienced developers
Small collocated teams
Automated Regression testing
Easy to access users.
Waterfall vs. Agile
• Money for information (waterfall)
• Money for flexibility (agile)
Agile Documentation
• A document is any artifact external to
source code whose purpose is to convey
information in a persistent manner.
Reasons to Create
Documentation
• Project stakeholders require it (a Business
decision with costs and benefits associated with
it)
• To define a contract model (to define how your
system and an external one interact with each
other). Typically required when an external
resource controls an IT resource your system
requires (e.g. DB, Application or IT service)
Reasons to Create
Documentation
• To support communication with an
external group (e.g. a non-co-located
group).
• If it will assist you in thinking
something through.
When is Documentation Agile
• Generally – when it is “Good Enough”, but no
more. This of course is subjective.
• When it maximizes stakeholder investment.
• When the documentation contains “just enough”
information to fulfill its purpose (and no more).
• Is purpose driven. If you are not clear about the
purpose you are creating the document, you
should not be doing so.
• When it contains information that is “Less Likely”
to change.
When is Documentation Agile
• When the documentation contains critical
information not readily available.
• When the documents have a specific
customer and facilitate the work efforts of
that customer.
• When the documents are sufficiently
indexed, accurate, consistent and detailed.
Relating PMBOK Practices to
Agile Practices
• Relating PMBOK Practices to Agile
Practices – Michele Sliger
– Part I
– Part II
– Part III
– Part IV
SECTZG652 : Agile Software Process
Session – 05, 06: Agile Roles and Processes,
Executing a Sprint
123
Introduction





Scrum Framework
Scrum Roles, Artifacts
Sprint in Scrum
Sprint Review
Sprint Retrospective
124
Scrum
Daily Scrum Meeting
• Done since last meeting
• Plan for today
• Obstacles?
Sprint Planning Meeting
•
Review Product Backlog
•
Estimate Sprint Backlog
•
Commit to 2-4 weeks of
work
daily
Sprint Review Meeting
• Demo features to all
• Retrospective on the
Sprint
Backlog tasks
expanded
by team
2-4 weeks
Sprint Retrospective
• What well well, What
went wrong, New ideas
Vision
Product Backlog:
• Prioritized Features
• desired by Customer
Sprint Backlog
• Features assigned to Sprint
• Estimated by team
Potentially Shippable
Product Increment
125
Scrum Roles, Artifacts
126
Product Owner
 Communicates a Product Vision
 Business Goals
 High Level Approach
 Owns Product Backlog
 Prioritizes the backlog (include all input for a product)
 Performs Release Planning
 Owns Release Planning and communicates release goals (Internal/External)
 Participates in Sprint Planning
 Present product backlog at sprint planning meeting
 Is available in the Sprint
 Attend daily standup meetings, available to team for questions
127
Product Backlog
 It exists over the life time of the project
 The Product backlog will contain a variety of items like




Features
Development requirements
Exploratory work
Known Issues
 Continuously updated by the Product Owner to reflect changes in the
needs of the customer, new ideas or insights, moves by the
competition, technical hurdles that appear
 The team provides the Product Owner with rough estimations of the
relative effort required for each item on the Product Backlog. Helps the
Product Owner make prioritization decisions
128
Product Backlog (contd.)
 Estimations are relative
 Items can be large but preferable to break them into smaller stories
 The Product Owner and team decides the level of details to which the
specification should be documented
 User Story
 A description of desired functionality told from the perspective of the user or
customer
 Story Points
 A relative size of a User Story. Has no UOM
 Ideal Days
 Effort needed to complete a story when it is the only thing you’ll work on, no
interruptions and every thing you need is available
129
Team
 7 people, + or -2
 Better to have dedicated resources
 Cannot change during a Sprint
 Can be distributed but better when co-located
 Cross functional, Self Organized and Self Managing
 Every team member that contributes is termed as Pigs in Scrum Vs
Chickens
 Team decides what to commit to and how to accomplish that
commitment
 The team can also provide input to the customer/Product owner on
how to make the product as good as it can be
130
Pigs and Chickens in Agile
Pigs are the scrum team members who are committed to the
Sprint/Scrum
Chickens are members who are involved but NOT committed to
the project
131
Scrum Master
 Serves the team
 The Scrum Master takes action to help remove impediments to the team’s
effectiveness
 The Scrum Master facilitates the team’s group interactions, to help the team
achieve its full potential

Protects the team
 The Scrum Master protects the team from anything that threatens its effectiveness,
such as outside interference or disruption
 The Scrum Master will need to confront uncomfortable issues, both inside and
outside the team

Guides the team’s use of Scrum
 The Scrum Master teaches Scrum to the team and organization
 The Scrum Master ensures that all standard Scrum rules and practices are followed
132
Sprint Backlog








Tasks to turn product backlog into working product functionality
Tasks are estimated in hours, usually 1-16
Tasks with more than 16 hours are broken down later
Team members sign up for tasks, they aren’t assigned (be patient, just
wait!)
Estimated work remaining is updated daily
Any team member can add, delete or change the Sprint Backlog
(theirs or new)
Work for the Sprint emerges
If work is unclear, define a Sprint Backlog with a larger amount of time,
break it down later.
 Update work remaining as more is known, as items are worked
133
Sprint Backlog (sample)
134
Sprint Burndown
 To create a burndown chart, each day the Scrum Master records the
estimated remaining work for the Sprint records it on a chart
 Start at day zero, the day of the Sprint planning meeting
 End at the day of the Sprint review
135
Sprint








Tasks to turn product backlog into working product functionality
Tasks are estimated in hours, usually 1-16
Tasks with more than 16 hours are broken down later
Team members sign up for tasks, they aren’t assigned (be patient, just
wait!)
Estimated work remaining is updated daily
Any team member can add, delete or change the Sprint Backlog
(theirs or new)
Work for the Sprint emerges
If work is unclear, define a Sprint Backlog with a larger amount of time,
break it down later.
 Update work remaining as more is known, as items are worked
136
Sprint
Sprints are not mini-waterfall projects
Rather, we do a little bit of everything all the time
137
Daily Scrum
 Daily – same place, same time, all
must attend
 Short , stand-up meeting for 15-mins
 All are welcome, but only "pigs" may speak
 Everyone reports 3 things only to each other
 What was I able to accomplish since last meeting
 What will I try to accomplish by next meeting
 What is blocking me
 Purpose – Share commitments, communicate status, identify
issues, set directions and focus, build the team
 Daily standup is for synchronizing between the team members,
not between Scrum Master and the team
 Some teams find it useful to have the Product Owners join and
give a brief daily report of their own activities to the team though
this is at the team’s discretion
138
Sprint Review
 Demo by the team of what the functionality
it has developed during the Sprint to the
Product Owner and “stakeholders” in the
project.
 Generate feedback, which the Product
Owner can incorporate in the Product
Backlog
 Attended by Team, Product Owner, Scrum
Master, functional managers and any
other stakeholders
139
Sprint Retrospective
 Accelerates visibility
 Accelerates action to improve
 It’s a key mechanism of continuous improvement
 A Good Approach
 What went well and therefore should be continued
 What didn’t go so well and therefore should be done differently next time
 What learning can the team apply to make improvements in the future
 The discussion can cover anything that affects how the team builds
software this might include: processes, practices, communication,
environment, artifacts and tools.

Process improvements are made at end of every Sprint - ensures that the
project team is always improving the way it works.

Attended only by the Delivery Team
140
References
1. Agile and Iterative Development A Manager’s Guide - Craig Larman/Pearson
Education - 2004. - Chapter 7, 8 and 9
2. Scrum Primer - Peter Deemer (Free download available)
3. Agile Project Management for Dummies - Mark C. Layton/John Wiley & Sons 2012 (Available in Books 24X7) – Chapter 6 and 9
141
SECTZG652 : Agile Software Process
Session – 07, 08: Agile Requirements and
Iteration Planning
142
Introduction
•
•
•
•
•
•
•
•
•
Introduction to User Stories
Prioritization techniques
Size Estimation
Introduction to Poker Estimation
Introduction to Velocity
Pre-requisite for Sprint Planning
Velocity based planning
Capacity based planning
Sprint Commitment
143
Agile Requirements
• Active user involvement is imperative
• Requirements emerge and evolve as software is
developed
• Agile requirements are ‘barely sufficient’
• Detailed enough for the team to work from, and further
details to be established and clarified at the time of
development
• Requirements are developed in small, bite-sized pieces
• Cooperation, collaboration and communication
between all team members is essential
144
User Stories
 A concise, written description of a piece of functionality that will be
valuable to a user (or owner) of the software.
 It generally has 3 parts



Card - A written description of the user story for planning purposes and as a
reminder
Conversation - A section for capturing further information about the user story and
details of any conversations
Confirmation - A section to convey what tests will be carried out to confirm the user
story is complete and working as expected
• User Stories should describe features that are of value to the user,
written in a user’s language.
• User Stories detail just enough information and no more.
• Details are deferred and captured through collaboration
just in time for development.
• User Stories need to be the right size for planning
145
User Stories
 User story should have the following INVEST features.






I – Independent
N – Negotiable
V – Valuable
E – Estimable
S – Small
T – Testable
146
User Story Desciption
As a [user role] I want to [goal] so I can [reason]
For example:
 As a registered user I want to log in so I can access subscriber-only
content
 Who (user role)
 What (goal)
 Why (reason)
 gives clarity as to why a feature is useful
 can influence how a feature should function
 can give you ideas for other useful features
that support the user's goals
147
MOSCOW Prioritization
 MoSCoW is a fairly simple way to sort features (or user stories) into
priority order – a way to help teams quickly understand the customer’s
view of what is essential for launch and what is not.
 MoSCoW stands for:
 Must deliver the item – the release is worthless to the user without it.
 Should deliver the item – but there is a short-term workaround. (Note: “Should” item
would be “Musts” if they were time-critical).
 Could deliver the item – if time is available.
 Will NOT deliver the item under any circumstances – but will consider it for future
releases.
148
Story Point Sizing
 Estimation is done in terms of Story Points
 All estimates are relative to other Stories in the backlog
 The team does the estimation themselves
Stories
Size
Enable users to search all Users
5
Enable users to create, update and delete users
8
Allow users to create, update and delete roles
8
Users should be able to map each user to a role
13
149
Poker Estimation
1. Everyone has cards: 1, 2, 3, 5, 8, 13, 21, 34
2. Scrum Master reads description of backlog item
3. Everyone selects and simultaneously shows cards
4. If estimates vary significantly, high and low estimators briefly explain
5. Repeat steps 3-5 until estimates stop converging
6. Decide estimate for backlog item
7. Move to next backlog item
 all standard Scrum rules and practices are followed
150
Velocity
 Planning in Scrum is based on Velocity
 Velocity is a measure of how much Product Backlog the team can
complete in a given amount of time
 Velocity can be calculated by
 Using historical data for this team
 Running an iteration
 Making a forecast
151
Backlog Prioritization
high
High risk
Low value
High risk
High value
(Avoid)
(Do first)
Low risk
Low value
Low risk
High value
(Do last)
(Do second)
Risk
Low
high
Value
152
Sprint Planning
Customers
Management
Meeting
Attendees
Meeting
Product Backlog
Meeting
Inputs
Outputs
Team Capabilities
Sprint Planning
Sprint Goal
Technology
Meeting
Sprint Backlog
Current Product
153
Sprint Planning
 More commitment as the team determines the estimates and make a
commitment by itself
 Sometimes it is acceptable to pull an item of lower priority as a gap
filler
 The team will know how much time is available with them for the sprint
related work
 Once the available effort is known team starts picking the tasks one by
one until estimates exceed available hours
 The selected tasks are noted down in a Sprint backlog - Task board or
excel
154
Sprint Planning
155
Sprint Commitment
 No changes once commitment is made
 No Changes to Deliverable
 Details will emerge during Sprint, but no new work or
substantially changed work
 Product Owner can terminate the Sprint if necessary
 No Changes to Sprint Duration
 Sprint ends on planned date whether team has completed its
commitment or not
 Product Owner can make any changes to the remaining Product
Backlog before the start of the next Sprint
156
References
1. Agile and Iterative Development A Manager’s Guide - Craig Larman/Pearson
Education - 2004. - Chapter 5, 8
2. Managing Agile Projects Kevin Aguanno / Multi-Media Publications 2004
(Available in Books 24X7) – Chapter 7, 11
157
SECTZG652 : Agile Software Process
Reinforcement Session – 01: Agile Introduction
“If you try to make the software foolproof,
they will just invent a better fool!”
Dorothy Graham
1
Introduction
 Refresher of concepts discussed

Traditional approaches

Traditional approaches vs. Agile

Benefits of Agile
 Case Study

“From Waterfall to Evolutionary Development and Test”
2
Traditional Model
Feasibility Study
User Requirements
Analysis
System Design
Detailed Design
Coding
Testing
Deploy and Maintain
3
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Traditional approaches - Objective
 In the face of changing requirements, traditional project management "best
practices" suggest that we try to

Lock down requirements to form a baseline

Implement change control and
 Fall back on the documented requirements or the contract as means to enforce the

change control.
All-at-once delivery
 Success of a project depends on ‘Triple Constraints’
 Ending the project within schedule

Finishing under budget

Completing entire scope
 Results of projects differed based on the choice
 Lenient and allowing too much change to the baseline without triggering the change
control processes (in the interest of customer satisfaction) - may go way over
budget and may be late due to additional features being added
 Too strict and refusing to accept changes to the baseline. Sometimes leads to irate
customers - may go over budget and may be late due to the extra work and delays
caused by assessing the changes to the baseline and the oft4en contentious
negotiations with the customers.
Waterfa l Model
5
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Waterfa l Model
 Pros

The model is straight forward

Very formal and disciplined model
 The model is rigid and each of the phases has certain deliverables and a review
process immediately after a particular phase is over
 Cons

Assumes everything is predictable at once

Expects all requirements to be captured upfront

Changes to requirements would be very expensive
 Bugs are expensive to fix and new requirements are expensive to incorporate.
Problems are not discovered until system testing

 It is not suited for long or complex projects or projects where the requirements can
change
 You do not see a working version of the software until late in the life cycle
6
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Spiral Model
1. In discussion with the customer, the requirements for the system are defined and
documented in as much detail as possible.
2. An initial design is created based on the requirements.
3. A sequence of increasingly complete prototypes are constructed from the design in
order to
- test the strengths and weaknesses of the prototypes, and to highlight any
risks;
- assist in refining the requirements by obtaining customer feedback; and
- assist in refining the planning and design.
4. The risks identified by testing the prototypes are reviewed with the customer, who
can make a decision whether to halt or continue the project.
5. Steps 2 through 4 are repeated until the customer is satisfied that the refined
prototype reflects the functionality of the desired system, and the final system is then
developed on this basis.
6. The completed system is thoroughly tested (including formal acceptance testing)
and delivered to the customer.
7. Where appropriate, ongoing maintenance and test are performed to prevent
potential failures and to maximize system availability.
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Spiral Model
BITS Pil ani, Deemed t o be Uni ver sit y under Secti on 3 of UGC Act, 1956
Need for Agile Development
 Client not sure how the end

product should look like

Need for having the best

features for better
marketability
Business is in
a
state of flux
Why
Agile?
Requirements are
evolutionary
Need for end user feedback
Unclear
Requirement
s
for delivering better
functionalities
 Shorter release cycles required


Identify and
follow
Optimal
Process
to
Rapid releases

get continuous feedback
optimal processes
Working software to reach
Improve
productivity
the customers faster
9
Agile Model
Leve Requirements
High Level
Analysis (Business
Requirements
Domain Model)
Key Features
High Level Architecture
H gh Leve Arch tecture
Analysis
Ana ys s
Release 1
•
Product
Backlog
Creation
(High Level
Feature Sets,
Prioritization)
Release Goal
•
Features
Identification
•
 Requ
emen s are
Requirements
unclear/con nuously evo
ving
unclear/continuously
evolving
•
Requirements
&
Architecture
Elaboration
Sprint Zero (Pre-Game Phase)
Sprint …N
Sprint 2
Sprint 1
•
Sprint Execution
Planning
Refine
Requirements &
Architecture
Design By Feature
Code By Feature
Test By Feature
Certify By Feature
(UAT)
Sprint Review and
Closure
10
•
Daily Standup
Meeting
Define
Def ne Program Roadmap
Release …N
Release 2
•


Unproven technology
echno ogy is
s used
Frequen
-pro ect
Frequent custome
customer-project
eam interaction
n e act on
team
 Usage
Usage
o Cu edge
ng edge
of Cutting
Release
Integration
System &
Performan
ce & User
Acceptanc
e Testing
•
Productio
n Rollout
Warranty
Support
Technology
architecture
Techno
ogy arch
ec ure &&
Initial
n a iterations
era ons may
may evolve
evo ve
architecture,
UI
frameworks
arch ecture U amewo ks
etc
ec
 Suited
Su ed for
o large
arge duration
dura on
projects;
pro ects;

Software
developed
 So
wa e is
s deve
oped in
n
numerous
releases
by
globally
nume ous re eases by g oba y
ddistributed
stribu ed teams
eams ;Release
Re ease to
o
production
can
combine
one
product on can comb ne one or
o
more iterations
more
e a ons
Benefits of Agile
 At a strategic level, Agile benefits include










Ongoing risk management: This is achieved by regularly confirming and adjusting requirements according to
ongoing interactions with the customer[17] and by delivering fully functional and fully tested software features
Ongoing control of budget expenditure: by providing decision makers with the opportunity to review and
assess the business value of deliverables at each iteration, and with the option to adjust, postpone or stop
ongoing funding based on the return on investment (ROI) of delivered work.
Rapid delivery of tangible outcomes: by focusing team efforts on regularly producing fully functional, fully
tested, production-ready software features that can be used by the organization well before the end of the
project timeline.
Strong alignment with business requirements: by directly involving the customer in the initial and ongoing
review of developed software, and by incorporating their feedback throughout the process.
Focus on the highest-priority features: by continually working with the customer to confirm and adjust the
work undertaken by the project team to align with the most current priorities of the organization.
Responsiveness to business change: by adjusting work throughout the process to incorporate
organizational, industry and technology changes.
Transparency in status tracking: by regularly providing tangible outputs for customer review, combined with
the use of open communication forums and centrally available real-time status-tracking tools.
Substantially higher-quality outputs: by incorporating rigid testing regimes throughout the process and by
working regularly with the customer to confirm the usability and business value of delivered features.
Greater employee retention: by creating work environments that are based on high communication,
empowering the team, trusting their expertise, encouraging innovation, and regularly acknowledging their
contribution to the organization[18].
Minimized whole-of-life software costs: by incorporating usability, quality and extensibility into solutions
throughout the delivery process – thereby reducing both development costs and 1s1upport and maintenance
overheads – and by providing a less risky and more cost-effective platform for additional functionality to be
integrated into the solutions.
Benefits of Agile
 Tactical benefits of Agile

The production of more valuable outputs per resource hour:

Earlier identification of technical issues

Less rework and “throw-away” work
 Reduced need to create – and maintain – detailed documentation

Greater flexibility

Greater opportunity for innovation

Reduced dependency on paper status reports

Reduced demand for ongoing support and maintenance
12
Traditional Vs Agile Development
Category

Visibility

Adaptability
Traditional Development
High Involvement of client during
through out the
Requirement elicitation
Little or no visibility until the
is ready
for UAT
 build
Define
detail requirement
in
testing
iteration advance
Agile Development

Active involvement of client
life cycle

Adapt requirement at each
 Quickly respond to business
and process
 Difficult to change requirement
changes due to longer delivery cycles


Business
Little or no Business value is
Deliver small usable
components through value
delivered until the system is
out the
iteration process
complete


Risk
Risk remains high until the
Identify issues earlier in
the process, system is delivered
eliminating risk in
the earlier cycle
13
Challenges




By only looking at small pieces (increments) of the software, we may have to
do massive rework, which might have been avoided if we analyzed or
designed the whole system correctly.
We might "paint ourselves into a corner;" that is, we can get a system that is
incapable of supporting some new requirement.
We may be unable to add global requirements, such as alternate language
support, performance, and security. A typical example is trying to retrofit
"security" to an application that was not designed with this requirement in
mind.
We might go slower because we have to restart analysis and design sessions
for each increment, instead of doing it once at the start of the project.
14
Corrective Maintenance
 While agile methods may not fit every project, they do provide valuable
benefits when applied against specific business problems

Reducing Risk

Building the Wrong Thing
 Building the Right Thing Wrong
 Getting Stuck in "Design Churn“

Improving Control

Frequent Delivery means Measurable Progress
 Feedback and Redirection means Delivering More Value

Early Feedback means Lower Cost of Change

End Early with Measurable Benefits

Improving Communications

Co-Located Teams

Short Daily Meetings

Close Customer (Sponsor) Involvement
15
EVERYONE IS DIFFERENT: AGILE CASE
STUDIES
“People think computers will keep them from
making mistakes. They’re wrong, with
computers you just make mistakes faster.”
-
Adam Osborne
CASE STUDY
“From Waterfall to Evolutionary
Development and Test”
Synopsis of case study






Evolutionary Development (Evo) focuses on early
delivery of high value to stakeholders and on
obtaining and utilizing stakeholder feedback.
Describes results rapidly achieved after migration
from waterfall to Evo
Major benefits of adopting an Evo approach:
Reducing the duration of the reqts phase from 5
weeks to a week
Paying greater attention to the quality
requirements vs. concentrating solely on the
required functionality
Resulting in a happier workforce, happier clients,
and more business
Background

Case study will focus on adoption and use
of Evo method in building a Conformit
product from an Oslo-based company
called Conformit AS.

Specifically focusses on the reduced
integration efforts as well as reduced devt.
timescales by using Evo as compared to
waterfall model
Background (Contd.)


Confirmit is a powerful web-based software package that enables organizations
to gather, analyze, and report on key business information across a broad range
of commercial applications.
A total staff of 20 members (including a QA team of 3 people) work in the
Confirmit AS R&D department

This team is responsible for developing the core Confirmit functionality and
developing custom bespoke modules for specific clients.

For initial versions, Confirmit AS had just a few clients, the development process
was fairly ad hoc and customer-driven. Changes to the software were made on
an almost daily basis, driven by client feedback. This delivered stakeholder value
quickly.

This process also resulted in numerous defects, long working hours, and poor
control of the software development and testing process. As the clients grew, they
were faced with the need to become more effective and efficient in its
development and testing.

This required a more formal process.
Background (Contd.)

Initially, Confirmit AS looked to adopt a waterfall approach and following the
Capability Maturity Model. After following a waterfall approach for a number of
years, a number of issues were identified:

Risk discovery and mitigation was delayed until the later stages of the project.

Document-based verification was postponed until the later stages of the
project.

There was dissatisfaction with the need to stipulate unstable requirements too
early; requirements change is perceived as a bad thing in waterfall.

Operational problems were discovered far too late in the process (typically at
acceptance testing).

There were lengthy modification cycles and too much rework and retesting.

Most important, the requirements were nearly all focused on functionality, not
on the quality attributes of the system.
Key goals of new process

Reducing the integration effort – that is, the amount of effort
for each developer to get the latest build to work on his or her
workstation so that they were able to code against the latest
code platform

Reducing the time in minutes to upgrade – from a previous
code platform to the most recent code platform from 3 hours
to a goal of 2 minutes;

Improving the reliability of builds – which historically had been
an area where there had been significant quality issues.
Realization dawned that “It is THE product quality
requirements that provide Confirmit with a competitive
advantage over its rivals.”
Evo 10 Key process Principles
1. Real results, of value to real stakeholders, will be delivered
early and frequently.
2. The next Evo delivery step must be the one that delivers
the most stakeholder value possible at that time.
3. Evo steps deliver the specified requirements, evolutionarily.
4. It is impossible to know all the right requirements in
advance, but it is possible to discover them more quickly by
attempts to deliver real value to real stakeholders.
5. Evo is holistic systems engineering; all necessary aspects
of the system must be complete and correct, and delivered to
a real stakeholder environment. It is not only about
programming, it is about customer satisfaction.
Evo 10 Key process Principles
6. Evo projects will require an open architecture, because project ideas will
change as often as needed to really deliver value to the stakeholders.
7. The Evo project team focuses their energy, as a team, toward success in
the current Evo step. They succeed or fail in the current step together. They
do not waste energy on downstream steps until they have mastered current
steps successfully.
8. Evo is about learning from hard experience, as fast as possible – what
really works and what really delivers value. Evo is a discipline to make
teams confront project problems early, but one that delivers progress quickly
when provably the team have got it right.
9. Evo leads to early, and on-time, product delivery – both because of
selected early priority delivery and because the team learns to get things
right early.
10. Evo should allow teams to validate new work processes and get rid of
bad ones early.
Evo: New Reqts standard

Requirements had to be :

be clear and unambiguous,

be testable,

be quantified,

not involve solutions, and

have a stakeholder focus.

Focus on day-to-day operations of users

Following this process, all reqts of new release
was designed and documented in 1 week.
Eco: Cycle time of 1 week

Week-day wise template plan for project
activities was worked out.

This plan had individual roles and
responsibilities clearly identified and
targeted.
Week day activities

On the Friday:

(PM) delivers the detailed plan for the next week’s version of the
software (let’s call it Version N) to the customer (CTO) prior to
attending a weekly PM meeting.

CTO reviews and approves or rejects the design and records
their comments.

PM and CTO attend the weekly PM meeting to discuss the
Version N detailed plan and review CTO comments.

Developers focus on general maintenance and documentation
tasks.

QA team runs final build and setup for that week’s developed
version (let’s call it Version N-1), installs setup on test servers,
and performs initial crash test 1 of Version N-1 prior to its release.
Week day activities

On the Monday:

The developers first generate the tests required to
validate Version N and then begin development of the
code.

QA team reviews the results of the continuous
integration (CI) process and reviews test plans and
tests for Version N.

Users begin to use Version N-1 and compile feedback
for the developers.
Week day activities

During Tuesday and Wednesday:

The developers continue to generate the tests
required to validate Version N and develop the
associated code.

The developers meet with the users to discuss the
feedback from using Version N-1.

Incorporating the feedback from the users, the
developers continue to generate the tests required to
validate Version N and develop the associated code.

QA team reviews the results of the CI process and
reviews test plans and tests for Version N.
Week day activities

On the Thursday:

The developers complete the final tests for
Version N, code, and execute the tests. The
developers also complete the graphical user
interface tests for the previous week’s version of
the software (let’s call this Version N-2).

The QA team reviews the results of the CI
process and reviews test plans and tests for
Version N.
Benefits of Evo adoption

Resulted in increased motivation and enthusiasm
among the developers and testers

developers reported that they are empowered and feel they have
the scope for greater creativity

Roll-out and adoption of Evo was relatively painless

Paradigm shift with respect to the requirements
process


Previously focussed on functional requirements but now on product
quality requirements
Testing was made mandatory thereby raising the
quality standards of the deliverable
Lessons learnt

The adoption of a weekly development, test, and delivery
cycle has been very beneficial – All stakeholders could
easily see value

As with the introduction and use of any new, nontrivial
technology, it is key to ensure adequate training,
mentoring, and consultancy

Approach to CI has been refined, the CI process has
proven to be successful and we intend to continue to use
it for the foreseeable future
There is always another lesson to be learned – the goal of
fine-tuning our processes continues today, and will
continue into the future.

Thank you
Questions?
SECTZG652 : Agile Software Process
Reinforcement Session – 03:
Testing of a system
that is WIP
1
Introduction
 Agenda

Case Study

Experiential learning – Cause – Effect relationships for arriving at
Project Risks
2
Case Study
In a fast-moving environment where requirements are changing all the time, in
order to support the customer’s needs, the testing strategy has to be superagile.
Questions to be answered:
How do you keep the relevant documentation up to date?
How do you communicate the changes to your team?
How do you ensure your testing covers the changes?
How can you guarantee that you deliver a system that works and meets the
customer’s needs?
3
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Case Study: Synopsis
This case study reviews the issues that are being faced
by a large, multiyear project practicing incremental
delivery, and shows how the team has used agile
techniques to address these issues. In particular we will
look at how using techniques such as daily builds,
pairing testers and developers through an iteration, and
the use of automated testing tools for regression testing
have enabled the team to successfully test and deliver a
new,ONLY
high-quality
release
every has
six weeks!
ONE AND
SOLUTION:
Testing
to be
superagile!!!
4
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Background of team
A team enhancing a large business critical information
system that needs to be updated every six weeks to
keep pace with an ever-changing variety of information
sources and analytical needs.
Traditional test approaches are not suitable in this kind
of situation; the test strategy must be agile for the
project to survive.
5
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Challenges faced
As team worked to develop and test the software, we
needed to meet the challenges of:
a) Keeping the relevant documentation up to date,
b) Communicating the frequent changes to all
members of the team
c) Ensuring that the changes are thoroughly tested,
d) Ensuring that the changes don’t compromise or
break the existing system, and
e) Delivering a system that works and meets the
customer needs every six weeks.
6
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Solutions to challenges faced
Solutions that were explored to address those issues:
a) Developing the test cases alongside the
requirements,
b) Pairing testers and developers through an iteration,
c) Ensuring that all the documentation was updated as
we
went along,
d) Relaying information to the team by means of a
daily Scrum, and
e) Employing automated testing tools to assist with the
testing load
7
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Background to the Project work
a) Project was first initiated in 1997
b) Involves the development of systems to provide key
information to government departments on demand.
c) As information sources are enhanced or new
sources identified, the systems need to be quickly
updated.
d) No end date to this project, as it is inevitable that
changes and new reqts will continue to be added future.
e) Systems are truly “business critical,” requiring very
high quality, reliability, and availability.
f) Essential updates must be implemented quickly,
must be delivered on time, must be defect free, and
should not regress the existing functionality.
8
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Background to the Project work
a)Project runs on a rolling three-year cycle, with major
reviews carried out at the end of each period. These
result in changes to the personnel involved in the project
and the underlying customer needs.
b)This is a large agile project, with some thirty staff,
including customer representatives. Team changes
regularly, with no one staying on the team for any great
length of time, other than a core of 5 people.
c)It is critical to project success that the productivity and
quality are not harmed as a result of the high turnover.
d)Continuously integrating new team members into the
team is a major challenge; consequently, a great deal of
attention has to be paid to keeping documentation up to
Background to the Project work
a) The project is run as a series of six-week iterations,
with each iteration delivering production-quality code
into the live environment.
b) As a result of this rapid development cycle and the
need to deliver high-quality reliable code into the live
environment, testing is absolutely critical to the success
of each iteration, as well s that of the overall project.
c) The need to ensure that the code implemented in
the current iterations meets the customer requirements
and is reliable, while ensuring that the changes do not
regress existing code base, means that testing must be
continuous, comprehensive, effective, and efficient.
10
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Background to the Project work
a)Project runs on a rolling three-year cycle, with major
reviews carried out at the end of each period. These
result in changes to the personnel involved in the project
and the underlying customer needs.
b)This is a large agile project, with some thirty staff,
including customer representatives. Team changes
regularly, with no one staying on the team for any great
length of time, other than a core of 5 people.
c)It is critical to project success that the productivity and
quality are not harmed as a result of the high turnover.
d)Continuously integrating new team members into the
team is a major challenge; consequently, a great deal of
attention has to be paid to keeping documentation up to
Definition of an Agile Testing Process
There were two aspects to the successful delivery of
the system:
1. Needed to assemble the core of a great team that
had the experience and talent to work using the new
agile techniques. This core of five people needed to
transfer knowledge to new team members as they
moved in and out of the project.
2. Needed a lightweight and practical process to help
us deliver on time, to budget, and to acceptable quality.
12
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Customized Agile Testing Process
Decided to adopt a smaller number of agile practices taken from
the Essential Unified Process
EUP is available at:
http://www.ivarjacobson.com/uploadedFiles/Pages/Knowledge_Ce
ntre/Resources/White_Paper/Resources/paper_essup_first_look.
pdf
The concepts within this process are delivered using cards – this
means that minimal information is referenced when it is needed.
The beauty of the EUP is that it adopts a practice-based
approach, where the practices underlying the process are defined
separately in a way that allows you to select just the ones that will
benefit your project.
13
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Customized Agile Testing Process
The practice approach is a 'Lightweight' approach:
Lightweight: Using small parts of the process to add value where
and when needed.
Followed the practice for improving communications and
introduced daily Scrums.
Scrum allowed us to minimize the amount of documentation we
produced
Combining smart communication with fit-for-purpose levels of
documentation turned out to be very important in supporting the
testing effort needed to ensure high-quality and reliable delivery.
Communication through simply talking has proven invaluable in
ensuring that all stakeholders are headed in the same direction.
14
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Customized Agile Testing Process
Decided to adopt a smaller number of agile practices
taken from the Essential Unified Process
EUP is available at:
http://www.ivarjacobson.com/uploadedFiles/Pages/Kn
owledge_Centre/Resources/White_Paper/Resources/pap
er_essup_first_look.pdf
The concepts within this process are delivered using
cards – this means that minimal information is
referenced when it is needed.
The beauty of the EUP is that it adopts a practicebased approach, where the practices underly15ing the
process are defined separate
BITlSyPilian
i, Da
eemw
ed ta
o by
e Untih
vera
sitytuna
delrlSo
ecw
tions
3 ofy
Uo
GCu
Act,
Customized Agile testing process
Process encouraged the involvement of the test resources throughout the project
Testers were involved in working with the customers alongside the analysts,
producing the test cases at the same time as the use cases were getting built.
This test-driven approach provided significant improvements in productivity and
accuracy compared with traditional methods.
Ensured that the requirements, both functional and nonfunctional, have a test built
alongside them during their development.
Establishing traceability between the requirements, tests, and components provides
the minimal level of documentation that is needed and adds value.When frequent
personnel changes were there, it was very useful.
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Customized Agile testing process
Took the approach that the customer representative was an essential part of the
team and mandated that customer representatives be involved in the software
development from day one.
Followed the assumption that “the customer will only know what they want when they
see it,” and through having them on hand at all times we could make sure that we
were building and testing the right thing.
Agile principle of promoting good and regular communication works very well with
the customer and cuts down the amount of time spent on clarifying or confirming
issues.
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Results of customized Agile testing
process
project continues to deliver successfully
reputation of the project has excelled
other projects within the same organization are now looking to reuse the approach
developed in order to improve their productivity and delivery records.
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Lessons Learnt
User requirements and test cases – you need them both up front.
As the use cases are constructed, a test resource is on hand to identify the test
cases that will be needed to cover functional and nonfunctional issues, quality, and
integration.
This provided us with accurate requirements and the details of the testing
needed to ensure that the requirements were met.
Pair developers and testers
This was not perfect owing to politics of developer vs. tester as a policeman
Subsequently, refined this approach so that the tester was involved in reviewing
what had been delivered at the end of each day, so that this could be incorporated
into the next day’s testing.
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Lessons Learnt
Every day is test day
The phrase ““we can cut back on testing to meet the deadline!” was thrown out
of the window
If something is to be delivered, then it is the testers who make the final decision
as to whether or not that something is delivered into the live environment.
In addition to daily builds and their associated tests, test cases are implemented during an iteration as the code is being developed.
Each and every day in our iterations is a day that the testers will work with
the team, with one common goal – successful delivery.
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Lessons Learnt
Automated testing of daily builds
The use of automated testing tools for regres sion testing has saved the project
significant amounts of time, effort, and cost, and has helped to ensure that the quality
of the deliverable is maintained.
The goal is to run automated tests every night, with any issues highlighted
the following morning.
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Lessons Learnt
Role and use of Scrums
One of the benefits of holding daily Scrums has been in promoting effective
testing as the key to the delivery of higher-quality code.
Scrums have also been instrumental in ensuring that testers, analysts,
developers, and customer representatives are all working together as a team toward
the same goal.
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Conclusions of this case study
Overall, the importance of testing within a project that has to deliver high-quality
code cannot be underestimated.
Within this project, testing was given a great deal of emphasis and, specifically,
testing was:
introduced into the process as early as possible
present everywhere within the practices
employed throughout each iteration,
the central cog of the development process
supported by the use of automated testing tools

“With agile practices and a good team, successful delivery becomes the norm.”
[Source: Anonymous]
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Experiential learning
24
Cause – Effects relationship
Cause – Effects relationship is used to identify project risks and understand
techniques to be used for process adherence
Class to be split into different groups
Each group lists down point by point all facts that can relate to an Enterprise
Software
Scope includes Cost, Time, Man-power, SW maintenance, Support etc.
Facts are grouped together in such a way that the fact on left causes the fact
mentioned on right
Example follows in the next slide.....
25
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Approach (Contd.)
The facts written could be:
Enterprise software has a lot of features
Enterprsie software is complex
Enterprise software is expensive
Enterprise software implementations can have bugs
Enterprise software takes time to deliver
Time is money
Enterprise software features need manpower to implement them
Bugs take time to fix
It takes time to co-ordinate the efforts of the develo2p6ers
B ITS P ila ni, De e med to be University under Section 3 of UGC Act,
Example Cause - Effect
27
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Likewise.....
Do for IRCTC Online reservation
system enterprise Software
28
BITS Pilani, Deemed to be University under Section 3 of UGC Act, 1956
Thanks
29
Managing Agile Projects, First Edition
by Kevin Aguanno (ed)
Multi-Media Publications Inc.. (c) 2004. Copying Prohibited.
Reprinted for Jayalakshmi L, Cognizant Technology Solutions
[email protected]
Reprinted with permission as a subscription benefit of Skillport,
http://skillport.books24x7.com/
All rights reserved. Reproduction and/or distribution in whole or in part in electronic,paper or
other forms without written permission is prohibited.
Managing Agile Projects, First Edition
Chapter 1: Introduction
Kevin Aguanno
Overview
Extreme Programming, [1] Scrum, [2] Feature-Driven Development, [3] Lean Development, [4] Crystal Methods, [5] Agile Project Management: [15] these are just a few of the
more common examples from a group of new product-development methods that have emerged over the past decade. While they were once relegated to back alley
discussions between product development teams, they have emerged to become topics of mainstream discussion, appearing as topics in conferences and academic
journals. Where did these "new" methods come from? What do they offer that is different from traditional methods? Is there anything really new in these methods? And do
we need
new
techniques
new methods?
Proponents have come together
under
theproject
bannermanagement
of Agile Methods
in ordertotomanage
supportthese
the further
development and promotion of these
methods. The term agile was selected by these proponents at an initial meeting [6] in order to denote the ability of these methods to respond to changing requirements in a
controlled but flexible manner. The runner-up moniker, Lightweight Methods, did not highlight the applicability of these methods to projects experiencing high levels of
change, and also carried the negative connotations of the term lightweight — these are serious methods and deserve consideration.
The concepts of agile product development first emerged among Japanese automobile manufacturers in the 1980s. [7] These concepts quickly spread to North American
car manufacturers and then their IT departments in the late 1980s. Once these ideas worked their way into the IT community, they quickly spread to other organizations and
industries through exposure in software development conferences and journals. Naturally, several different approaches, or methods, evolved that incorporated these new
product development ideas into a software engineering and development context.
While they first emerged as software development methods, these methods have been adopted more broadly. Scrum, for example, has been used as a general project
management approach in non-software projects, [8] and agile techniques have been customized into methods for other industries, such as Lean Construction. [9] While the
principles described in this book are generally applicable to most new product development scenarios, the discussions and examples are mostly from the software
development world, where most of the research and work on agile methods is taking place.
[1]Beck, Kent. Extreme Programming Explained: Embracing Change. Boston: Addison Wesley, 1999.
[2]Schwaber, Ken and Beedle, Mike. Agile Software Development with Scrum. Upper Saddle River, NJ: Prentice Hall, 2002.
[3]Palmer, Steven. "Feature-Driven Development." Borland Developer Network Web site.
<http://bdn.borland.com/article/borcon/files/2136/paper/ 2136.html>.
[4]Poppendieck, Mary and Poppendieck, Tom. Lean Software Development: An Agile Toolkit for Software Development Managers. Boston: Addison Wesley, 2003.
[5]Cockburn, Alistair. "Crystal Light Methods." Available at <http://alistair.cockburn.us/crystal/articles/clm/crystallightmethods. htm>.
[15]Highsmith, Jim. Agile Project Management. Boston: Addison Wesley, 2004.
[6]Highsmith, Jim. "History: The Agile Manifesto." Agile Alliance Web site, 2001. < http://www.agilemanifesto.org/history.html>.
[7]Aguanno, Kevin. "Ever-Changing Requirements: Use Agile Methods to Reduce Project Risk." Proc. Informatics 2004. Canadian Information
Processing Society (CIPS). May 2004.
[8]Aguanno, Kevin. "Manage Change Better With Scrum." Inside Project Management. 2.8 (2002) 1–6.
[9]The Lean Construction Institute Web site is available at <http://www.leanconstruction.org/>.
Why do we Need New Methods?
1.
2.
In
the down
face ofrequirements
changing requirements,
traditional project management "best practices" suggest that we try to
Lock
to form a baseline,
Implement change control, and
3.
Fall back on the documented requirements or the contract as means to enforce the change control.
Lock Down Requirements.
Page 2 / 13
Reprinted for CTS/316124, Cognizant Technology Solutions
MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited
Managing Agile Projects, First Edition
The purpose behind this technique is to document the requirements as of a single point in time and then get those requirements
"approved" (signed off by the sponsor) to provide a baseline against which further changes can be measured. Having such a baseline allows the impact of new changes to
be assessed and a set of metrics (usually budget and timeline) that are used as negotiating points for accepting the changes.
Implement Change Control.
Once the baseline is in place, any scope discussions can refer back to the baseline to see if features are covered under the existing scope or form new requirements. New
requirements will require an impact analysis that estimates the effect of the changed requirements to the budget, timeline, risk, etc. of the project. For changes to be
accepted by the project team, and for the baseline to be updated to reflect the newly approved scope, the project sponsor signs a change authorization document that grants
the formal approval to update the approved budget, timeline, and scope baselines. In many environments, this includes changing signed contracts.
Fall
Back on
thebeDocumented
As discussed above, whenever there is a question about whether
a feature
is to
implemented Baseline.
by the project team, the team can refer back to the documented baseline.
Any difference will have to be handled through the change control process. Often disputes erupt about whether a feature is new, or just a "clarification" to an existing feature
that is already part of the baseline. In most projects, the baseline is never 100% clear, and negotiations are needed to resolve different interpretations of the baseline.
While these methods may appear to work in theory, in practice they lead to chaos and dramatic project underperformance. "Junior" project managers — those without a lot
of real-world experience — will usually err by being either too lenient, and allowing too much change to the baseline without triggering the change control processes (in the
interest of customer satisfaction), or err by being too strict, and refusing to accept changes to the baseline. Sometimes the latter approach leads to irate customers as they
are told that changes will be deferred until the next release of the product to avoid delays to the release of the initial project scope baseline. Either approach can lead to
project underperformance. In the first case, projects may go way over budget and may be late due to additional features being added in a haphazard way by the project team
in response
changing
customer
whims. In the
second
case,[10]
projects
may that
go over
budget and16
may
be late
the extra
work
and delays
assessing
the
The
StandishtoGroup,
in their
ground-breaking
Chaos
Reports
first noted
approximately
percent
of due
all ITtoprojects
are
successful.
Thecaused
rest arebyeither
late, over
changes
the baseline
andto
the
often
contentious
negotiations
with the
customers.
budget, deliver only a fraction of their original
scopetobaseline
in order
meet
their
time or budget
restrictions,
or are
cancelled altogether. Many in the IT industry were
initially shocked by these results, but soon realized the truth behind them. IT projects,
especially software development projects, are different from more traditional projects in that they are new product development projects with a number of unusual
n At the early design stages, the intangible nature of most software leadscharacteristics:
to difficulties in communicating design and vision in an easily- understandable way.
n
n
n
Progress is often hard to assess, given the intangible nature of the deliverables.
They are usually trying to create unique products with few available analogs for comparison.
The tools for building software (programming languages) are constantly changing, often mid-way through the project.
n The industry standards that the software must support are constantly changing.
n The building blocks (computer hardware, operating systems) are constantly changing.
When dealing with all of this uncertainty, of course there is going to be a high level of change during a project.
Now add to this a reality of today's business world: with a global economy and the faster pace of today's business (working in Internet time), no set of requirements will stay
the same for very long. A competitor comes out with a new product. Government legislation changes. Your company is bought out by another one with a different strategy.
An organizational restructuring results in you having a new boss who wants to make a mark and who wants to redirect your priorities. Many different forces of change are at
work in our world,
we cannot control these sources of change. The concept of change control is a misnomer: we cannot "control" these factors, nor can we control the
[10]Theand
Standish Group. The CHAOS Report. 1994. <http://www.standishgroup.com/sample_research/chaos_1994_ 1.php>.
changes that they generate. What we can do, however, is manage how we adapt to these changes.
What is Different about Agile Methods?
Agile methods, at their core, are all about managing the impact of change on a project. When change occurs, these methods provide ways of allowing that change to be
introduced to the project in an orderly way that attempts to maximize the benefits for the sponsor, while controlling the risks that the change introduces.
In traditional product development lifecycles, such as the Waterfall Method, [11], [12] there is a design developed, then the product is developed according to that design, then
the product is tested to determine how well it adhered to the design. Design changes introduced during the development or testing portions of the project cause chaos, in that
they require the project to stop dead in its tracks and cycle back to the beginning design phase. If these changes occur late in the project, the resulting delays and increased
costs can skyrocket. (See Figure 1-1.)
Page 3 / 13
Reprinted for CTS/316124, Cognizant Technology Solutions
MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited
Managing Agile Projects, First Edition
Figure 1-1: Boehm's cost of change curve [13] shows the exponentially higher cost of making changes late in a project.
Agile methods share some common characteristics that allow them to respond better to change. These characteristics are discussed at greater length throughout
this book.
Iterative and Incremental Development.
Agile methods break down the development of their new products into a number of repeating cycles called iterations. Each iteration builds upon the last, adding additional
layers of functionality. This allows the product to grow much in the same way that an onion or a pearl grows by adding layers. Starting from an initial kernel of functionality,
over time (and several iterations) the product becomes more and more complete. This provides delivery of some functionality early in the project, and then regularly
throughout the remainder of the project.
By using short iterations, agile methods keep the feedback cycle short, allowing
responsiveness to change, and reducing the risk of building "the wrong thing"
Shortmore
Iterations.
based on unclear or changing requirements.
Progress
Viaelements
Completed
Features.
Rather than trying to track progress by measuring percent
completeMeasured
on intangible
such
as design, agile methods track progress by fully-completed and tested
features. Progress is measured by the percent of features that are complete and ready for the sponsor to review or deploy. This avoids the Vaporware Syndrome, where
functionality is "mocked up" (faked) or features are not properly developed in order to meet a timeline or budget constraint. Then, when a sponsor seeks to deploy the
product, the truth is revealed — that a lot of additional work is still required to "finish the job."
Open, Flexible Design.
Designs are flexible and extensible using open standards wherever possible. Since the full set of requirements may be unclear at the beginning of the project, and will likely
change anyway, prepare a flexible, extensible design that will allow you to add on features to support new requirements as they emerge. There is always the risk of some
rework to incorporate complex requirements, but often the impact is offset by the other benefits gained by using agile methods.
Empowered Teams.
Teams of specialists who know their jobs well and have the experience (and maturity) to decide for themselves how best to approach the problems at hand. Instead of
imposing a design on the team, let the people who know best how to implement the details decide how they are going to do the work. This often allows for more flexibility in
a system than is usually found in a more traditional, centralized design.
Personal Communications.
Rather than focus on producing written documents to communicate design decisions, technical approaches, and other normally-documented items, agile methods suggest
that teams work in shared physical environments. Speaking face to face, perhaps with the support of a whiteboard for drawing diagrams, is a much more efficient way of
working out design details. It is easier to update a design on a whiteboard, a design that is shared in the minds of a room full of people, than to update hundreds (or
thousands) of pages of design documents. As we will see later in this chapter, many large projects have failed because of the reliance on written documentation to
communicate design. While written documentation has its place on agile projects (as discussed in Chapter 9) teams need to seek opportunities to discuss approaches
verbally to capture nuances not reflected always in documents, and to provide a fast way of asking (and answering) questions to ensure comprehension.
Page 4 / 13
Reprinted for CTS/316124, Cognizant Technology Solutions
MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited
Managing Agile Projects, First Edition
Using these common characteristics, the creators of the various agile methods have produced a variety of approaches, each emphasizing different aspects. No single
agile method is "better" than the rest — they all have their strengths and weaknesses — yet employing them can often lead to some significant benefits for the sponsor
and for the project team.
[11]Royce, W.W. "Managing the Development of Large Software Systems: Concepts and Techniquees." Proc. WESCON. (1970) 1–9.
[12]Aguanno, Kevin. "The Waterfall Development Method." Inside Project Management. 2.8 (2002).
[13]Boehm, Barry. Software Engineering Economics. Upper Saddle River, NJ: Prentice Hall, 1981.
What are the Benefits of Being Agile?
While agile methods may not fit every project, they do provide valuable benefits when applied against specific business problems. Consider each of these benefits when
evaluating whether a particular agile technique may be of use on your own project, as each technique puts a different emphasis on the different benefits.
There are three main types of benefits from agile techniques: reducing risk, improving control, and improving communications. Each of these benefits has a number of
aspectsReducing
that are detailed
Risk below.
Of all three benefit types, reducing risk is perhaps the most significant. The benefits from improved control and improved communications largely lead to reduced risks
themselves,
sodifferent
we should
put extra
on will
discussing
the use
of agile
techniques
forbuilding
the reduction
of risk.
While risks may be categorized
in many
ways,
in thisemphasis
chapter we
look at three
specific
risks:
the risk of
(or doing)
the wrong "thing;" the risk of
building the right thing, but poorly; and the risk of being stuck in an endless cycle of design updates and reviews due to changing requirements or high levels of complexity.
There are other risk-reduction benefits, but these are the three that I have found to be easier to sell to your project sponsors and team members, as they help avoid
concrete, measurable impacts when these risks are left uncontrolled.
Building the Wrong Thing
As one of my primary specialties, I spend a lot of time reviewing (and correcting) troubled software development and systems integration projects. When I first come onto
these projects, I interview all the main project stakeholders. Of course, one of my first stops is the desk of the sponsor. Something that I have heard repeatedly from
sponsors of troubled projects is a variation of the phrase "They gave me what I may have asked for, but that was not what I meant." This is an indication of a serious
disconnect in expectations that can be improved with better communications.
There is nothing better on a project than having actively-involved stakeholders who work closely with the project team reviewing the work in progress, answering questions
as they arise and providing immediate feedback. Imagine managing one of these projects — you would never be concerned about acceptance of the final deliverables,
since the approvers were providing you their feedback throughout the project, ensuring that what you created was aligned with their expectations. Agile techniques realize
that documentation is a poor means of communications. Writing down requirements may help some people better understand the "thing" they desire, but you need to
Some people are visual learners. No matter how detailed (and thick!) a requirements document becomes, these people will not be able to relate the document to their
supplement the written documents with many discussions and joint design reviews to ensure that you capture the nuances that sometimes cannot be put onto paper.
mental vision for the product. In fact, I have personally seen one project sponsor hold a two-inch-thick binder filled with detailed technical specifications, shake it up and
down a couple of times in her hand, and comment that since the document is so
obviously thick and heavy, that it must be correct. She signed off on the document without even opening up the binder! For people like this, creating more and more detailed
specifications
is not
going
to solve the
problem.
Even
they do
attempt
to read
the document,Intheir
eyes are going
to glazea over
the first fewofpages,
and of
they
will drift
Agile methods
adapt
a technique
borrowed
from
theifmovie
industry
called
"storyboarding."
storyboarding,
you create
visualafter
representation
the "flow"
a movie,
to are
sleep.
Youthinkers
need a will
different
approach. other than the written script to which they can relate, and get a
sketching out visually what each shot will look like. Then, thoseoff
who
visual
have something
better sense of what you are proposing. In agile software development, we do this by creating "use cases" or "user stories" that give a simple, task-oriented view of what
people will need to be able to do when using the system. The specifications are created from the user's perspective, focusing on the functionality that is demonstrable and
that performs some business function. We don't "storyboard" database optimization algorithms — no user or sponsor will likely be able to understand the technical details of
such a work component anyways, except at the most general levels — stakeholders do not even think of such features, or if they do, they just assume them to be in the project
anyway. You can "storyboard" a transaction or use case by sketching out the user interface (the screen) and the changes that appear on that interface as the various steps of
the use case are completed. This will help visual thinkers get a better feel for what you are proposing, they can better understand how it relates to how they perform their jobs
Gone are the days when the technical people get a written specification,
create
andusability
then hand
it back to the sponsoring group claiming that they are done. Now,
today, and you
can something,
get some early
feedback.
sponsors are more astute, taking a more holistic view of project success: the real measure of success they use is not conformance to the written requirements, but rather
the achievement of the business case benefits that prompted the funding of the project in the first place. Sponsors are demanding a seat at the table, and a chance to
provide some feedback during the development of the
Page 5 / 13
Reprinted for CTS/316124, Cognizant Technology Solutions
MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited
Managing Agile Projects, First Edition
project's "product."
The close involvement of sponsors and other stakeholders during iterative product development through the use of end of iteration reviews, allows stakeholders to
provide guidance to the project team that will avoid the "you built what I asked for, not what I wanted" situation discussed earlier. It also has an added benefit of allowing
On many projects, especially where the project is creating
something
thatapproach
the sponsors
have never
had before, the true requirements are often not known or understood.
a more
adaptive
to changing
requirements.
Sometimes these projects are reactions to external forces beyond the sponsor's control, and about which little is currently known:
n
New government legislation that will change regulations affecting how the organization carries out its business,
n
Changing
consumer
and
Customers demanding nnew
features
to matchpreferences,
a competitor's
newly announced offering.
In these (and related) situations, the sponsor will not know all of the detailed requirements at the start of the project. Instead, enough will be known to get started, and the
rest of the requirements will be discovered or fully explored during the course of the project. In these cases, it is sometimes better to "just get started" and then figure out
the details later.
I once had the challenge of building a new software system for a government body to allow the automation of some processes to meet service availability and
Like most proposed government legislation, by the time it gets approved and turned into law, it goes through many changes as a result of negotiations with the various
responsiveness targets proposed by upcoming legislation. The legislation, when passed, would require the immediate availability of the supporting information systems to
political parties and the influence of lobbyists. While the final requirements would not be known until the law was passed, we needed a system running days after the
support the new regulations.
proposal became law. What were we to do?
The use of agile techniques made this process much simpler. We started by building the pieces that were not likely to change, and demonstrated increasingly more
complete versions of the system through our end of iteration reviews. The specialists in the government department, who were closely monitoring the current state of the
legislation and the direction of the political winds, gave us feedback at each stage that allowed us to adapt the system to the prevailing concept of what the final legislation
Traditional methods, where one waits for a signed-off requirements document before starting work, would have led to long delays before we could start, numerous change
would look like. In four months, we developed and tested the complete system, and it was ready the day the legislation was passed into law.
request forms that would have been caught up in the government bureaucracy awaiting approval, and a delivery date that would have been months behind the required
(legislated) product availability date. If we had not accepted any change requests until we were done (one common response to this type of situation), we would have built
what was originally asked for, but not what was required at the time of completion, due to the many requirements that had changed. The project output would have been
useless. In this real-world example, agile techniques saved the day.
Building the Right Thing Wrong
Assuming we managed to build the right thing for the customer (that is, we completely and accurately understood the customer's requirements and expectations, and
managed to build a product that met those expectations) there is still a major product risk left to consider. We may have built the right thing, but we may have done a poor job
building it. In other words, we may "have built the right thing wrong."
Quality should be a concern for every product development effort, whether that product is computer software, a bridge, or a consulting report. Dr. William Edwards Deming,
the guru of the revolution in quality management that took over the business world in the 1980s and 1990s, tells us that quality needs to be designed into a product
development process. More simply: we need to find ways of ensuring that barriers to quality are removed at every step in the process.
In the software development world, quality is usually addressed through various types of testing at the end of the software development process: unit testing, integration
testing, usability testing, and others that all culminate in customer acceptance testing. One of the major reasons why most software development projects run over
budget and behind schedule is that this testing happens only at the end of the project. Defects are found late in the project lifecycle, leaving little time to fix them. When
a design
defect
is found,
theand
implications
disastrous
project
team must
revisit the
designs,development
make updates,
change
software that
wasAll
developed
One
solution
to this
problem,
one easilyare
addressed
by—
thethe
agile
techniques
of iterative
andinitial
incremental
is the
use ofthe
continuous
testing.
agile methods
uponevery
thoseiteration delivers fully-tested and functional deliverables. The completeness of
are structured around iterative and incremental development. Using thesebased
methods,
updated
(and the
changes
may
ripple
throughout
all areas
theportions
softwarethat
application)
and then
start iteration
the testing
process
all over again.
Just
these defects
thosedesigns
deliverables
increases
with
each
succeeding
iteration,
butofthe
are developed
in each
need
to be properly
working
forone
the of
iteration
to be can
lead to a delay of many months and the associated
increased
costs.This
We means
need tothat
findtesting
a way needs
to design
quality into
the software
considered
complete.
to happen
in every
iteration.development process to avoid these costly latecycle quality issues.
Testing during each iteration means that defects are found much earlier in the development cycle. This allows more time than the traditional "test at the end" methods for
fixing these defects. More importantly, critical design-related defects may be uncovered much sooner. As Boehm points out in Figure 1-1, the later a change (or, by
extension, design defect) occurs in a project, the greater the cost of incorporating the change. Identifying design defects early on is critical.
Page 6 / 13
Reprinted for CTS/316124, Cognizant Technology Solutions
MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited
Managing Agile Projects, First Edition
I once had a case where my team was one month into an agile development project. We had two-week iterations, and were at the end of our second end-of-iteration
review. The project sponsor had pulled in an external reviewer to assess our progress and approach. With a concerned look on his face, the external reviewer announced
that a new corporate standard for user interface design was just announced that we would have to live by on our project. Unfortunately, the new standard required us to
significantly redesign how we were building the user interface for our application. Essentially, about half of our work over the prior four weeks had to be discarded and done
over again. The
sponsor was not happy about this. That is, until I explained the impact on the project (and his budget) if we had not been using an agile development method. If the first time
that a reviewer had seen our work and noticed the non-compliance with the new standard was during the traditional "user acceptance testing" phase at the end of our eight
month project, we would have needed to discard months of work completed to that point in time — a much greater impact than the couple of lost weeks that we were really
facing. The sponsor immediately saw the value in iterative delivery and mandated the use of agile development methods (in this case, Scrum) on his future projects.
Another benefit to testing in each iteration is the greater amount of testing that generally takes place under these approaches. Additionally, through the regression tests
required to ensure that the incremental development does not break portions that were developed earlier, the initially-developed portions are tested over and over again,
increasing the chance that the initially-developed pieces work as they were intended. One way to ensure this is through the practice of test-driven development, where we
design the tests first — tests designed to test that the application Getting
will meet the
requirements
— and
then use the tests as design input into our development process. This
Stuck
in "Design
Churn"
way, we can use what will be the eventual "acceptance tests" as the unit and systems tests performed by the programmers. Running the relevant acceptance tests in each
iteration
means
code is more
likely
to workfor
asevery
expected,
since
there are
a do
greater
of opportunities
to of
fixproject.
identified
defectsthat
and
then retest
again
during
Agile
methods
arethat
not the
necessarily
the best
methods
project;
however,
they
havenumber
a lot to offer
certain types
Projects
benefit
the most
from
the use
of agile methods are those in which the requirements are either unclearsubsequent
or evolving.iterations.
If you expect a high level of requirements change during a project, then traditional
Peter Coad and Jeff DeLuca were brought on to one of these projects methods
in their notorious
"Singapore"
simply will
not work. project. [3] This project, to develop a commercial leasing system, had
such a complex design that no single team member could keep the entire design in his or her mind. To compensate for this complex design, the team had developed
thousands of pages of documentation (over 3,500 pages of use cases, class diagrams, etc.) in which they captured the design and worked out the complex component
interaction issues. The problem was that there were continual changes occurring that required them to review and update these 3,500 pages of documentation to incorporate
the impact of each change. Obviously, this took a lot of time, and by the time the changes were incorporated into the designs, more change had occurred. The changes were
sparking additional changes, and the team was stuck in the dreaded cycle of "design churn." The sponsor, frustrated with this lack of progress, fired the original development
team and brought in Coad and DeLuca to try and find a way out of this problem and start developing usable software.
To break out of the vicious cycle, Coad and DeLuca decided to take the pieces that they could understand clearly, and that were reasonably well-defined and stable, and
build them first. By completing these simpler pieces first, visible progress was demonstrated to the sponsor, usable software started evolving, and the project became
"unstuck." While the initial pieces were being built, the design team picked up another discrete piece and designed that piece enough that development could start on it,
and so on. This process works as long as the overall design uses open standards, and is flexible and extensible. (A similar process was used to break out of the design
churn encountered by Kent Beck, Ron Jeffries, and the rest of the C3 Team on the Chrysler Comprehensive Compensation system, [16] discussed later in this book.)
Another side benefit of this overall approach is the ability to procrastinate — that's right, procrastinate. If you are facing a project scope element where the requirements are
not stable, why not delay starting on the design and development of that piece as long as possible? Work on other pieces during the initial iterations, and push the scope
elements full of uncertainty to future iterations. In this manner, you can deliberately delay working on components whose requirements are likely to change for as long as
possible.
Thenot
longer
you wait,
the
greater
of the requirements
moreuntil
stable
is known
the
solution
youthis
aretechnique
enhancing
Now, I am
advocating
that
you
push the
out chance
all components
with unclearbecoming
requirements
lateas
in more
the project.
Thisabout
would
beemerging
foolish. You
needthat
to use
through
each
iteration.
Once
a
requirement
is
stable
enough
to
start
work,
then
that
is
the
time
to
start
working
on
it
—
to
start
earlier,
you
risk
too
much
rework
and are
wasted
judiciously, balancing the benefits of delaying the start of a project component with unstable requirements with other techniques that reduce other risks. In fact, there
times
when you may wanteffort.
to do the exact opposite.
Sometimes, the way of getting out of a design dilemma is through experimentation. If you are not sure how to overcome a design issue with certainty, or if you are faced with
competing approaches and cannot make up your mind which is best, try conducting an experiment to see which approach is better. Take a page from the Rational Unified
Process (RUP) playbook, and schedule the areas of greatest uncertainty (or risk) first, allowing you to perform experiments to validate assumptions, remove technical
uncertainty, and establish an approach that can work. Sometimes this approach will allow you to "prove" a design through demonstration long before you could "prove" it on
paper
with
supporting
design
details.
Use these techniques as different tools in your toolbox. Do not pick one
tool
and
try to apply
it to every
situation, but rather learn all of the tools and learn when each one is
best employed. In other words, use the right tool for the job at hand.
Improving Control
In addition to reducing risk, agile methods allow the project manager to improve his or her control over the project. This may sound
Page 7 / 13
Reprinted for CTS/316124, Cognizant Technology Solutions
MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited
Managing Agile Projects, First Edition
counterintuitive, but in practice, it is true: using a less-rigid, structured approach allows the manager to better control the project in situations where there will be high levels of
change on the project. In effect, the agile methods allow the manager to better respond and adapt to changing requirements in a way that does not lead to design churn,
confrontational contract negotiations, and angry stakeholders.
Generally, control is improved through a number of mechanisms that are common results of all agile methods:
n
n Frequent delivery of working code means progress is objectively measurable,
More chances for stakeholders to provide early feedback and redirect project priorities where necessary increases the chance of delivering real value,
n
n Misunderstanding are surfaced earlier, avoiding late-lifecycle design changes mentioned earlier in this chapter, and
The sponsor has the ability to end a project early and still get measurable benefits.
Frequent Delivery means Measurable Progress
By breaking the project lifecycle down into a number of short, recurring design-develop-test iterations, the functionality being developed that meets the business requirements
can be delivered in small increments, each providing business value. When facing highly-complex or risky projects, sponsors and managers have a much better read on the
real progress of a project when actual progress is visible to everyone on a frequent basis. Without the visibility of real progress, there is little management control that can be
meaningfully exerted to correct the course of the project or to deal with performance issues.
Consider a traditional waterfall-type development process. The team designs a solution, builds it, then tests and perfects it before handing it over to a project sponsor for
review and acceptance. If this whole process was 18 months long, the sponsor will have no means by which to measure progress until he or she gets access to the
completed
forallow
the acceptance
review.
Until into
the product
is ready
review,on
the
sponsor has
no concrete
means byFor
which
to measure
the team says
Instead,
agileproduct
methods
you to improve
visibility
real progress
byfor
focusing
user-visible
features
or transactions.
example,
let usprogress.
look at anIfapplication
with ten
they are 90% complete, who user-visible
can argue? The
next(such
weeks,
say they
are 91%,application).
92%, and then
93%
complete,
there is still
nothe
evidence
features
aswhen
menuthey
options
in a software
When
you
can demonstrate
that
four by which to question or
this progress.
of the ten are complete and working, you can claim you areargue
40% complete,
and have a sound basis against which to measure that progress.
Visible progress reduces uncertainty. It also puts sponsors at ease — especially those who may have gambled their careers on the success of your project. Showing them
real progress will ease their concerns, increase their satisfaction, and reduce their need for micromanaging you and your team.
Feedback and Redirection means Delivering More Value
End-of-iteration reviews allow sponsors and other stakeholders a chance to review the work performed to date. This introduces an opportunity for them to provide feedback.
You may hear that what was developed was perfect. More likely, you will hear feedback such as one of the following:
n What you delivered may be what I asked for, but not what I meant (a misunderstood requirement).
n What you delivered does not work properly (a defect).
n
n Now that I see what you have built, I have thought of something that would make it even better (a new requirement).
Now that I see what you have built, I realize we forgot something (a missed requirement).
n Something has come up — I need you to do that a different way (a change).
No matter which of the above types of feedback you receive, if you can incorporate the feedback into your next iteration, you will bring the project closer to delivering the
business value that the sponsor needs. There is no point in sticking to the original scope baseline and deferring change until the end of the project (or for another product
version/release) — doing so will mean that you deliver something to the sponsor that he or she cannot use. Since you have not adapted to his or her changing business
requirements, your deliverable is now based on obsolete requirements and will exist solely as "shelfware" — a useless effort and expenditure of funds unless you can make
the changes to the product
Capturing and responding to feedback at the end of each iteration will help you be more responsive to your sponsor's changing business
to bring it back in line with the sponsor's current business needs.
priorities, and will help you better deliver a product at the end of the project that will deliver some business value, rather than no business value (as would happen if you did
not respond to the changes). The feedback will not be just changes to what you have already built, but it will also help you reprioritize what you are planning to build next, to
ensure that you are focusing on the pieces that will deliver the greatest benefits.
Both the sponsor
and the
project manager
can
better control
theChange
delivery of business value.
Early
Feedback
means
Lower
Cost of
Getting feedback earlier in the project will allow changes to be incorporated earlier. As pointed out in Figure 1-1, this means that design changes have a greater chance of
being surfaced and acted upon earlier in the product development cycle, when the costs of those changes are the lowest.
Page 8 / 13
Reprinted for CTS/316124, Cognizant Technology Solutions
MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited
Managing Agile Projects, First Edition
End Early with Measurable Benefits
Another benefit of this approach allows the sponsor control over the level of quality (completeness) of the product at the end of the project. At the end of each iteration, the
included features should be fully functional and tested. Theoretically, it would be possible for the sponsor to release (deploy) the product at the end of any iteration,
allowing the sponsor to realize several benefits:
n
n
If the product is the first to address a niche in the marketplace, early deployment may allow the sponsor to gain marketshare well ahead of any competition.
n If the contents of the early iterations are selected carefully, then the sponsor may choose to deploy a partially-completed product to gain immediate benefits of the
If the contents of the iterations are continually reprioritized at the start of each iteration, focusing on the items that are most important first, then at some point later in the
completed portions, before the full product is completed. In some cases, the benefits from early deployment may help offset (or even pay for) the costs of completing the
project, all of the high-priority items will have been developed, and the only remaining
items to be developed will be of marginal value to the sponsor. The sponsor may
full product.
decide to forego developing these low-priority features, deeming the product to be "good enough" for general rollout.
Improving Communications
Finally, agile methods foster better communications among team members than traditional product development methods. Communications is key to any project, and all
good project managers know that 80% of the job of a good project manager is facilitating communications, whether
it be communicating status, discussing solutions to problems, notifying others of dependencies, or ensuring that everyone shares the same project vision and strategy.
Once, on one of those "take a student to work days," I had a Grade 9 student assigned to me. His task was to shadow me for the day, and then write a report for his class on
the role of a project manager.
For the entire day, the student followed me to meetings, watched me working at the computer, and listened to me calling project stakeholders to gain insight or to share
information. Only at the end of the day, before leaving work, did I find out that the student was the son of an executive several layers above me in the organizational hierarchy.
That made me wonder: did I do my job well, did I look professional, did I make a lasting impression? I hoped that when the boy's father asked who he shadowed at work that
day, and how things went, that I would get a glowing report.
About a week later, I received a copy of his school report via internal company mail along with a short note. The report described the day-to- day job of a project manager
as being
the most fun job in the company — you get to talk to your friends all day on the phone, stop by their desks for a chat, and send them emails. You don't have to
do any real work!
I was mortified. What would my executive think about my job performance? I opened the note with shaking hands and read
Sounds like my son doesn't get it yet. Maybe he's too young to understand, but it seems to me like you are focusing on exactly the right thing —
communications. That's the key to running a successful business, and a successful project. Good work.
I learned a lesson that day, about the importance of communications. I was never conscious of what I was doing, but that day opened my eyes. Since then, I have
deliberately crafted communications plans for my projects, and have designed project teams to maximize the flow of information and knowledge.
Co-Located Teams
There is tremendous value to be gained from using collocated teams on a project. These are teams where most (if not all) team members work in the same location,
preferably with adjacent desks. Later in this book we will delve into this topic in more detail, but in my experience, the direct benefits of collocated teams are experienced
Whiteboarding.
through several means.
Instead of crafting long-winded, complicated emails or documents describing issues and suggesting design approaches, when the team members are all in one location,
someone can simply tap others on the shoulder and ask them to step over to a whiteboard. By drawing diagrams, making quick changes, erasing and redrawing, and
through immediate feedback from others, solutions to problems can be quickly
and effectively described, modified, and agreed upon or rejected. This is what Cockburn describes [14] as high-bandwidth communications. This beats the long delays in
trying to do the same problem solving via long strings of emails back and forth between team members, or via slowly-evolving documents.
I once worked in an environment where we needed to boost the productivity
of athe
team
building a of
Web
application. We moved the graphic designer into the same office as the
Looking Over
Shoulders
Others.
two developers. There was an immediate improvement in the performance of the team, all attributable to better communications. When the designer created the mockup for
a new Web page, he could simply ask one of the developers to turn around in his chair and take a look at the design while it was on the screen. The developers could
immediately say whether the design was "buildPage 9 / 13
Reprinted for CTS/316124, Cognizant Technology Solutions
MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited
Managing Agile Projects, First Edition
able" or not, and could ask the designer to make immediate corrections that would prevent much later problem solving and rework. Similarly, the designer could review the
Web pages as the developers built them to give feedback on whether they were turning out as intended. Finally, the two developers were able to help each other out with
technical problems, reducing the time spent on problem-solving and fixing defects. Over all, it was the most effective management change that we implemented on the
project. The improved communications gave us greater control over the project's outcome.
Non-Verbal Communications.
The majority of the information we convey (approximately 70%, by some estimates) is through non-verbal means. This includes body language (nervousness, hesitation),
tone of voice (sarcasm, uncertainty), and eye contact (or the lack thereof). Sometimes, more is revealed by the topics that are avoided than by the topics that are discussed.
By working in a collocated environment, we avoid the use of impersonal communications vehicles such as email and documents that convey only 30% of the meaning;
instead, we get to use face-to-face conversations that allow us to take advantage of the full 100% of what information is being transmitted. This allows faster and more
thorough communications. It allows us to "read" the other person in a conversation to try and determine whether they really do understand what we just said. Sometimes we
have to work remotely, but even then, if a team has worked together before, and knows each others' working styles and personalities, then teleconferences are an
acceptable alternative that still allow a lot of non-verbal transfer of information. Greater understanding and faster transfer of knowledge and information: why would you ever
Short
want Daily
to workMeetings
apart again?
By holding regular (but short) daily team meetings, team members can share their successes and problems with each other. Following the lead of Scrum, agile
1.
What they have justmeetings
completed
sowhen
that others
who may be
dependent
uponpieces
the completion
of that work may get immediate notice
are —
best
team members
briefly
share three
of information:
of its readiness, and to give a measure of visible progress to the team's efforts.
2.
What they are about to work on next — so that team members will be aware of what others are doing and can able to help out or provide advice based upon
past experiences. This also may bring other dependencies to light that the team may not have been aware of at first.
3.
Any issues that are slowing down or halting progress — if facing technical issues, other team members may be able to help, or the project manager may be
able to find assistance from outside of the team. If the issues are organizational or administrative, the project manager can take immediate actions to remove the
Employing
short
daily
meetings
allows thethe
project
manager
to get
notice
of problems
(andor
thus
more time
to help
act upon
them before
intoto
big
issues).
barriers.
If the
issues
are personal,
project
manager
canearlier
seek out
assistance,
training,
whatever
other
is required
for thethey
teamballoon
members
maximize
Additionally, project managers can better ensure steady progress with these their
meetings
by
highlighting
crossdependencies
and
offering
a
chance
for
team
members
to
performance.
share their tacit knowledge to solve issues. Of course, the lengthy dialogues that might be required to impart knowledge or solve problems do not happen in the meeting —
they are handled through follow-up conversations between the team members affected — rather, the meetings are used to highlight the need for these follow-up
conversations.
Close Customer
(Sponsor) Involvement
Another way of improving control over the project through improved communications is by having the project sponsor, or a customer representative involved daily in project
meetings. The immediate and regular access to someone who understands the business situation that gave rise to the project, who understands the requirements, and who
is authorized to make decisions regarding the project can greatly
improve control over the project schedule, budget, and scope. In Extreme Programming, we call this the On-Site Customer, while in Scrum, this is referred to as the Product
Owner. There are three main ways in which this improved level of communications with the sponsor can be used
to help
control the project.
By having ready access to a decision-maker who understands the business
requirements
and the project's business case, the project manager can quickly escalate any
issues requiring a decision or action within the sponsor's organization. Usually, this role is held by someone with authority who can move roadblocks that the project
and Easyof
Escalation.
manager cannot resolve without assistance. The quickQuick
communication
these issues helps speed up the project, avoiding costly delays.
Snap Decision-Making.
In addition to the ability to quickly escalate issues to the sponsor or other key decision-makers, close customer involvement in the daily happenings within the project allows
you to contact a decision-maker immediately when a snap decision is required. No more struggling to find a decision maker and get a decision made. By having someone
involved who is authorized (and willing) to make decisions, you can communicate your decision point requests quickly,
Instant Feedback.
As discussed earlier in this chapter, one of the big benefits of agile development methods is that you have regular opportunities for stakeholder feedback at the end of
each iteration. Having close customer involvement in the project, however, leverages this benefit to even higher levels. Instead of waiting for end of iteration reviews for
feedback, team members can bounce ideas or approaches off of the customer representative at any point during the project to get immediate, valuable feedback. This
increased communications helps control quality by even further reducing the likelihood of "building the wrong thing."
Page 10 / 13
Reprinted for CTS/316124, Cognizant Technology Solutions
MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited
Managing Agile Projects, First Edition
As I have described above, there are three main categories of benefits from deploying agile development methods on projects, and each
plays an important role in improving project control. While agile methods are not the right solution for every project situation, they do provide a means by which to increase
control over projects where the requirements are constantly changing — projects that are notoriously hard to control using traditional methods.
[3]Palmer, Steven. "Feature-Driven Development." Borland Developer Network Web site.
<http://bdn.borland.com/article/borcon/files/2136/paper/ 2136.html>.
[16]The C3 Team. "Chrysler Goes to 'Extremes.'" Distributed Computing. Oct. 1998, 24–28.
[14]See Chapter 5 for more details on the benefits of high-bandwidth communications vehicles.
Why do we Need This Book?
There are many publications in the marketplace that describe the various agile methods and techniques. Yet, most of these discuss these techniques from the perspective
of a team member who will be employing these methods in the performance of their technical development activities. Very few publications present the agile methods
from the perspective of a project manager.
Additionally, most of the existing publications focus on a single method or agile technique; there are few that discuss all of the most common techniques. This book
presents techniques from many different agile methods, and compares the various methods in the context of these techniques. (I should note here that many of the
discussions deal primarily with Extreme Programming — not because the techniques are not applicable to other agile methods, but rather because Extreme Programming
is the agile method that has been most written about and most studied to date. When reading this book, when you read "Extreme Programming" consider that in most
instances the statement will apply to most other agile methods as well.)
Part
Introduction
This book combines the work of many experts into one volume. These
areOne:
the luminaries
of the field — the people who invented some of these agile methods and
techniques.
The
chapters
in
this
book
have
been
prepared
by
these
experts
both
from
previously
(and
updated)
original works,
The first section of this book, its introduction, presents an overview of what agile methodspublished
are about,
andnow
a brief
historyarticles,
of how and
they from
camenew
to be.
appearing in this book for the first time.
Chapter 1 — This chapter provides a brief overview of reason why agile methods were developed in the first place, and the major benefits to be gained from employing
them. The author, Kevin Aguanno, is a consultant, teacher, and keynote speaker on agile development methods. He focuses on bringing agile methods out from under the
software development umbrella and into the world of project managers. He has introduced hundreds of companies (and thousands of project managers) to agile
development principles and techniques.
Chapter 2 — For those who want to understand more about how these methods have evolved, this chapter provides a brief history of the major agile methods and
describes how they interrelate with the Software Engineering Institute's Capability Maturity Model (SEI CMM). The authors of this chapter, David Cohen, Mikael Lindvall,
Two:
Managingmethods
Agile Projects
and Patricia Costa performed an extensive study of agilePart
software
development
for the U.S.is
AirDifferent
Force through the Fraunhofer Center for Experimental Software
Engineering at the University of Maryland. This chapter is a brief extract from their full report.
The second section of this book explores how managing agile projects is different from managing projects following more traditional methods. This section takes a more
holistic view from the project management perspective, rather than the specific agile techniques that are deployed on projects.
Chapter 3 — Written by Kevin Aguanno, this chapter presents a brief overview of how agile project management is different from the project management approaches
Chapter 4 — There is a lot of confusion
between
the terms
and incremental.
Each
means
a very different thing, yet agile methods
presented
by bodies
suchiterative
as the Project
Management
Institute
(PMI).
bring both together for the first time in a unique way. Pascal Van Cauwenberghe is a noted author, teacher, and speaker on Extreme Programming and other agile
methods and techniques, and has prepared an excellent tutorial on the differences between iterative and incremental development approaches and the advantages
from each.
Chapter 5 — As one of the leading luminaries in the agile development movement, Alistair Cockburn has written numerous books, published scores of articles, and speaks
regularly at software development conferences on agile principles and techniques. He is the developer of a group of related agile methods called, collectively, the Crystal
Methods, and is one of the early proponents of using "use cases." Mr. Cockburn is one of the founders of the Agile Alliance, and a co-author of the Agile Manifesto. In this
chapter, adapted from a series of articles he published in Crosstalk: The Journal of Defense Software Engineering, he takes his experiences from agile software
development and
applies them to the topic of project management in general.
Page 11 / 13
Reprinted for
CTS/316124,
Cognizant
Technology
Chapter
6—
Agile project
managers
mustSolutions
walk a fine line between too much control, which destroys the benefits
from
flexibility Inc.,
thatKevin
agileAguanno
methods
and too
little
MultiMedia
Publications
(c)provide,
2004, Copying
Prohibited
control, which will allow a project to degrade into chaos. Learning from the science of Complex Adaptive Systems, Sanjiv Augustine and Susan Woodcock propose a
Managing Agile Projects, First Edition
between too much order and too much chaos, the so-called chaordic edge.
Chapter 7 — When requirements are constantly changing, documenting and rationalizing requirements — the practice of requirements engineering — becomes very
challenging. Jim Tomayko, a professor of computer science at Carnegie Mellon University and a scientist of the Software Engineering Institute (SEI), presents a brief
comparison between requirements elicitation in traditional and agile projects, highlights the related difficulties when working with requirements in agile projects, and
highlights one of the advantages.
Chapter 8 — One way in which agile projects are quite different from traditional projects, is in the level of involvement required from project stakeholders, and in particular,
the project sponsor. Scott Ambler, a noted expert on object-oriented software development techniques, the developer of the Agile Modeling technique, and a widelypublished author presents in this chapter the reason behind the need for active stakeholder participation on agile projects. In addition, he presents some tips for ensuring that
you get the most benefit out of your stakeholder involvement, and avoid some of the pitfalls.
Chapter 9 — Scott Ambler contributes again to this book by providing a chapter on the reliance of agile methods on higher-bandwidth communications; for example,
Part Three: With
Agile
Management
Techniques than traditional project methods, agile methods require some
focusing on face-to-face communications over written documentation.
a different
focus on communications
extra attention from project managers in this key area. Ambler's contribution in this chapter is an update from material presented in his book Agile Modeling: Effective
Now that we have discussed how agile projects are different from traditional projects, this section addresses a number of individual agile management techniques
Practices
forare
Extreme
Programming
The Unified Process.
that
common
to most agileand
methods.
Chapter
11 — While
Chapter
7 we discussed
theoverview
need forofathe
different
approach to requirements
engineering,
thissection.
chapter provides the
Chapter
10 —inKevin
Aguanno
provides an
agile management
techniques presented
in this
details on how to conduct such a different approach. Kirstin Kohler and Barbara Paech are active researchers in requirements engineering, having published many journal
articles in the field. Kohler is a researcher and consultant with the Fraunhofer Institute for Experimental Software Engineering in Germany, and Paech is the Chair of Software
Engineering at the University of Heidelberg. Both share their extensive experience in this area to provide practical approaches to overcoming the challenges surrounding
changing requirements on agile projects.
Chapter 12 — As a frequent speaker and teacher on agile development methods, perhaps the most frequently-asked question I receive is "How do you estimate and
deliver agile projects under fixed-price contracts?" While recognizing that time and materials contracts are the easiest under which to deliver agile projects, the reality in the
business world is that these types of contracts require a large amount of trust between the sponsor and the delivery team — trust that is often not present. In this chapter,
Pascal Van Cauwenberghe provides us with some good options for preparing fixed price contracts for agile projects.
Chapter 13 — The focus that agile methods place on feature-based prioritization, design, and progress reporting changes the paradigm under which a project operates.
To focus so much on user-facing features, requires that the project adopt a user-centric view of requirements and design. Larry Constantine, one of the founders (and
leading proponents) of usage-centered design, first presented the contents of this chapter as an article in Information Age. This chapter presents the pros and cons of
taking such as user-focused design approach, and shares a step-by-step process that managers can understand for performing user-focused design.
Chapter 14 — Documentation: how much is enough? In Chapter 9, we talked about the preference for other means of communication. Yet in Chapter 11, we explored the
need for requirements documentation. Where is the balance? In this chapter, Scott Ambler answers that question, providing an approach and some tips to help you prepare
"just enough" documentation.
Chapter 15 — One of the key benefits from (and requirements of) iterative development is the need for continuous testing. In this chapter, Ron Jeffries explores the different
types of testing you will need to perform in an agile environment,Part
and Four:
tips for performing
each.
He also
includes some tips on how to get your project teams to adopt the agile
There is No
Silver
Bullet
testing techniques such as automated regression testing. Jeffries is one of the
To prepare a balanced view of agile
project management,
oneProgramming
must look at method,
the criticisms
agile methods
well.
This section
presents some of the shortcomings
co-founders
of the Extreme
and isofathe
well-known
authoras
and
speaker
in this field.
and possible misrepresentations of the agile methods.
Chapter 16 — While we discussed how to do create agile documentation in Chapter 14, we still need to focus on face-to-face communications as our primary means
Chapter
17information.
— No singleInmethod
can address
all situations.
In this
chapter,
Kevin
Aguanno describes
theand
types
projects
wherein shares
agile methods
can for
playholding
a valuable
of sharing
this chapter,
Linda Rising,
one of the
leading
experts
in object-oriented
design
theofuse
of "patterns,"
techniques
agilerole,
and those that might best be served through
morethat
traditional
methods.
no one-size-fits-all
method:
project
managers should understand a number of different
meetings
first appeared
in There
STQE:isSoftware
Testing and
Quality
Engineering.
methods and be prepared to select the appropriate one for the project at hand.
Chapter 18 — Perhaps the most damning of all the critics of any agile method, Gerold Keefer is known for his in-depth analysis of the research supporting Extreme
Page 12 / 13
Programming
and for his
sharp (and
well-supported)
Reprinted for CTS/316124,
Cognizant
Technology
Solutions criticism of some of the claims made by XP proponents. Keefer is president of a quality management consultancy
MultiMedia
Publications
Inc., Kevin Aguanno (c) 2004, Copying Prohibited
that specializes in helping organizations take a common-sense
approach
to
Managing Agile Projects, First Edition
implementing best practices like CMMI.
Chapter 19 — Sometimes, the rapid pace of agile projects can cause problems. In this chapter, David Hussman, a noted speaker and author on agile development
practices, discusses the problems caused by agile projects locally-optimizing for their own projects, and the management problems that result from having multiple agile
projects with interface interdependencies. He doesn't leave us high and dry, however: he does provide us with a suggested risk reduction strategy for use when managing
this type of situation.
Chapter 20 — So, you have decided to adopt a whole agile method, or just some of these agile techniques, into your own organization. How do you combat the resistance
of those who are comfortable with the traditional techniques? How can you convince others that their methods are not the best ones for high-change projects? How do you
get the organization to change its official project management (and product development) methods? Kevin Aguanno addresses these — and other — questions in this
chapter on "stealth" methodology adoption.
All of us who have contributed to this book hope that you enjoy it and welcome any questions that you may have about the contents herein. At the end of the book you will find
biographical information on each author along with an email address and (in most cases) a Web site address. Feel free to visit the Web sites for more information and email
the authors with your questions or feedback.
For those wanting more details on these topics, most of the chapters have included extensive end notes including supporting references. Browse through these end
notes for additional sources of information.
Page 13 / 13
Reprinted for CTS/316124, Cognizant Technology Solutions
MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited
Managing Agile Projects, First Edition
by Kevin Aguanno (ed)
Multi-Media Publications Inc.. (c) 2004. Copying Prohibited.
Reprinted for Jayalakshmi L, Cognizant Technology Solutions
[email protected]
Reprinted with permission as a subscription benefit of Skillport,
http://skillport.books24x7.com/
All rights reserved. Reproduction and/or distribution in whole or in part in electronic,paper or
other forms without written permission is prohibited.
Managing Agile Projects, First Edition
Chapter 7: The Engineering of Unstable Requirements
Overview
James Tomayko, Ph.D.
Reprinted/derived from an article of the same title printed in the Proceedings of the International Workshop on Time Constrained
Requirements Engineering (TCRE), edited by Armin Eberlein and Julio Cesar Sampaio do Prado Leite, September 2002. Used with permission of the
author.
In a recent cartoon, a manager is seen walking through an area filled with programmers. He says, "You guys start coding and I'll go see what they want." This pretty well
characterizes the situation of projects today. There seems to be a common belief that agile development methods reinforce this unfortunate attitude toward requirements.
Conversely, my research has shown that an "agile attitude" toward requirements is a
very effective means of acquiring them. [1]
I have had 12 teams of from four to six engineers participate in Extreme Programming (XP) [2], [2] experiments in the past year. The experiments were primarily aimed at
[4] however, observing how these teams go about their work, has led me to several insights into the requirements
defect[1]reduction
andAnot
requirements
acquisition;
Smith, John.
Comparison
of RUP
and XP. Rational
Software White Paper, 2001.
[2]Beck, Kent. Extreme Programming. Boston:
acquisition
process. 2000.
Others have come to the same conclusions. [3]
Addison-Wesley,
[2]Cockburn, Alistair. Agile Software Development. Boston: Addison-Wesley, 2002.
[4]Tomayko, James E. "A Comparison of Pair Programming to Inspections for Software Defect Reduction." Computer Science Education.
2002.
[3]Tomayko, James E. "Using Extreme Programming to Develop Software Requirements." Soft-Ware 2002. Berlin: Springer-Verlag, 2002.
315–31.
The (Old) Method of Up-Front Requirements Elicitation
Current requirements elicitation methods reinforce improper beliefs. Many projects try to follow the waterfall software life cycle and other obsolete software development life
cycle models. The requirements are gathered first in one big effort. [4] Frequently, these requirements turn out to be rife with omissions and misconceptions. Correcting
them costs time and money. The result has been a movement toward more iterative models. [5]
At first, these took the form of prototypes, both to find missing requirements and to examine the feasibility of solutions. [6] The history of iterative requirements gathering has
itself gone through several cycles, of which agile methods are the latest. The trouble is that with each new iterative method the requirements elicitation process appears to
become less defined.
I feel [4]
that
the attitude
towardsRequirements.
requirements gathered
early
in the
process
is incorrect
in that ones missed at that stage are considered defects when added later. My
Davis,
Alan. Software
Englewood
Cliffs,
N.J.:
Prentice-Hall,
1990.
observations,[5]and the entire point of iterative processes, is that requirements are seldom omitted, they are just unknown. There is simply no way that the requirements of
Tomayko,
James E.problems
"An Historian's
View
of Software
Engineering."
Proc.
of the IEEEare
Conference
Software
Engineering
and
even
well understood
could be
known.
Therefore,
why even try?
Requirements
elicited byon
agile
methods
in a more Education
practical way.
Training. Los Alamitos, California: IEEE Computer Society Press, 2000.
[6]Leffingwell, D. and Widrig, D. Managing Software Requirements: A Unified Approach. Boston: Addison-Wesley, 2000.
Requirements Elicitation in Agile Methods
"User stories" or the like are just the beginning points of both the requirements gathering and development processes in agile methods. Early requirements are simply a
place to start. We expect to add more requirements as more is known about the product. Conversely, the method of trying to gather all the requirements before starting
development is almost certainly rife with errors and surely takes too long. "I'll know it when I see it (IKIWISI)" [7] has become a well-known requirements elicitation method. In
effect, the early version of the product becomes a prototype. Agile methods are designed to appeal to clients that insist on IKIWISI.
Prototyping in agile methods is even more rapid and produces smaller amounts of code than traditional prototypes. [2], [4] Developers that use
Page 2 / 3
Reprinted for CTS/316124, Cognizant Technology Solutions
MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited
Managing Agile Projects, First Edition
prototype-based life cycle models are familiar with the case of the client falling in love with the prototype so that they want to take it away as the product. Avoiding a situation
where bad code and poor documentation characterizes the product makes the developer produce a less robust prototype. As a result, they are not as useful. Agile methods,
which have the concept of a "spike"— a rapid development of a prototype that answers a single question about requirements content—avoid this problem of showing the
client too much.
In this way,
client is kept from the responsibility of "getting the requirements right." There are no wrong requirements. There are simply some waiting to be
[7]the
Boehm, Barry. "Requirements that Handle IKIWISI, COTS, and Rapid Change." Computer. Los Alamitos, California: IEEE Press. July 2000.
discovered.
99–102.
Difficulties Caused by Agile Methods of Gathering Requirements
This attitude toward requirements makes estimation and software architecture development more difficult, and verification easier, than traditional methods. Without
knowing the final form of the product, or marketplace demands, estimation is going to be impossible to get correct. [10] It is little comfort that requirements omissions and
changes caused by reacting to the competition make most estimates incorrect right now. Agile methods are likely to be right about the costs involved in the current cycle,
but estimating is poorly understood for the unknown requirements of the next cycle.
One thing that can be done is to fund the project one cycle at a time. However, there will be a time when knowing the total cost is necessary, as in contract work. In these
cases, customers express the requirements as well as they can, and estimates are adjusted by the probable cost of later changes. For instance, if a project is estimated at
$1 million, and prior projects of roughly those same characteristics have had the cost of "changed" requirements at around 20 per cent, then the estimate should be $1.2
million. Of course, as with all estimations, this can not be
used without considerable historical data.
The architecture
chosen by the team during the early cycles may become just plain wrong, as later requirements become known. Rework of the architecture matches the
[10]Thayer,
Richard
and Dorfman,
eds.Programming.
Software Requirements
Los Alamitos,
California:
IEEE
Society Press,
refactoring
principle Merlin,
of Extreme
Most of myEngineering.
XP teams embrace
refactoring,
claiming
thatComputer
they would
1997.
do it anyway, even if the requirements were stable. One student identified refactoring as rework, with its attendant negative properties, notably increased cost. Either way,
Advantages
of Agileare
Methods
Correctness
significant refactoring is to be expected in an atmosphere
where requirements
relativelyfor
unknown.
Confidence in the requirements translates to confidence in the
architecture.
Aside from refactoring and effective prototyping, agile methods have other advantages for a situation in which requirements are unstable. Reliance on test-driven
programming, a core principle of XP, means early detection of most minor errors, more certain detection of defects at integration, and early thinking-through of tests for a
Graphical User Interface. [5] This is an advantage to any system. For this reason alone, requirements engineering is advanced by the developer knowing right away if a
[5]Tomayko, James E. "Using Extreme Programming to Develop
requirement
can be
tested.
Software
Requirements."
Soft-Ware 2002. Berlin: Springer-Verlag, 2002.
315–31.
Page 3 / 3
Reprinted for CTS/316124, Cognizant Technology Solutions
MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited
Managing Agile Projects, First Edition
by Kevin Aguanno (ed)
Multi-Media Publications Inc.. (c) 2004. Copying Prohibited.
Reprinted for Jayalakshmi L, Cognizant Technology Solutions
[email protected]
Reprinted with permission as a subscription benefit of Skillport,
http://skillport.books24x7.com/
All rights reserved. Reproduction and/or distribution in whole or in part in electronic,paper or
other forms without written permission is prohibited.
Managing Agile Projects, First Edition
Chapter 4: An Introduction to Iterative and Incremental Delivery
Pascal Van Cauwenberghe
Overview
Surprisingly, many people still wonder what is wrong with the safe and predictable, sequential-phased approach, also known as "waterfall." This is despite the fact that a lot
has been written about iterative and incremental development over many years. Still, most people involved in software development cannot give you a clear definition of
what those two words mean to them. When they are able to give definitions, they often contradict each other.
Into this confused world, the proponents of Agile Development and especially Extreme Programming proclaim that they go beyond "traditional" iterative and incremental
Definingdevelopment
Our Termsmethods. What are we to do? How do we approach software projects? How do we reach our targets reliably, quickly, and efficiently?
"When I use a word," Humpty Dumpty said in a rather scornful tone, "it means just what I choose it to mean — neither more nor less."
Lewis Carrol, Through The Looking Glass.
We must first choose what we want our terms to mean.
A Phase: A period in which some clearly defined task is performed. Just imagine that we require the following phases: Analysis, Design, Coding, Testing, Integration,
Deployment.
has some
inputs
and
some
To Iterate: To perform some task inand
multiple
passes. Each
Each phase
pass improves
the
result,
until
the outputs.
result is "finished." Also called rework.
An Iteration: A period in which a number of predefined tasks are performed. The results are evaluated to feed back to the next iteration.
An Increment: A period in which some functionality is completed to a production-quality level.
A Release: Some coherent set of completed functionalities that is useful and useable to the intended users of the system.
To illustrate the difference between iterative and incremental, imagine a project where we need to develop a system that has three functions: A, B and C. Each of the
functions requires the same amount of work: one month. Thus, we have a three month project.
With these definitions we can have a look at different ways to organize a software project.
Figure 4-1: A comparison of iterative and incremental development models.
Different Ways to Plan a Project
The Waterfall — Straight to the Target
The sequential, phased approach, better known as "Waterfall" is the simplest and potentially fastest approach: we analyze the problem, design the solution, implement the
code, is
test
code (are
fixsteps
the coding
bugs?),
integrate
then
deploy.
Done.
The attraction of this process model
itsthe
simplicity:
youwe
doallowed
each ofto
the
and then
you are
done. ifIf necessary,
you want toand
know
how
long the
project takes, just add up the time
required for each phase. These times are just estimates, so your total is also an estimate. But it makes following up on the project's schedule easier. For example, once
analysis and design are complete, they will not be worked on again.
n
Remote stakeholders like upper level managers or The
end-users
whoofhave
needattracts
to know
thekinds
exactofprocess.
simplicity
this no
model
two
people: They really just want to know when the outputs will be
delivered.
n Teachers and educators who need to present a simplified model of a process as a first, simplified introduction to the subject.
Page 2 / 6
Reprinted for CTS/316124, Cognizant Technology Solutions
MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited
Managing Agile Projects, First Edition
Unfortunately, it is this first approximation that sticks in the minds. Or do students skip all the following lectures?
The Spiral — Iterate to Incorporate Feedback
Of course, it is never as simple as the waterfall process suggests: we do make errors during analysis and design. When Walker Royce [1] originally described his
process, there were feedback loops back to analysis and design. They were quickly "simplified" away. So, this was the original phased, iterative approach:
n Perform analysis, until you think you are ready
n
Design, until you think you are ready. Should you find any problems in the analysis, feed them back to the analysis. Perform another iteration of the analysis, to
improve it.
n
Code the design, until ready. Should you find any problems in the design, feed them back. Perform another iteration of the design, to improve it.
n
Test the code. Should you find any problems, start another iteration of the coding.
n Integrate and deploy. Feed back any problems you encounter.
As Boehm [2] noted, the later a defect is caught, the higher the cost to fix it. We are therefore encouraged to only proceed cautiously to the next phase if the previous phase
relatively
complete.
As software
have
noted,
the likelihood
finding
becomes
asoutput
we come
to the
laterisphases.
ThisIn
is more
because
Inisshort,
you go
sequentially
throughengineers
the phases.
Some
phases
have moreofthan
onedefects
iteration
if we seehigher
that the
of that
phase
not perfect.
thaneach
one phase
delivers
more precise,
more "testable"
output than
previous
phases.
sense,
theawaterfall
is the optimist's
interpretation
of thethe
spiral
model.
There is one management problem with the spiral model: how do you schedule the iterations? How many iterations will be needed? This makes estimating and
tracking
the project's
progress —
more
difficult Better
and unpredictable.
Iterative
Development
Getting
All the Time
Where the spiral process views feedback and iteration as exceptional events, iterative development assumes we will make mistakes, we will need feedback, and we will
need several iterations before we get it right.
In iterative, phased development we design our project plan around the idea of iterations and fit the phases in them. For example, we can plan to have five iterations:
n
n
In the second iteration we will do 30% analysis, 50% design, 20% coding
n
n
In the first iteration we will do 90% analysis, 10% design
In the third iteration we will do 10% analysis, 30% design, 70% coding
In the fourth iteration we will do 10% design, 50% coding, 40% testing and bug fixing
Iterative Development with Incremental Delivery — Growing Software
n In the fifth iteration we will do 50% testing and bug fixing, 30% integration, 20% deployment.
One complaint we could have with the previous process is that it takes too long to see the results of the work. Indeed, the software is not ready until the absolute end of the
This processproject.
takes into
account
the reality
that we
almost
never
get
anything
completely
right the
firstincremental
time. At first,delivery,
we will get
a lot of feedback.
Gradually,
with each iteration,
What
if we need
the results
faster?
We
could
use
iterative
development
with
a variation
on the previous
process.
the output from each phase stabilizes and we need to do less rework.
The basic idea is to release the software several times to its users, each time with more functionality. Each release is complete, useable and useful to its users. Each
release adds more functionality, preferably the most important functionality first. How do we schedule our project?
First, we go through several iterations of analysis and design, until we are pretty sure these phases are mostly complete. We can then select the content and
schedule of the increments to be developed. Let's say we have identified three increments A, B and C, to be delivered in this order to the users.
n For increment B, we iterate through all required phases, until the software can be released. We expect almost no analysis or design work.
n For increment A, we iterate through all required phases, until the software can be released. We expect to rework the analysis and design very little.
For increment C, we iterate through all required phases, until the software can be released. We expect almost no analysis or design work. We can picture this process
n
n
as four applications of the above process. The amount of analysis and (architectural) design decreases in each
Page 3 / 6
Reprinted for CTS/316124, Cognizant Technology Solutions
MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited
Managing Agile Projects, First Edition
step. The process delivers functionality after the second, third and fourth steps.
How do we select the contents of the increments? Architecture-driven processes would select the elements that have the most impact on the architecture (and thus the
design). Risk-driven processes would select the most risky elements. Users would prefer the most useful or urgent functionalities.
Agile Software Development — Extremely Incremental
Agile software methods like Extreme Programming [3] take another approach, based on the following assumptions:
n
n
n
You should deliver software to your users in small increments and deliver functionality in the order that the users want.
The
development
process
is then scheduled
as follows: can be added at any time.
Gather
an initial list
of requirements.
New requirements
n
n
You should welcome feedback and rework, instead of trying to avoid it
Decide
length
of incremental
increments
are theprioritize
same length.
Decide which
ones
will be
releases
internally
for evaluation
and
Beforeon
thethe
start
of each
increment: releases.
users (or All
their
representative)
the requirements
and
assign
theinternal
requirements
to (used
releases.
As many
releases as
required
feedback)
and external
toone
the being
end-users).
can be planned, but typically
the contents
of all releases
releases,(released
except the
implemented, are subject to change.
n
n
n
During the increment, the requirements are analyzed and broken down into small micro-increments. These increments are small enough to be fully implemented in a
day or less.
To implement a micro-increment, the developers analyze, design code, test, integrate and deploy iteratively. They iterate very quickly, so as to get a lot of feedback to
guidefor
their
[1]See <http://www.sei.cmu.edu/cbs/spiral2000/february2000/Royce/>
an work.
overview of RUP as an example of a "Spiral process."
[2]Boehm, Barry. Software
Each
increment has
a fixed length.
needed,
scope
is Prentice
reduced/increased
Engineering
Economics.
UpperIfSaddle
River,
NJ:
Hall, 1981.by the user to meet the target date.
[3]Beck, Kent. Extreme Programming Explained. Boston: Addison-Wesley, 2000.
What's So Extreme in Extreme Programming?
What is the difference between Extreme Programming-style planning and iterative development with incremental delivery, such as is possible with the well-known and
accepted Unified Process framework?
Incremental Architecture and Design
One difference is the assumption that you can do architecture and design incrementally. Indeed, XP spends very little time up front to define an architecture and
overall design. Instead, we immediately start with the first increment to deliver functionality. All architecture and design work is done to satisfy the requirements of the
n A System Metaphor describes an overall architecture and vocabulary that all participants understand and agree with. The Metaphor is refined iteratively over the
current increment. XP does design in the following ways:
whole project.
n Test-First programming designs the code incrementally by defining executable tests with which the program unit must comply.
n Refactoring reworks the design to iteratively adapt the design to changing knowledge, environment, or requirements.
n
Whiteboard design sessions, CRC card sessions, and other group design techniques.
Incremental Analysis
An even more controversial assumption is that you can do analysis incrementally. At the start of each increment, we only examine the requirements that have been
this increment.
XP does
analysis in the
following
ways:
n Brief requirements, called Stories, arescheduled
elaboratedfor
interactively
between
the development
team
and the
story author just before and during implementation.
n
Requirements are formalized into executable "Acceptance" tests, which specify and verify the compliance of the software with the requirement.
n
Requirements are allocated to releases using the Planning Game, where developers and customers optimize delivered value versus
Page 4 / 6
Reprinted for CTS/316124, Cognizant Technology Solutions
MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited
Managing Agile Projects, First Edition
development cost.
Incremental Development in a Customer-Selected Order
A final difference is the assumption that you can deliver software features incrementally, in whatever order yields most benefit for the customer. If the software can
be delivered incrementally, the users will get the benefit of the functionality sooner and thus get a faster return on their investment. As the customers can choose the delivery
order, they receive the most important and valuable features first. The use of these increments generates lots of valuable feedback to drive the following increments.
What's the Best Way to Plan a Project?
The short answer is that it depends. It depends on your project, your team, and your environment. If the assumptions of XP hold, we can gain a lot of benefits from working
incrementally:
n Early delivery
of useful software.
n
Delivery of functionality based on the value users give to that functionality (business value-driven instead of architecture-or risk-driven).
n Clear, tangible feedback on progress: each increment delivers finished, production-quality functionality.
n
Clear and regular feedback on the quality and fit of the software from the users to the development team.
n
n
n
The ability to adapt the project plan.
Clear scheduling and predictable delivery.
n By
only looking of
at the
small
piecespossible
(increments)
of the
have to dowithout
massive
which might
have been
avoided if we
analyzed
designedofthe
The
development
simplest
system
thatsoftware,
satisfies we
the may
requirements,
anyrework,
unnecessary
adornments
and complexity.
What
are theordangers
this
whole system correctly.
approach?
n We might "paint ourselves into a corner;" that is, we can get a system that is incapable of supporting some new requirement.
n
We may be unable to add global requirements, such as alternate language support, performance, and security. A typical example is trying to retrofit "security" to an
application that was not designed with this requirement in mind.
A Few Heuristics
We might go slower because we have to restart analysis and design sessions for each increment, instead of doing it once at the start of the project.
If your requirements are volatile or incomplete, if the environment changes, or if you wish to be able to anticipate to future events, work incrementally. If the
requirements and environment are stable, you can optimize your process by looking at all the requirements upfront.
n
If you are not familiar with the domain, or have not built a similar architecture, work incrementally. Use the feedback to design your system and to avoid unnecessary
complexity. If you have created many similar systems, you can do more design work up front. Still, you can always use the feedback to keep your system simple.
If you cannot deliver incrementally, then don't deliver incrementally. But, even if you cannot deliver incrementally to your final user, you might deliver incrementally to
internal users, such as the quality assurance team, or product managers. Even if you cannot do that, deliver incrementally within your team. That way you still get the
benefit of early feedback.
If you know a requirement is going to be more difficult to work on if you only tackle it later, work on it now. This might happen with global properties of software systems like
localization, scalability, and security. You can still get the benefit of business value-driven scheduling for most requirements if you take those few exceptions into account:
"Did you want security with that, Sir? With security, this feature will cost you X. Without security, it will cost you Y. If you wish to add security later, it will cost you Z." Iterative
Conclusion
(re) design techniques like refactoring and the emphasis on simplicity does
help to keep your software "soft"—more malleable—more accepting of changes.
Incremental
software
withwork
shortupfront
increments,
project
andyou
functional
risk and allows
us toondeliver
value on
faster
users.
release provides
If your
team development,
is big, do enough
with areduces
small team
so that
can decompose
the work
the system
the to
basis
of aEach
reasonable
opportunities for useful external (customer/user) feedback and replanning,
so thatorwe
arearchitecture.
more likely to deliver what the customer needs. Within those increments, one
(but not perfect
final)
iterates based on internal feedback (tests, reviews), to reduce technical risk, so that we are more likely to deliver the quality the customer needs.
The project is at its most agile when we use fast iteration and short increments, as the regular feedback allows us to make continuous small course corrections to our
project.
Page 5 / 6
Reprinted for CTS/316124, Cognizant Technology Solutions
MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited
Managing Agile Projects, First Edition
Page 6 / 6
Reprinted for CTS/316124, Cognizant Technology Solutions
MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited
Agile Project Management for Dummies
by Mark C. Layton
John Wiley & Sons (US). (c) 2012. Copying Prohibited.
Reprinted for Jayalakshmi L, Cognizant Technology Solutions
[email protected]
Reprinted with permission as a subscription benefit of Skillport,
http://skillport.books24x7.com/
All rights reserved. Reproduction and/or distribution in whole or in part in electronic,paper or
other forms without written permission is prohibited.
Agile Project Management for Dummies
Chapter 7: Defining the Product Vision and Product Roadmap
In This Chapter
n
Planning agile projects
n Establishing the product vision
To start, let's dispel a common myth. If you've heard that agile projects don't include planning, dismiss that thought right now. Not only will you plan the overall project, you
n Creating features and aalso
product
roadmap
will plan
every release, every sprint, and every day. Planning is fundamental to agile project success.
If you're a project manager, you probably do the bulk of your planning at the beginning of a project. You may have heard the phrase, "Plan the work, then work the plan,"
which sums up non-agile project management approaches.
Agile projects, in contrast, involve planning up front and throughout the entire project. By planning at the last responsible moment, right before an activity starts, you know
the most about that activity. This type of planning, called just-in-time planning or a situationally informed strategy (introduced in Chapter 3), is a key to agile's success.
TECHNICAL STUFF Helmuth von Moltke, a nineteenth-century German field marshal and military strategist, once said, "No plan survives contact with the enemy." That is,
in the heat of a battle — much like in the thick of a project — plans always change. The agile focus on just-in- time planning allows you to accommodate real situations and
to be well informed as you plan specific tasks.
Planning in Agile
This chapter describes how just-in-time planning works with agile. You also go through the first two steps of planning an agile project: the product vision and the
product
Planning happens at a number of points in an agile project. A great way to
look atroadmap.
the planning activities in agile projects is with the Roadmap to Value. Figure 7-1 shows
the roadmap as a whole.
n
Figure 7-1: Planning in agile with the Roadmap to Value
The Roadmap to Value has seven stages:
In Stage 1, the product owner identifies the product vision. The product vision is your project's destination; it's a definition of what your product is, how it will support
your company or organization's strategy, who will use the product, and why people will use the product. On longer projects, revisit the product vision about once a
year.
n In Stage 2, the product owner creates a product roadmap. The product roadmap is a high-level view of the product requirements, with a
Page 2 / 11
Reprinted for CTS/316124, Cognizant Technology Solutions
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
Agile Project Management for Dummies
n
n
n
n
n
loose time frame for when you will develop those requirements. Identifying product requirements and then prioritizing and roughly estimating the effort for those
requirements allow you to establish requirement themes and identify requirement gaps. Revise the product roadmap biannually with support from the development
team.
In Stage 3, the product owner creates a release plan. The release plan identifies a high-level timetable for the release of working software. The release serves as a
mid-term goal that the scrum team can mobilize around. An agile project will have many releases, with the
highest-priority features appearing first. You create a release plan at the beginning of each release. Find out more about release planning in Chapter 8.
In Stage 4, the product owner, the scrum master, and the development team plan sprints, also called iterations, and start creating the product within those sprints.
Sprint planning sessions take place at the start of each sprint. During sprint planning, the scrum team determines a sprint goal, with requirements that support the
goal and can be completed in the sprint, and outlines how to complete those requirements. Get more information about sprint planning in Chapter 8.
In Stage 5, during each sprint, the development team has daily scrum meetings to coordinate the day's priorities. In the daily scrum meeting, you discuss what you
completed yesterday, what you will work on today, and any roadblocks you have, so that you can address issues immediately. Read about daily scrums in Chapter 9.
In Stage 6, the scrum team holds a sprint review. In the sprint review, at the end of every sprint, you demonstrate the working product to the product stakeholders. Find
out how to conduct sprint reviews in Chapter 10.
In Stage 7, the scrum team holds a sprint retrospective. The sprint retrospective is a meeting where the scrum team discusses how the sprint went and plans for
improvements in the next sprint. Like the sprint review, you have a sprint retrospective at the end of every sprint. Find out how to conduct sprint retrospectives in
Chapter 10.
Each stage in the Roadmap to Value is repeatable, and each stage contains planning activities. Planning in agile, like development in agile, is iterative.
REMEMBER The various teams on agile projects — the development team, the scrum team, and the project team — have different roles
and responsibilities, as you see throughout this chapter and the rest of the book. Figure 7-2 shows how these teams fit together.
Figure 7-2: Teams in agile
Planning as Necessary
During each stage in an agile project, you plan only as much as you need to plan. In the early stages of your project, you plan widely and holistically to create a broad outline
of how the product will shape up over time. In later stages, you narrow your planning and add more details to ensure success in the immediate development effort.
Planning broadly at first and in detail later, when necessary, prevents you from wasting time on planning lower-priority product requirements that may never be
implemented. This model also lets you add high-value requirements during the project without disrupting the development flow.
The more just-in-time your detailed planning is, the more efficient your planning process becomes.
REMEMBER Some studies show customers rarely or never use 64 percent of the features in an application. In the first few development
cycles of an agile project, you complete features that are high priority and that people will use. Typically, you release those groups of features
Page 3 / 11
Reprinted for CTS/316124, Cognizant Technology Solutions
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
Agile Project Management for Dummies
as early as possible.
Inspect and Adapt
Just-in-time planning brings into play a fundamental tenet of agile techniques: inspect and adapt. At each stage of a project, you need to look at the product and the
process
(inspect)cycle
and make
changesand
as adapting.
necessaryConsider
(adapt). the following:
Planning in agile
is a rhythmic
of inspecting
n
During the sprint, the product owner provides feedback to help improve the product as the development team creates the product.
n
n
n
At the end of each sprint, in the sprint review, stakeholders provide feedback to further improve the product.
Also at the end of each sprint, in the sprint retrospective, the scrum team discusses the lessons they learned during the past sprint to improve the development
process.
After a release, the customers using the product can provide feedback for improvement. Feedback might be direct, when a customer contacts the company about
the product, or indirect, when potential customers either do or don't purchase the product.
Inspect and adapt is a fantastic tool for delivering the right product in the most efficient manner.
REMEMBER At the beginning of a project, you know the least about
the product
creating,
so trying to plan fine details at that time just doesn't work. With agile, you
Defining
theyou're
Product
Vision
do the detailed planning when you need it, and immediately develop the specific requirements you defined with that planning.
The first stage in an agile project is defining your product vision. The product vision statement is an elevator pitch, or a quick summary, to communicate how your
Now that
you know aor
little
more about strategies.
how planning
agile, it's must
time to
complete
the
first for
step
in product.
an agile project: defining the product vision.
product supports
the company's
organization's
Theworks
visioninstatement
articulate
the
goals
the
The product might be a commercial product for release to the marketplace or an internal solution that will support your organization's day-to- day functions. For example,
say your company is XYZ Bank and your product is a mobile banking application. What company strategies does a mobile banking application support? How does the
application support the company's strategies? Your vision statement clearly and concisely links the product to your business strategy.
Figure 7-3 shows how the vision statement — Stage 1 on the Roadmap to Value — fits with the rest of the stages and activities in an agile project.
Figure 7-3: The product vision statement as part of the Roadmap to Value
The product owner is responsible for knowing about the product, its goals, and its requirements throughout the project. For those reasons, the product owner creates the
vision statement, although other people may have input. After the vision statement is complete, it becomes a guiding light, the "what we are trying to achieve" statement that
the development team, scrum master, and stakeholders refer to throughout the project.
When creating a product vision statement, follow these four steps:
1.
Develop the product objective.
2.
Create a draft vision statement.
3.
Validate the vision statement with product and project stakeholders. Revise the vision statement based on feedback.
4.
Finalize the vision statement.
The look of a vision statement follows no hard-and-fast rules. However, anyone involved with the project, from the development team to the CEO, should be able to
understand the statement. The vision statement should be internally focused, clear, nontechnical, and as brief as possible. The vision statement should also be explicit
and avoid marketing fluff.
Step 1: Developing the Product Objective
Page 4 / 11
Reprinted for CTS/316124, Cognizant Technology Solutions
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
Agile Project Management for Dummies
To write your vision statement, you must understand and be able to communicate the product's objective. You need to identify the following:
n
Key product goals: How will the product benefit the company that is creating it? The goals may include benefits for a specific department within your company,
such as customer service or the marketing department, as well as the company as a whole. What specific company strategies does the product support?
n
n Customer:
will use
the features
product?are
This
question
might
have more than one answer.
n Need: Why does the customer
need theWho
product?
What
critical
to the
customer?
Competition: How does the product compare with similar products?
n Primary differentiation: What makes this product different from the status quo or the competition or both?
Step 2: Creating a Draft Vision Statement
After you have a good grasp of the product's objective, create a first draft of your vision statement.
You can find many templates for a product vision statement. For an excellent guide to defining the overall product vision, see Crossing the
Chasm, by Geoffrey Moore (published HarperCollins), which focuses on how to bridge the gap ("chasm") between early adopters of new technologies and the majority
who
follow. Will the market take to the product? Will there be an adequate return
The adoption of any new product is a gamble. Will users like the
product?
on investment for developing the product? In Crossing the Chasm, Moore describes how early adopters are driven by vision, whereas the majority are skeptical of
visionaries and interested in down-to-earth issues of quality, product maintenance, and longevity.
TECHNICAL STUFF Return on investment, or ROI, is the benefit a company gets from paying for something. ROI can be quantitative, such
as the additional money ABC Products makes from selling widgets online after investing in a new website. ROI can also be something intangible, such as better
customer satisfaction for XYZ Bank customers who use the bank's new mobile banking application.
By creating your vision statement, you help convey your product's quality, maintenance needs, and longevity.
Moore's product vision template is pragmatic. In Figure 7-4, I expand the template to more explicitly connect the product to the company's strategies. If you use this
template for your product vision statement, it will stand the test of time as your product goes from early adoption to mainstream usage.
Figure 7-4: Expansion of Moore's template for a vision statement
TIP One way to make your product vision statement more compelling is to write it in the present tense, as if the product already exists. Using
present tense helps readers imagine the product in use.
Using my expansion of Moore's template, a vision statement for a mobile banking application might look like the following:
For XYZ Bank customers
who want access to online banking capability while on the go,
the MyXYZ mobile banking application by XYZ Bank
is a mobile application that can be downloaded and used on smartphones and tablets
Page 5 / 11
Reprinted for CTS/316124, Cognizant Technology Solutions
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
Agile Project Management for Dummies
that allows bank customers to conduct secure, on-demand banking, 24 hours a day.
Unlike traditional banking at a branch or online banking from your home or office computer,
our product allows users immediate 24-hour access to their financial accounts wherever they have mobile carrier service.
Platinum Edge addition: This supports our company strategy to provide quick, convenient banking services, anytime, anywhere.
As you can see, a vision statement identifies a future state for the product when the product reaches completion. The vision focuses on the conditions that should exist
when the product is complete.
WARNING! Avoid generalizations in your vision statement such as "make customers happy" or "sell more products." Also watch out for too much technological
specificity, such as "using release 9.x of Java, create a program with four modules that…." At this early stage, defining specific technologies might limit you later.
Here are a few extracts from vision statements that should ring warning bells:
n
n
n Secure additional customers for the MyXYZ application.
Satisfy our customers by December.
Eliminate all defects and improve quality.
n Create a new application in Java.
n
Beat the Widget Company to market by six months.
Step 3: Validating and Revising the Vision Statement
After you draft your vision statement, review it against the following quality checklist:
n
Does
the statement
a compelling
description
how the
product meets customer needs?
Isn this
vision
statementprovide
clear, focused,
and written
for anof
internal
audience?
n
n
n Does the vision describe the best possible outcome?
Is the business objective specific enough that the goal is achievable?
Does the statement deliver value that is consistent with corporate strategies and goals?
n Is the project vision statement compelling?
These yes-or-no questions will help you determine whether your vision statement is thorough. If any answers are no, revise the vision statement.
n
n
When all answers are yes, move on to reviewing the statement with others, including the following:
Project stakeholders: The stakeholders will be able to identify that the vision statement includes everything the product should
accomplish.
Your
development
the team
willproduct
create the
must understand
whatroadblocks
the product
needs
to accomplish.
n Scrum
master: Ateam:
strongBecause
understanding
of the
willproduct,
help the itscrum
master remove
and
ensure
that the development
team is on the right path later in the project.
n Agile mentor: Share the vision statement with your agile mentor, if you have one. The agile mentor is independent of the organization and can provide an external
See whether others think the vision statement is clear andperspective,
delivers thequalities
messagethat
youcan
want
to convey.
Review
and revise
make
for a great
objective
voice.the vision statement until the project stakeholders,
the development team, and the scrum master fully understand the statement.
REMEMBER At this stage of your project, you might not have a development team or scrum master. After you form a scrum team, be sure to
review the vision statement with it.
Step 4: Finalizing the Vision Statement
After you finish revising the vision statement, make sure your development team, scrum master, and stakeholders have the final copy. You might even put a copy on
the wall in the scrum team's work area, where you can see it every day. You will refer to the vision statement throughout the life of the project.
If your project is more than a year long, you may want to revisit the vision statement. I like to review and revise the product vision statement once a year to make sure
the product reflects the marketplace and supports any changes in the company's needs.
Page 6 / 11
Reprinted for CTS/316124, Cognizant Technology Solutions
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
Agile Project Management for Dummies
REMEMBER The product owner owns the product vision statement and is responsible for its preparation and communication across and
outside the organization. The product vision sets expectations for stakeholders and helps the development team stay focused on the goal.
Congratulations. You have just completed the
first stage
your agile
project. Now it's time to create a product roadmap.
Creating
a in
Product
Roadmap
The product roadmap, Stage 2 in the Roadmap to Value (see Figure 7-5), is an overall view of the product's requirements and a valuable tool for planning and organizing
the journey of product development. Use the product roadmap to categorize requirements, to prioritize them, and to determine a timetable for their release.
Figure 7-5: The product roadmap as part of the Roadmap to Value
As he or she does with the product vision statement, the product owner creates the product roadmap, with help from the development team. The development team
participates to a greater degree than it did during the creation of the vision statement.
TIP Keep in mind that you will refine requirements and effort estimates throughout the project. In the product roadmap phase, it is okay for
your requirements, estimates, and timeframes to be at a very high level.
1.
2.
3.
4.
Identify product requirements and add them toTo
the
roadmap.
create
your product roadmap, you
Arrange the product requirements into logical groups.
Estimate requirement effort at a high level and prioritize the product's requirements.
Envision high-level time frames for the groups on the roadmap.
Because priorities can change, expect to update your product roadmap throughout the project. I like to update the product roadmap at least twice a year.
TIP Your product roadmap can be as simple as sticky notes arranged on a white board — which makes updates as easy as moving a sticky
note from one section of the white board to another.
You use the product roadmap to plan releases — Stage 3 in the Roadmap to Value. Releases are groups of usable product functionality that you release to customers to
gather real-world feedback and to generate return on investment.
The following section goes through the steps to create a product roadmap in detail.
Step 1: Identifying Product Requirements
The first step in creating a product roadmap is to identify, or define, the different requirements for your product.
Decomposing requirements
Throughout the project, you will break those requirements down into smaller, more manageable parts using a process called
decomposition. You can break requirements down into the following sizes, listed from largest to smallest:
n Themes: A theme is a logical group of features and is also a requirement at its highest level. You may group features into themes in
Themes: A theme is a logical group of features and is also a requirement at its highest level. You may group features your product roadmap.
n
n
n
Epic user stories: Epics are very large requirements that support a feature and contain multiple actions. You need to epics before you can start
will see how
creating a product requirement from them. You can find out how you will use epics for release p Chapter 8.
n Tasks: Tasks are the execution steps required to develop a requirement. You break down user stories into different tasks during sprint
User stories: User stories are requirements that contain a single action and are small enough to start implementing. You you define user stories
and use them at the release and sprint level in Chapter 8.
Page 7 / 11
Reprinted for CTS/316124, Cognizant Technology Solutions
n
once the
Features: Features are parts of products at a very high level. Features describe a new capability the customers will have feature is complete. You
n Epic user stories: Epics are very large requirements that support a feature and contain multiple actions. You need to break down your
will use features in your product roadmap.
lanning in
n
Wiley
& Sons
(US),planning.
John WileyYou
& Sons,
(c)out
2012, Copying Prohibited
Tasks: Tasks are the execution steps required to develop a requirement. You break down user John
stories
into
different
canInc.
find
about tasks and sprint planning in Chapter 8.
Agile Project Management for Dummies
at the user
Keep in mind that each requirement may not go through all these sizes. For example, you may create a particular requirement story level, and never think
y be a lowerof it on the theme
or epic
scale. You
may create
a requirement
at theyou
epicmay
usernot
story
but ittoma
priority requirement.
Because
of user
just-in-time
planning,
priority
requirement.
Because
of just-in-time
planning,
takelevel,
the time
decompose
that lower priority
epic
story until
you
you may not take the time to decompose that lower priority epic user complete development of all the higher-priority requirements.
When you first create your product roadmap, you likely will start with large, high-level requirements. The requirements on your product roadmap
will most likely be at two different levels: themes and features. Themes are logical groups of features and requirements at their highest levels. Features are parts of the
product
at a very
high level.
Features
describe
a new capability
will have
once
the help
feature
is complete.
To identify product themes and
features,
the product
owner
can work
with stakeholders
andthe
thecustomer
development
teams.
It may
to have
a requirements session, where
the stakeholders and the development team meet and write down as many requirements as they can think of.
TIP When you start creating requirements at the theme and feature level, it can help to write those requirements on index cards or big sticky
notes. Using a physical card that you can move from one category to another and back again can make organizing and prioritizing those requirements very easy.
While you are creating the product roadmap, the features you identify start to make up your product backlog — the full list of what is in scope for a product, regardless of
level of detail. Once you have your first requirement, you have your product backlog started.
Step 2: Arranging Product Features
After you identify your product requirements features, you work with the development team to group the requirements into themes — common, logical groups of
requirements. A stakeholder meeting works well for grouping requirements, just like it works for creating requirements. You can group features by usage flow, technical
Here are questions to consider when grouping your requirements:similarity, or business need.
n
n How would customers use our product?
If we offered this requirement, what else would customers need to do? What else might they want to do?
n Can the development team identify technical affinities or dependencies?
Use the answers to these questions to identify your themes. Then group the features by these themes. For example, in the mobile banking application, the themes
might be
n
Account information
n
n
Transactions
Customer service functions
n
Mobile functions
Figure 7-6 shows features grouped by themes.
Page 8 / 11
Reprinted for CTS/316124, Cognizant Technology Solutions
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
Agile Project Management for Dummies
Figure 7-6: Features grouped by themes
If you are using sticky notes, you can group your features on a white board, like the example in Figure 7-7.
Figure 7-7: Requirement categories on a white board
Step 3: Estimating and Ordering the Product's Features
You have identified your product requirements and arranged those requirements into logical groups. Next, you estimate and order the requirements. Here are a
few
terms you need to be familiar with:
n Effort is the ease or difficulty of creating a particular
requirement.
n An estimate, as a noun, can be the number or description you use to express the estimated effort of a requirement.
Page 9 / 11
Reprinted for CTS/316124, Cognizant Technology Solutions
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
Agile Project Management for Dummies
n
n Estimating a requirement, as a verb, means to come up with an approximate idea of how easy or hard that requirement will be to create.
Ordering, or prioritizing, a requirement means to determine that requirement's value in relation to other requirements.
n Value means just how beneficial a particular product requirement might be to the organization creating that product.
TIP You can use the estimating and prioritizing techniques in this section for requirements at any level, from themes and features down to single user stories.
Scoring Requirement Value and Effort
To order requirements, you must first estimate a score to represent the value and effort for each requirement. To order your requirements, you also want to know any
dependencies. Dependencies mean that one requirement is a predecessor for another requirement. For example, if you were to have an application that needs someone
to log in with a username and password, the requirement for creating the username would be a dependency for the requirement for creating the password, because you
generally need a username to set up a password.
Estimating, or scoring, requirements on value and effort is a key first step to ordering those requirements.
You work with two different groups to score your requirements:
n
The product owner, with support from the stakeholders, determines the value of the requirement to the customer and the business.
n
The development team determines the effort to create the requirement for each requirement.
Scrum teams often use the Fibonacci sizing sequence for creating requirement scores. The Fibonacci sequence goes in a progression like this:
1, 2, 3, 5, 8, 13, 21, 34, 55, 89, 144, and so on
Each number after the first two is the sum of the prior two numbers.
REMEMBER The concept of breaking down requirements into smaller pieces is called decomposition.
STUFF
The Fibonacci
named
Leonardo
Fibonacci,
an Italian
mathematician
theas
sequence
in
Use your scoresTECHNICAL
relatively. Choose
a requirement
that sequence
the projectisteam
canafter
agree
has a small
value and
effort, score
it, and usewho
thatdescribed
requirement
a benchmark.
To score
hisorbook
backbenchmark
in 1202! requirement, and whether they are easier or harder than your
other requirements, decide whether other requirements have more
less Liber
value Abaci
than your
benchmark requirement.
When you are creating your product roadmap, your requirements will be on the feature scale. Most of them will have effort scores from 55 to
You
mightwhen
use two
requirements,
one features
for valuedown
and one
for effort.
In the end,
relative
the13absolute
score,
matters.
Next
up is ainformula
144.
Later,
you benchmark
plan releases,
you break your
to epic
user stories
with the
scores
of noscore,
largernot
than
to 34. And
after
you start
planning
sprints,for
your
calculating
relative
priority.
user stories
should have
effort
scores of 1 to 8.
After you have your value and effort scores for your requirements, you can calculate the relative priority of each requirement. Relative priority helps you understand how
one requirement relates to another in terms of value. Once you know the
relative priority
of your
requirements, you can order them on your product roadmap.
Calculating
Relative
Priority
Calculate relative priority with the following formula:
Relative priority = value/effort
For example, if you have a requirement with a value of 89 and an effort of 55, the relative priority would be 1.62 (89/55 = 1.62), which you could round to 2.
Using this formula
n
n
A requirement with high value and low effort will have a high relative priority. For example, if the value is 144 and the effort is 3, the relative priority is 48.
A requirement with a low value and high effort will have a lower relative priority. For example, if the value is 2 and the effort is 89, the relative priority is 0.0224.
n
This formula usually produces fractional results. If you want, you can round those to the nearest whole number.
WARNING! Relative priority is only a tool to help the product owner make decisions and prioritize requirements. It isn't a mathematical universal that you must follow.
Make sure your tools help, rather than hinder.
Note
the relative
priority for
each requirement.
From here, you can review your requirements simultaneously and prioritize them.
Reprinted
for CTS/316124,
Cognizant
Technology Solutions
Page 10 / 11
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
Prioritizing Requirements
Agile Project Management for Dummies
To determine the overall priority for your requirements, answer the following questions:
n
n
n
What is the relative priority of the requirement?
What are the prerequisites for any requirement?
What set of requirements belong together and will constitute a solid release?
Using the answers to these questions, you will be able to place the highest-priority requirements first in the product roadmap. When you have finished prioritizing your
requirements, you will have something that looks like Figure 7-8.
Figure 7-8: Product roadmap with prioritized requirements
Your prioritized list of user stories is called a product backlog. Your product backlog is an important agile document, or in agile terms, an
artifact. You will use this backlog throughout your entire project.
With a product backlog in hand, you can start adding target releases to your product roadmap.
Step 4: Determining High-Level Time Frames
When you first create your product roadmap, your time frames for releasing product requirements will be at a very high level. For the initial roadmap, choose a logical time
increment for your project, such as a certain number of days, weeks, months, quarters (three-month periods), or even larger increments. Using both the requirement the
priority, you can add requirements to each increment of time.
REMEMBER Creating a product roadmap might seem like a lot of work, but after you get the hang of it, you can create one in a short time. Some scrum teams can create a
Saving
Work
product vision, product roadmap, and release plan, and be ready to start their
sprintYour
in as little
as one day! To begin coding the product, you need only enough requirements
for your first sprint. You can determine the rest as the project progresses.
Up until now, you could do all your roadmap planning with white boards and sticky notes. After your first full draft is complete, however, save the product roadmap, especially
if you need to share the roadmap with remote stakeholders or development team members. You could take a photo of your sticky notes and white board, or you could type
the information into a document and save it electronically.
You will update the product roadmap throughout the project, as priorities change. For now, the contents of the first release should be clear —
and that's all you need to worry about at this stage.
Page 11 / 11
Reprinted for CTS/316124, Cognizant Technology Solutions
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
Agile Project Management for Dummies
by Mark C. Layton
John Wiley & Sons (US). (c) 2012. Copying Prohibited.
Reprinted for Jayalakshmi L, Cognizant Technology Solutions
[email protected]
Reprinted with permission as a subscription benefit of Skillport,
http://skillport.books24x7.com/
All rights reserved. Reproduction and/or distribution in whole or in part in electronic,paper or
other forms without written permission is prohibited.
Agile Project Management for Dummies
Chapter 8: Planning Releases and Sprints
In This Chapter
n
Decomposing requirements and creating user stories
n Planning
agilea sprints
n Creating
product backlog, release plan, and sprint backlog
After you create a product roadmap for your agile project (see Chapter 7), it's time to start elaborating on your product details. In this chapter, you discover how to break
down your requirements to a more granular level, refine your product backlog, create a release plan, and build a sprint backlog. First, you will see how to break down the
larger requirements from your product roadmap into smaller, more manageable
requirements
called
user
stories.
REMEMBER The concept of breaking down requirements
into smaller
pieces
is called
decomposition.
Refining Requirements and Estimates
You start agile projects with very large requirements. As the project progresses and you get closer to developing those requirements, you will break them down into smaller
parts.
One clear, effective format for defining product requirements is the user story. The user story and its larger cousin, the epic user story, are good-sized requirements for
release planning and sprint planning. In this section, you find out What
how to is
create
a user
story, how to prioritize user stories, and how to estimate user story effort.
a User
Story?
The user story is a simple description of a product requirement in terms of what that requirement must accomplish for whom. Your user story will have, at a minimum, the
following parts:
n Title: <a name for the user story>
As a <user or persona>
I want to <take this action>
n so that <I get this benefit>
It will also include the following validation steps; steps to take to know that the working requirement for the user story is correct:
n When I <take this action>, this happens <description of action>
User stories may also include the following:
n
n
n
A user story ID: A number to differentiate this user story from other user stories.
n The user story value and effort estimate: Value is how beneficial a user story might be to the organization creating that product. Effort
is the ease or difficulty in creating that user story. You find out how to score user story value and effort later in this chapter.
The name
of so
thetryperson
who cards
thought
of thenotes
userfor
story:
Anyone
on the
project
team
can create
Agile techniques encouragen low-tech
tools,
using index
or sticky
your user
stories.
Even
if you
eventually
wantatouser
usestory.
an electronic tool, it is a good
idea to become familiar with the process of creating user stories first. Once you know how to create user stories, then consider taking on the overhead of complex
electronic tools.
TIP Agile project management approaches encourage low-tech tools, but agile approaches also encourage scrum teams to find out what
works best for each team in each situation. There are a lot of electronic user story tools out there. Some cost money; some are free. Some are simple, and are just for user
stories. Others are complex and will integrate with your other product documents. Personally, I love index cards,
but that solution may not be for everyone. Use what works best for your scrum team and for your project.
Figure 8-1 shows a typical user story card, back and front. The front has the main description of the user story. The back shows how you will confirm that the requirement
works correctly, after the development team has created the requirement.
Page 2 / 14
Reprinted for CTS/316124, Cognizant Technology Solutions
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
Agile Project Management for Dummies
Figure 8-1: Card-based user story example
The product owner gathers and manages the user stories. However, the development team and other stakeholders also will be involved in creating and decomposing
user stories.
TIP It's important to note that user stories aren't the only way to describe product requirements. You could simply make a list of requirements without any given structure.
However, because user stories include a lot of useful information in a simple, compact format, I find them to be very effective at conveying exactly what a requirement needs
to do.
The big benefit of the user story format is when the development team starts to create and test requirements. The development team members know exactly whom they are
creating the requirement for, what the requirement should do, and how to double-check that the requirement satisfies the intention of the requirement.
to examples
Create aofUser
Story throughout this chapter and throughout the book. Keep in mind that anything I describe that you can do with user stories, you
I use user Steps
stories as
requirements
can do with more generically expressed requirements.
creating a
user
story, stakeholders.
follow these steps:
1.When Identify
the
project
2.
3.
Identify who will use the product.
Working with the stakeholders, write down the requirements that the product will need and use the format I describe earlier
in this chapter to create your user stories.
Find out how to follow these three steps in the following sections.
REMEMBER Agile is iterative. Don't spend a ton of time trying to identify every single requirement your product might have. You can always add requirements later in the
project. The best changes often come at the end of a project, when you know the most about the product and the customers.
Identifying Project
Stakeholders
You probably
have a good idea about who your project stakeholders are — anyone involved with, or affected by, the product and its creation.
REMEMBER You will also work with stakeholders when you create your product vision and your product roadmap.
Make sure the stakeholders are available to help you create requirements. Stakeholders might include
n
n
People who interact with customers on a regular basis, such as customer service representatives or bank branch personnel.
Business experts for the different areas where your product's customers interact. For example, XYZ Bank, the sample company I tell you about in Chapter 7, might
have one manager in charge of checking accounts, another manager in charge of savings accounts, and a third manager in charge of online bill payment services. If
you're creating a mobile banking application, all these people would be project stakeholders.
n
Users of your product, if they are available.
n
Experts on the type of product you are creating. For example, a developer who has created mobile applications, a marketing manager who knows how to create
mobileTechnical
campaigns,
and a user people
experience
specializes
mobile
interfaces
all with
mightyour
be helpful
stakeholders,
who specialist
work with who
the systems
thatinmight
need
to interact
product.on the sample XYZ Bank mobile banking project.
Identifying Customers
When thinking about the customers who will use your product, it's often helpful to assign them personas, such as a salesperson or a customer service representative.
n
TECHNICAL STUFF Development teams of all types often create personas, character descriptions of people who are likely to use a
Page 3 / 14
Reprinted for CTS/316124, Cognizant Technology Solutions
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
Agile Project Management for Dummies
product. Think of a persona as a character in a book or a movie. You can give a persona its own background: a name, age, gender, job, likes, dislikes, and needs. Using
personas can help you understand exactly what your product may need to do.
You can also think of personas in terms of specific representatives of those roles, such as someone in a particular demographic or a type of user. An example is a 30REMEMBER Keep the customer you
described
in your
productdirector
vision statement
in mind
when
creating personas. You can find out more
something
female
marketing
who travels
a lot on
business.
about the vision statement in Chapter 7.
Suppose that you are the product owner for the XYZ Bank's mobile banking project described previously. You are responsible for the department that will bring the product
to market, preferably in the next six months. You have the following ideas about the application's users:
n
n
n Maybe
customers
are probably
about to buy
large-ticket
and they want
to make
suretheir
theybalances
can charge
it.recent transactions.
The customers (the end
users the
of the
application)
wanta quick
accessitem,
to up-to-date
information
about
and
Maybe the customers' ATM cards were just refused, but they have no idea why, and they want to check recent transactions for possible fraudulent activities.
n
Maybe the customers just realized that they forgot to pay their credit card bill and will have penalty charges if they don't pay the card today.
Who are your personas for this application? Here are a few examples:
n
n
Persona #1:nJason
is a young,
tech-savvy
executive who
travels
lot. When
he has when
a spare
moment,
he wants
to their
handle
personal
quickly. He carefully
Persona
#2: Carol
is a small-business
owner
whoastages
properties
clients
are trying
to sell
home.
She business
shops at consignment
centers
and sees aportfolios.
couch sheHe
wants
to buy
for a client.
invests his money
in high-interest
keeps
his available
cash low.
Persona #3: Nick is a student who lives on student loans and a part-time job. He knows he can be flaky with money because he's flaky with everything else. He just
lost his checkbook.
Determining
Product Requirements
and Creating
TIP Your
product stakeholders
can help you create
personas.User
Find Stories
people who are experts on the day-to-day business for your product. Those stakeholders will know
After you have identified your different customers, ayou
start
to potential
determine
product requirements and create user stories for the personas. A
lot can
about
your
customers.
good way to create user stories is to bring your stakeholders together for a user story creation session.
Have the stakeholders write down as many requirements as they can think of, using the user story format. One user story for the project and personas from the preceding
sections might be
n Front side of card:
As a busy, tech-savvy, on-the-go customer of XYZ Bank (Jason)
¡ I want to see my checking account balance on my smartphone
¡ Title: See bank account balance.
¡ so that I can see how much money I have in my checking account
n Back side of card:
¡
¡
When I sign into the XYZ Bank mobile application, my checking account balance appears at the top of the page.
¡ When I sign into the XYZ Bank mobile application after making a purchase or a deposit, my checking account balance reflects that
purchase or deposit.
You can see sample user stories in card format in Figure 8-2.
Page 4 / 14
Reprinted for CTS/316124, Cognizant Technology Solutions
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
Agile Project Management for Dummies
Figure 8-2: Sample user stories
REMEMBER Be sure to continuously add new user stories to your product backlog. Keeping your product backlog up-to-date will help you
have the highest priority user stories when it is time to plan your sprint.
Throughout an agile project, you will create new user stories. You will also take existing large requirements and decompose them until they are manageable enough to work
on during a sprint.
Breaking down Requirements
n
You will refine requirements many times throughout an agile project. For example:
When you create the product roadmap (see Chapter 7), you create features, a capability your customers will have after you develop the feature that they don't have
prior, as well as themes, which are logical groups of features. Although features are intentionally large, at Platinum Edge, we require features at the product roadmap
level to be no larger than 144 story points.
When you plan releases, you break down the features into more concise user stories. User stories at the release plan level can be either epics, very large user stories
with multiple actions, or individual user stories that will contain a single action. For our clients, user stories at the release plan level should be no larger than 34 story
points. You find out more about releases later in this chapter.
n
When you plan sprints, you can break down user stories even further. You also identify individual tasks associated with each user story in the sprint. For our clients,
user stories at the sprint level should be no larger than eight story points.
To decompose requirements, you will want to think about how to break the requirement down into individual actions. Table 8-1 shows a requirement decomposed
from the theme
leveleffort
down
the user
story level.
REMEMBER A story point is a relative score to represent
value and
fortoeach
requirement.
Scrum teams often use numbers in the Fibonacci sequence —
where each number after the first two is the sum of the prior two numbers — for their story points. You can find out more about story points and the Fibonacci sequence in
Table 8-1: Decomposing a Requirement
Requirement Level
Chapter 7. Requirement
n
Theme
Features
See account data with a mobile application.
See account balances.
See a list of recent withdrawals or purchases.
See a list of recent deposits.
Epic User Stories — decomposed from "see account balances"
User Stories — decomposed from "see checking account balance"
See my
upcoming
automatic
bill payments.
See checking
account
balance.
See savings
See investment
my accountaccount
alerts.
account balance. See
balance. See retirement account balance.
Log into mobile account.
Securely log into mobile account.
Page 5 / 14
Reprinted for CTS/316124, Cognizant Technology Solutions
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
Agile Project Management for Dummies
See a list of my accounts.
Select and view my checking account.
See account balance changes after withdrawals.
See account balance changes after purchases.
See day's end account balance.
See available account balance.
Estimation Poker
See mobile application navigation items.
Change account view.
Logtime
out of
As you refine your requirements, you need to refine your estimates as well. It's
tomobile
have application.
some fun!
One of the most popular ways of estimating user stories is by playing estimation poker, sometimes called Planning Poker, a game to determine user story size
and to build consensus with the development team members.
REMEMBER The scrum master can help coordinate estimation, and the product owner can provide information about features, but the development team is
responsible for estimating the level of effort required for the user stories. After all, the development team has to do the work to create the features that those stories
User stories and the INVEST approach
describe.
You
may just
be asking,
just how decomposed
user story
to be? in
Billhis
Wake,
in XP123.com
his blog at XP123.com
describes
thetoINVEST
You may be
asking,
how decomposed
does a userdoes
storya have
to be?have
Bill Wake,
blog at
describes the
approach
ensure
quality in user stories. I like his method so much I include it here.
n
Independent: To the extent possible,
a the
story
should approach,
need no other
implement
Using
INVEST
userstories
storiestoshould
be the feature that the story describes.
n Independent: To the extent possible, a story should need no other stories to implement the feature that the story
task. The story is in the user's language and is easy to explain. The people using the product or system can understand the story.
n Negotiable: Not overly detailed. There is room for discussion and expansion of details.
n
Valuable: The
story demonstrates product value to the customer. The story describes features, not a single-thread start-to task. The story is in the
n Small: It is easier to plan and accurately estimate small user stories. A good rule of thumb is that a user story should not take one
user's language and is easy to explain. The people using the product or system can understand
-finish user
n Estimable: The story is descriptive, accurate, and concise, so the developers can generally estimate the work necessary functionality in the user
to create the
To play estimation poker, you need a deck of cards like the one in Figure 8-3. story.
You can get them online at my website (www.platinumedge.com/estimationpoker), or you
can make your own with index cards and markers. The numbers on the cards are from the Fibonacci sequence.
n Small: It is easier to plan and accurately estimate small user stories. A good rule of thumb is that a user story should not person on the
development team longer than half of a sprint to complete.
n
Testable: You can easily validate the user story, and the results are definitive.
Figure 8-3: A deck of estimation poker cards
Only the development team plays estimation poker. The scrum master and product owner don't get a deck and don't provide estimates. However, the scrum master
can act as a facilitator, and the product owner will read the user stories and provide details on user stories as needed.
Page 6 / 14
Reprinted for CTS/316124, Cognizant Technology Solutions
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
Agile Project Management for Dummies
To play estimation poker, follow these steps:
1.
Provide each member of the development team with a deck of estimation poker cards.
2.
Starting with a simple user story, the players decide on an estimate — as a story point — that they can all agree on for that
user story.
This user story becomes the baseline story.
3.
The product owner reads a high-priority user story to the players.
4.
Each player selects a card representing his or her estimate of the effort involved in the user story and lays the card facedown on the table.
The players should compare the user story to other user stories they have estimated. (The first time through, the players compare the user story only to the
baseline story.) Make sure no other players can see your card.
5.
Once each development team member selects a card, all players turn over their cards simultaneously.
6.
If the players have different story points:
a.
It's time for discussion.
The players with the highest and lowest scores talk about their assumptions and why they think the estimate for the user story should be higher or lower,
respectively. The players compare the effort for the user story against the baseline story. The product owner provides more information about the story, as
necessary.
b.
Once everyone agrees on assumptions and has any necessary clarifications, the players reevaluate their estimates and place their new selected cards
c.
on the table.
d.
If the story points are different, the players repeat the process, usually up to three times.
7.
The players repeat Steps 3 through 6 for each user story.
If the players can't
agreeeach
on the
estimated
effort, the
scrum—
master
helps the
development
a score
that you
all the
players
can support or
REMEMBER
Consider
part
of the definition
of done
developed,
integrated,
tested,team
and determine
documented
— when
create
estimates.
thatplay
the user
story
requires
more development
detail or needs
to as
be you
further
broken down.
You can play estimation poker at any point —determine
but definitely
during
product
roadmap
and
progressively
break down user stories for inclusion in
releases and sprints. With practice, the development team gets into a planning rhythm and becomes more adept at quickly estimating.
TIP On the average, development teams will spend about ten percent of their time on a project estimating and re-estimating. Make your estimation poker games fun!
Bring in snacks, use humor, and keep the mood light to help speed the task of estimating.
Affinity Estimating
Estimation poker can be effective, but what if you have many user stories? Playing estimation poker for, say, 500 user stories could take a long time. You need a way to
focus only on the user stories you need to discuss to gain consensus.
When you have a large number of user stories, many of them are probably similar and would require a similar amount of effort to complete. One way to determine the right
stories for discussion is to use affinity estimating. In affinity estimating, you quickly categorize your user stories and then apply estimates to these categories of stories.
Affinity
can be by
a fast
and write
furious
activity
the development
team
may choose
to havetypes
the scrum
help facilitate
sessions. stories.
To
TIP estimating
When estimating
affinity,
your
user —
stories
on index cards
or sticky
notes. These
of usermaster
story cards
work wellaffinity
when estimating
quickly categorizing
estimate by affinity, follow these steps:
1. Taking no more than one minute for each category, the development team agrees on a single user story in each of the following categories:
a.
Extra-small user story
b.
Small user story
c.
e.
d.
f.
Medium user story
Extra-large user story
Large user story
Epic user story that is too large to come into the sprint
Page 7 / 14
Reprinted for CTS/316124, Cognizant Technology Solutions
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
Agile Project Management for Dummies
The sizes are like T-shirt sizes and should correspond to Fibonacci scale numbers, as shown in Figure 8-4. You can find out about
Fibonacci scale numbers in Chapter 7.
2.
3.
4.
5.
Figure 8-4: Story sizes as T-shirt sizes and their Fibonacci numbers
Taking no more than 30 seconds per user story, the development team puts all remaining stories into the categories listed
in Step 1.
If you're using index cards or sticky notes for your user stories, you can physically place those cards into categories on a table or a whiteboard, respectively. If you
split the user stories among the development team members, having each development team member categorize a group of stories, this step can go quickly!
Taking another 60 minutes, maximum, for each 100 stories, the development team reviews and adjusts the placement of the user stories.
The entire development team must agree on the placement of the user stories into size categories.
The product owner reviews the categorization.
When the product owner's expected estimate and the team's actual estimate differ by more than one story size, they
discuss that user story.
The development team may or may not decide to adjust the story size.
REMEMBER Note that after the product owner and the team discuss clarifications, the team has final say on the user story size.
User stories in the same size category will have the same user story score. You can play a round of estimation poker to double-check a few, but you won't need to waste
time in unnecessary discussion for every single user story.
TIP You can use the estimating and prioritizing techniques in this chapter for requirements at any level, from themes and features down to
single user stories.
Release Planning
A release, in agile terms, is a group of usable product features that you release to production. A release does not need to include all the functionality outlined in the roadmap
but should include at least the minimal marketable features, the smallest group of product features that you can effectively deploy and promote in the marketplace. Your
early releases will exclude many of the medium- and low-priority requirements you created during the product roadmap stage.
When planning a release, you establish the next set of minimal marketable features and identify an imminent product launch date around which the team can mobilize. As
when creating the vision statement and the product roadmap, the product owner is responsible for creating the release goal and establishing the release date. However, the
development team, with the scrum master's facilitation, contributes to the process.
Release planning is Stage 3 in the Roadmap to Value (refer to Figure 7.1 in Chapter 7 to see the roadmap as a whole). Figure 8-5 shows how release planning fits into an
agile project.
Page 8 / 14
Reprinted for CTS/316124, Cognizant Technology Solutions
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
Agile Project Management for Dummies
Figure 8-5: Release planning as part of the Roadmap to Value
Release planning involves completing two key activities:
n
Revising the product backlog: In Chapter 7, I told you that the product backlog is a comprehensive list of all the user stories you currently know for your project,
whether or not they belong in the current release. Keep in mind that your list of user stories will probably change throughout the project.
Release plan: The release goal, release target date, and prioritization of product backlog items that support the release goal. The release plan provides a
WARNING! Don't create a new, separate backlog
during
release
planning.
The
task is unnecessary and reduces the product owner's
midrange
goal
that the
team can
accomplish.
flexibility. Prioritizing the existing product backlog based on the release goal is sufficient and enables the product owner to have the latest information when he or she
commits communication
to scope duringchannels
sprint planning.
The product backlog and release plan are some of the most important
between the product owner and the team. The following sections describe
n
how to complete a product backlog and a release plan.
Completing the Product Backlog
As Chapter 7 explains, the product roadmap contains themes, epic user stories, and some tentative release timelines. The requirements on your product roadmap are the
firstproject.
versionThe
of your
product
backlog.
The product backlog is the list of all user stories associated with the
product
owner
is responsible for creating and maintaining the product backlog by adding
and prioritizing user stories. The scrum team uses the backlog during release planning and throughout the project.
Figure 8-6
shows a sample product backlog. At a minimum, when creating your product backlog, be sure to
n Include a description of your requirement.
n
n Order the user stories based on priority. You can find out how to determine priority in Chapter 7.
Add the effort estimate.
Figure 8-6: Product backlog sample
REMEMBER In Chapter 2, I explain how documents for agile projects should be barely sufficient, with only information that is absolutely
necessary to create the product. Keep your product backlog format simple and barely sufficient, and you will save time on updating it throughout the project.
The scrum team refers to the product backlog as the main source for project requirements. If a requirement exists, it is in the product backlog. The user stories in your
product backlog will change throughout the project in several ways. For example, as the team completes user stories, you mark those stories as complete within the
backlog. You also record any new user stories. Additionally, you update the priority and effort
Page 9 / 14
Reprinted for CTS/316124, Cognizant Technology Solutions
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
Agile Project Management for Dummies
scores of existing user stories as needed.
The total number of story points in the product backlog — all user story points added together — is your current product backlog estimate. This estimate changes daily as
user stories are completed and new user stories are added. Discover more about using the product backlog estimate to predict the project length and cost in Chapter 13.
REMEMBER Keep your product backlog up to date so that you always have accurate cost and schedule estimates. A current product
backlog also gives you the flexibility to prioritize new product features — a key benefit of agile — against existing features.
After you have a product backlog, create your first release plan, as described next.
Creating the Release Plan
The release plan contains a release schedule for a specific set of features. The product owner creates a release plan at the start of each release. To create a release
1.
Establish the release goal.
plan, follow these steps:
The release goal is an overall business goal for the product features in your release. The product owner and development team collaborate to create a release
goal based on business priorities, the development team's development speed, and the development team's capabilities.
2.
Review the product backlog and the product roadmap to determine the highest-priority user stories that support your release goal.
These user stories will make up your first release. I like to have my releases be achieved with about 80 percent of the user stories, using the final 20 percent to add
robust features that will meet the release goal while adding to the product's "wow" factor.
3.
Determine a date for the release.
The release date is typically at least three sprints out, but the actual date depends on your specific project. Some scrum teams determine release dates
based on completion of functionality; others may have hard dates, like March 31 or September 1.
TIP Some project teams add a release sprint to each release in order to conduct activities that are not related to product development,
but still necessary to release the product to customers. If you need a release sprint, be sure to factor that into the date you choose. You can find more about release
sprints in Chapter 11.
4.
Consult the development team when
updating
your revised
stories.
If you
haven'testimates
done so for
already,
refineuser
the user
stories in your release goal.
5.
Get the development team's buy-in and commitment for the first release.
Be sure you have consensus on both the release date and the release goal.
TIP Not all agile projects use release planning. Some scrum teams release functionality for customer use with every sprint. The development team, product, organization,
customers, stakeholders, and technological complexity can all help determine your approach to product releases.
The planned releases now go from a tentative plan to a more concrete goal. Figure 8-7 represents a typical release plan.
Figure 8-7: Sample release plan
TIP Bear in mind the pen-pencil rule: You can commit to (write in pen) the plan for the first release, but anything beyond the first release is
tentative (written in pencil). In other words, use just-in-time planning (see Chapter 7) for each release. After all, things change, so why bother getting microscopic too
early?
Sprint Planning
In agile projects, a sprint is a consistent iteration of time in which the development team creates a specific group of product capabilities from
Page 10 / 14
Reprinted for CTS/316124, Cognizant Technology Solutions
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
Agile Project Management for Dummies
start to finish. At the end of each sprint, the product that the development team has created should be working and ready to demonstrate.
Sprints should be the same length within a project. Keeping the sprint lengths consistent helps you measure the development team's performance and plan better
at each new sprint.
Sprints generally last one, two, three, or four weeks. Four weeks is the longest amount of time any sprint should last; longer iterations make changes riskier, defeating
Each sprint includes the following:
the purpose of agile.
n
Sprint planning at the beginning of the sprint
n Daily scrum meetings
n
Development time — the bulk of the sprint
n
A sprint review and a sprint retrospective at the end of the sprint
Discover more about daily scrums, sprint development, the sprint review, and the sprint retrospective in Chapters 9 and 10. In this chapter, you find out how to plan sprints.
Sprint planning is Stage 4 on the Roadmap to Value, as you can see in Figure 8-8. The entire scrum team — the product owner, the scrum master, and the development
team — works together to plan sprints.
Figure 8-8: Sprint planning as part of the Roadmap to Value
The Sprint Backlog
The sprint backlog is a list of user stories associated with the current sprint and related tasks. When planning your sprint, you
n Establish goals for your sprint.
n
n
Choose the user stories that support those goals.
Break user stories into specific development tasks.
n Create a sprint backlog. The sprint backlog includes
¡
The list of user stories within the sprint in order of priority.
¡
The relative effort estimate for each user story.
¡ The tasks necessary to develop each user story.
At the task
level, you estimate the number of hours each task will take to complete, instead of using story points. Since your sprint has a specific length, and thus
a set number of available working hours, you can use the time each task takes to determine whether the tasks will fit into your sprint.
¡ The effort, in hours, to complete each task.
¡
Each task should take one day or less for the development team to complete.
A burndown chart, which shows the status of the work the development team has completed.
TECHNICAL STUFF Tasks in agile projects should take a day or less to complete for two reasons. The first reason involves basic psychology: People are motivated to get
to the finish line. If you have a task that you know you can complete quickly, you are more likely to finish it on time, just to check it off your to-do list. The second reason is
that one-day tasks provide good red flags that a project might be veering off course. If a development team member reports that he or she is working on the same task for
more than one or two days, that team
member probably has a roadblock. The scrum master should take the opportunity to investigate what might be keeping the team member from finishing work. (For more on
managing roadblocks, see Chapter 9.)
The development team collaborates to create and maintain the sprint backlog, and only the development team can modify the sprint backlog. The sprint backlog should
Page 11 / 14
reflect anforup-to-the-day
snapshot
of the sprint's
progress. Figure 8-9 shows a sample sprint backlog. You can use this example, find other samples, or even use a white
Reprinted
CTS/316124, Cognizant
Technology
Solutions
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
board.
Agile Project Management for Dummies
Figure 8-9: Sprint backlog example
The Sprint Planning Meeting
On the first day of each sprint, often a Monday morning, the scrum team holds the sprint planning meeting.
Base the length
of your
planning
meeting
on the
length make
of yoursure
sprints:
Meet involved
for no more
than
two hours
for everyto
week
of your
Thismeeting.
timebox is one of the
TIP
For asprint
successful
sprint
planning
meeting,
everyone
in the
session
is dedicated
the effort
forsprints.
the entire
rules of scrum. Figure 8-10 illustrates this and is a good quick reference for your meeting lengths.
Figure 8-10: Sprint planning meeting to sprint length ratio
TECHNICAL STUFF On agile projects, the practice of limiting the time of your meetings is sometimes called timeboxing. Keeping your
meetings timeboxed ensures that the development team has the time it needs to create the product.
You will split your sprint planning meetings into two parts: one to set a sprint goal and choose user stories for the sprint, and another to break down your user stories into
individual tasks. The details on each part are discussed next.
In the first part of your sprint planning meeting, the product owner and development team, with support from the scrum master, do the following:
Part 1: Setting Goals and Choosing User Stories
1. Discuss and set a sprint goal.
Page 12 / 14
Reprinted for CTS/316124, Cognizant Technology Solutions
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
Agile Project Management for Dummies
2. Review the user stories from the product backlog that support the sprint goal and revisit their relative estimates.
3. Determine what the team can commit to in the current sprint.
At the beginning of your sprint planning meeting, the product owner and the development team should determine a goal for the sprint. The sprint goal should be an overall
description supported by the highest-priority user stories in the product backlog. A sample sprint goal for the mobile banking application (refer to Chapter 7) might be
As a mobile banking customer, I want to log in to my account so I can view my account balances and pending and prior transactions.
Using the sprint goal, you determine the user stories that belong in this sprint. You also take another look at the estimates for those stories and make changes to the
estimates if you need to. For the mobile banking application sample, the group of user stories for the sprint might include
n
Log in and access my accounts.
n
n
View account balances.
View pending transactions.
n
View prior transactions
All these would be high-priority user stories that support the sprint goal.
The second part of reviewing user stories is confirming that the effort estimates for each user story look correct. Adjust the estimate if necessary. With the product
owner in the meeting, resolve any outstanding questions.
Finally, once you know which user stories support the sprint goal, the development team should agree and confirm it can complete the goal planned for this sprint. If any of
In the the
second part
of the
planning
meeting,
theinscrum
team sprint,
does the following:
stories
yousprint
discussed
earlier
don't
theuser
current
them
from
the
sprint
and add themeach
backpart
intoof
the
product
backlog.
1.
Create user
the sprint
backlog
tasks associated
withfiteach
story. Makeremove
sure that
there
are
tasks
encompassing
the
definition
of done:
developed,
integrated,
tested,
and future
documented.
WARNING! Always plan and work one sprint at a time. Don't
place user
stories into
specific
sprints — it's an easy trap to fall into. For example, don't decide that
2.
user story
X
should
go
into
sprint
3
or
4.
Instead,
keep
the
ordered
list
of
user
stories
up
to
date
the product backlog
Double-check that the team can complete the tasks in the time available in the sprint. Eachindevelopment
team and focus on always developing the remaining
highest-priority stories. Commit only to planning for the current sprint.
3.
TIP
Developmentmember
team members
should
onher
only
one
task
one user story at a time to enable swarming — the practice of having the
shouldrequirement
choosework
his or
first
task
to on
accomplish.
wholeadevelopment
team
work on
until
completion.
a very
efficient
to complete
work
in a short
of time. meeting
Once you have
sprint goal, user
stories
for one
the sprint, and commitment
to the Swarming
goal, movecan
on be
to the
second
part way
of sprint
planning.
Because
youramount
sprint planning
may last a few hours, you might want to take a break between the two parts of the meeting.
At the beginning of part two of the meeting, break the user stories into individual tasks and allocate a number of hours to each task. The development team should target
being able to complete a task in a Part
day or2:less.
For example,
a user
forBacklog
the XYZ Bank mobile application might be
Creating
Tasks for
the story
Sprint
Log in and access my accounts.
The team decomposes this user story into tasks, like the following:
n
Create an authentication screen for a username and password, with a Submit button.
n
n
Create an error screen for the user to reenter credentials.
Create a logged-in screen (includes list of accounts — to be completed in next user story).
n Using
codedo
from
the check
online to
banking
application,
for an
iPhone/iPad
Once you know the number of hours
that authentication
each task will take,
a final
make sure
that the rewrite
numbercode
of hours
available
to the application.
development team reasonably matches
the total of the tasks' estimates. If the tasks exceed the hours available, one or more user stories will have to come out of the sprint. Discuss with the product owner what
n Create calls
toor
the
database
verify
the username
tasks
user
stories to
are
the best
to remove.and password.
n Refactor
forbe
mobile
devices.
If extra time is available within the sprint, the development
teamcode
might
able to
include another user story. Just be careful about over-
Reprinted for CTS/316124, Cognizant Technology Solutions
Page 13 / 14
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
Agile Project Management for Dummies
committing at the beginning of a sprint, especially in the project's first few sprints.
After you know which tasks will be part of the sprint, choose what you will work on first. Each development team member should select his or her initial task to accomplish
for the sprint. Team members should focus on one task at a time.
TIP As the development team thinks about what they can complete in a sprint, use the following guidelines to ensure that they don't take on more work than they can
handle:
n Sprint 2: 50 percent of what the team thinks it can accomplish.
n
Sprintn 3:
75 percent
of what of
thewhat
team
thinks
can accomplish.
Sprint
1: 25 percent
the
teamitthinks
it can accomplish. Include overhead for learning the new process and starting a new project.
n Sprint 4 and forward: 100 percent. The team will have developed a rhythm, gained insight into agile and the project, and will be working
at close to full pace.
The team should constantly evaluate the sprint backlog against the development team's progress on the tasks. At the end of the sprint, the team can also assess
estimation skills and capacity for work. This evaluation is especially important for the first sprint.
TECHNICAL STUFF For the sprint, how many total working hours are available? In a 40-hour week, you could wisely assume, for a two- week sprint, that nine working
days are available to develop user stories. If you assume each full-time team member has 35 hours per week (seven productive hours per day) to focus on the project,
the number of working hours available is
Number of team
× 7 hours
× 9working
days on the tasks to create the product!
After the sprint planning is finished, the development
teammembers
can immediately
start
Why
nine
days?
Half of
day one
is taken
planning,
and half
of day
ten is taken
up with
the sprint
the stakeholders
review thetocompleted
and the
The
scrum
master
should
make
sure up
thewith
product
roadmap,
product
backlog,
and sprint
backlog
arereview
all in a(when
prominent
place and accessible
everyone.work)
This allows
sprintand
retrospective
(when parties
the team
improvements
futureonsprints).
That
leaves
nine daysthe
of development.
managers
other interested
to identifies
view the artifacts
and getfor
status
progress
without
interrupting
development team.
Page 14 / 14
Reprinted for CTS/316124, Cognizant Technology Solutions
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
Agile Project Management for Dummies
by Mark C. Layton
John Wiley & Sons (US). (c) 2012. Copying Prohibited.
Reprinted for Jayalakshmi L, Cognizant Technology Solutions
[email protected]
Reprinted with permission as a subscription benefit of Skillport,
http://skillport.books24x7.com/
All rights reserved. Reproduction and/or distribution in whole or in part in electronic,paper or
other forms without written permission is prohibited.
Agile Project Management for Dummies
Chapter 1: Modernizing Project Management
In This Chapter
n
Understanding why project management needs to change
Agile projectn management
is a style
project
management that focuses on early delivery of business value, continuous improvement of the project's product and
Finding out about
agileof
project
management
processes, scope flexibility, team input, and delivering well-tested products that reflect customer needs.
In this chapter, you find out why agile processes emerged as an approach to software development project management in the mid-1990s and why agile methodologies have
caught the attention of project managers, customers who invest in the development of new software, and executives whose companies fund software development
departments. This chapter also explains the advantages of agile methodologies over long-standing approaches to project management.
Project Management Needed Makeover
A project is a planned program of work that requires a definitive amount of time, effort, and planning to complete. Projects have goals and objectives and often must be
completed in some fixed period of time and within a certain budget.
If you approaches
are reading this
book,
it's likely
thatneed
you are
either a project
manager,
or you To
areunderstand
someone who
projects, works
on projects, or projects,
is affected
by projects
in some
Agile
are a
response
to the
to modernize
project
management.
howinitiates
agile approaches
are revolutionizing
it helps
to know
a
way.
little about the history and purpose of project management
and the issues that projects face today.
The Origins of Modern Project Management
Projects have been around since ancient times. From the Great Wall of China to the Mayan pyramids at Tikal, from the invention of the printing press to the invention of the
Internet, people have accomplished endeavors big and small in projects.
As a formal discipline, project management as we know it has only been around since the middle of the twentieth century. Around the time of World War II, researchers
around the world were making major advances in building and programming computers, mostly for the United States military. To complete those projects, they started
creating formal project management processes. The first processes were based on step-by- step manufacturing models the United States military used during World War II.
People in the computing field adopted these step-based manufacturing processes because early computer-related projects relied heavily on hardware, with computers
that filled up entire rooms. Software, by contrast, was a smaller part of computer projects. In the 1940s and ‘50s, computers might have thousands of physical vacuum
tubes but fewer than 30 lines of programming code. The 1940s’ manufacturing process used on these initial computers is the foundation of the project management
methodology known as waterfall.
1.
Requirements.
2.
Design.
In 1970, a computer scientist named Winston Royce wrote "Managing the Development of Large Software Systems," an article for the IEEE that described the phases in
the 3.
waterfall
methodology. The term waterfall was coined later, but the phases, even if they are sometimes titled differently, are essentially the same as originally defined by
Development.
4.
Integration.
Royce:
5.
6.
Testing.
Deployment.
On waterfall projects, you move to the next phase only when the prior one is complete — hence, the name waterfall.
TECHNICAL STUFF Pure waterfall project management — completing each step in full before moving to the next step — is actually a
misinterpretation of Royce's suggestions. Royce identified that this approach was inherently risky and recommended prototyping and working within iterations to create
products
— suggestions
were overlooked
by many
that adopted
methodology.
Until improved approaches based
on agile
techniques that
surpassed
it around 2008,
the organizations
waterfall methodology
was the
the waterfall
most common
project management approach in
software development.
Software project success and failure
Unfortunately, the stagnation in project management approaches is catching up with the software industry. In 2009, a software company called the
Standish Group did a study on software project success and failure in the United States. The results of the
statistical
study
Page 2 / 6
Reprinted for CTS/316124, Cognizant Technology Solutions
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
Agile Project Management for Dummies
showed that
n
n
24% of projects failed outright. This means that the projects were cancelled before they finished, and did not result in any releases. These projects
delivered
valuefinished,
whatsoever.
n 44% of projects were challenged. This means
that the no
projects
but they had gaps between expected and actual
product cost,
time,
44% of projects were challenged. This means that the projects finished, but they had gaps between expected and actual quality, or a combination of
n
32%
of
projects
succeeded.
This
means
the
projects
finished
and
delivered
the
expected
product
in
the
originally
expected
time
and
oking at time,
these elements. The average difference between the expected and actual project results — lo cost, and features not delivered — was 189%.
n
In 2009,
companies
and organizations
theprojects
U.S. spent
$491.2
on application
development.
Thatoriginally
means that
more than $103 billion
32%
of projects
succeeded.
This meansinthe
finished
andbillion
delivered
the expected
product in the
budget.
In 2009, companies and organizations in the U.S. spent $491.2 billion on application development. That means that more was wasted on failed
The Problem
with the Status Quo
projects.
Computer technology has, of course, changed a great deal since the last century. I have a computer in my pocket with more power, memory, and capabilities than the
largest, most expensive machine that existed when people first started using waterfall methodologies — and my computer has a telephone attached.
At the same time, the people using computers have changed as well. Instead of creating behemoth machines with minimal programs for a few researchers and the military,
people create hardware and software for the general public. In many countries, almost everyone uses a computer, directly or indirectly, every day. Software runs our cars; it
provides our daily information and daily entertainment. Even tiny children use computers — my friends' two-year-old is almost more adept with the iPhone than her parents.
The demand for newer, better software products is constant.
Somehow, during all this growth of technology, the processes were left behind. Software developers are still using project management methodologies from the
1950s, and these approaches were all derived from manufacturing processes meant for the hardware-heavy computers of the mid-twentieth century.
Today traditional projects that do succeed often suffer from one problem: scope bloat, the introduction of unnecessary product features in a project.
Think about the software products you use every day. For example, the word-processing program I'm typing on right now has a lot of features and tools. Even though I
write on this program every day, I use only some of the features all the time. There are some elements that I use less frequently. There are quite a few tools that I have never
used, and come to think of it, I don't know anyone else who has used them, either. These features that few people or no one uses are the result of scope bloat.
Scope bloat appears in all kinds of software, from complex enterprise applications, to websites that everyone uses. The chart in Figure 1-1 shows data from another
Standish Group study that illustrates just how common scope bloat is. In the figure, you can see the proportion of requested features that are actually used when the
software goes into production. Sixty-four percent of the features are rarely or never used.
Copyright 2011 by Standish Group.
Page 3 / 6
Reprinted for CTS/316124, Cognizant Technology Solutions
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
Agile Project Management for Dummies
Figure 1-1: Actual use of software features
The numbers in Figure 1-1 illustrate an enormous waste of time and money. That waste is a direct result of traditional project management processes that are unable to
accommodate change. Project managers and stakeholders know that change is not welcome mid-project, and that their best chance of getting a potentially desirable
feature is at the project start, so they ask for
n
n
Everything they think they may need
n
n
Everything they need
Everything they want
Everything they think they may want
The result is the bloat in features that results in the statistics in Figure 1-1.
Introducing
Agile
Projectare
Management
The problems associated with using outdated management and
development
approaches
not trivial. These problems waste billions of dollars a year. The $103 billion
lost in project failure in 2009 (see the sidebar, "Software project success and failure") could equate to millions of jobs around the world.
The seeds for agile techniques have been around for a long time. Figure 1-2 shows a quick history of agile project management, dating back to the 1930s with Walter
Sherwart's
(PDSA)
approach
project quality.
Over the past two decades, people working on projects
have Plan-Do-Study-Act
recognized the growing
problems
withtotraditional
project management and have been working to create a
better model: agile project management.
Figure 1-2: Agile project management timeline
In 1986, Hirotaka Takeuchi and Ikujiro Nonaka published an article called "New New Product Development Game in the Harvard Business
Review." Takeuchi and Nonaka's article described a rapid, flexible development strategy to meet fast-paced product demands. This article
first coined the term scrum in conjunction with product development, comparing product development to a game of rugby. Scrum eventually became one of the most
popular agile project management approaches.
In 2001, a group of software and project experts got together to talk about what their successful projects had in common. This group created the Agile Manifesto, a
statement of values for successful software development:
Manifesto for Agile Software Development[*]
Working software over comprehensive documentation
We are collaboration
uncovering better
ways
of developing
software by doing it and helping others do it. Through this work we have come to value:
Customer
over
contract
negotiation
Individuals
and interactions over processes and tools
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more.
These experts also created the Agile Principles, 12 practices that help support the values in the Agile Manifesto. I list the Agile Principles and describe the Agile Manifesto
in more detail in Chapter 2.
Agile, in product development terms, is a description for project management methodologies that focus on people, communications, the
Reprinted for CTS/316124, Cognizant Technology Solutions
Page 4 / 6
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
Agile Project Management for Dummies
product, and flexibility. There are many agile methodologies, including scrum, extreme programming, and lean, but they all have one thing in common: adherence to the
Agile Manifesto and the Agile Principles.
How Agile Projects Work
Agile approaches are based on an empirical control method — a process of making decisions based on the realities observed in the actual project. In the context of
software development methodologies, an empirical approach can be very effective in both new product development and enhancement and upgrade projects. By using
frequent and firsthand inspection of the work to date, you can make immediate adjustments, if necessary. Empirical control requires
n
Frequent ninspection:
The people
whoinvolved
are invested
the product
and process
most
regularly
evaluate
the product and
Transparency:
Everyone
on aninagile
project knows
what isthe
going
onshould
and how
the project
is progressing.
process.
n Adaptation:
Make adjustments
quickly
to minimize
problems;
if inspection
shows
that you
change,
thenOn
change
To accommodate
frequent inspection
and adaptation,
agile
projects work
in iterations
(smaller
segments
ofshould
the overall
project).
agile immediately.
projects, you still have the same
type of work that is involved on a traditional waterfall project: You have to create requirements and designs, you develop your product, and if necessary, you integrate your
product with other products. You test the product, fix any problems, and deploy it for use. However, instead of completing these steps for all of your product features at once,
you break the project into iterations, also called
sprints.
Figure 1-3 shows the difference between a linear waterfall project and an agile project.
Figure 1-3: Waterfall versus agile project
WARNING! Mixing traditional project management methods with agile approaches is like saying, "I have a Porsche 911 Turbo. However, I'm
using a wagon wheel on the front left side and right rear side. How can I make my car as fast as the other Porsches?" The answer, of course, is you can't. If you fully commit
to an agile approach, you will find you have a better chance at project success.
Why Agile Projects Work Better
Throughout this book, you will see how agile projects work better than traditional projects. Agile project management methodologies have
been able to produce more successful projects. The Standish Group, mentioned in the sidebar "Software project success and failure", also did a study of project success
rates in 2009. That year, the group found that 26 percent of projects failed outright — but in 2011, that number fell by
5 percent. The decrease in failure has, in part, been attributed to wider adoption of agile approaches.
Here are some key areas where agile approaches are superior to traditional project management methods:
Page 5 / 6
Reprinted for CTS/316124,
Cognizant
Technology
n Project
success
rates:Solutions
In Chapter 15, you will find out how the risk of catastrophic project
failure
falls
to
almost
nothing
on
agile
projects.
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
Agile Project Management for Dummies
Agile approaches of prioritizing by business value and risk ensures early success or failure. Agile approaches to testing throughout the project help ensure that you
find problems early, instead of after spending a large amount of time and money.
n
n
Scope creep: In Chapters 7, 8, and 12, you see how agile approaches accommodate changes throughout a project, minimizing the idea of scope creep. On agile
projects, you can add new requirements at the beginning of each sprint without disrupting development flow. By fully developing prioritized features first, you'll prevent
scope creep from threatening critical functionality.
Inspecting and adaptation: In Chapters 10 and 14, you find details of how regular inspecting and adaptation work on agile projects. Agile project teams can improve
their processes and their products with each sprint armed with information from complete development cycles and actual product.
Throughout many of the chapters in this book, you discover how you gain control of the outcome of agile projects. Testing early and often, adjusting priorities as needed,
[*]Agile
using
betterManifesto
communication
techniques,
regularly
demonstrating
andvan
releasing
product
functionality
allowWard
you toCunningham,
fine-tune yourMartin
controlFowler,
over a James
wide variety
of factors
Copyright
© 2001:and
Kent
Beck, Mike
Beedle, Arie
Bennekum,
Alistair
Cockburn,
Grenning,
Jim on
agile projects.
Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert
C. Martin, Steve Mellor, Ken Schwaber, Jeff Sutherland, Dave Thomas
If you're
interested
the possibility
of agile,
thenthis
thisnotice.
is the perfect book for you.
This declaration may be freely copied
in any
form, butinonly
in its entirety
through
Page 6 / 6
Reprinted for CTS/316124, Cognizant Technology Solutions
John Wiley & Sons (US), John Wiley & Sons, Inc. (c) 2012, Copying Prohibited
Agile Project Management For Dummies
From Agile Project Management For Dummies by Mark C. Layton
Agile project management focuses on continuous improvement, scope flexibility, team input, and delivering essential quality
products. Agile project management methodologies include scrum, extreme programming (XP), and lean, among others. These
methodologies all adhere to the Agile Manifesto and the 12 Agile Principles, which focus on people, communications, the product,
A Manifesto for Agile Software Developers
and flexibility.
The Agile Software Development Manifesto© is an intentionally streamlined expression of the core values of agile project
management. Use this manifesto as a guide to implement agile methodologies in your projects.
"We are uncovering better ways of developing software by doing it and helping others do it. Through this work, we have come to
value:
•
Individuals and interactions over processes and tools
•
Working software over comprehensive documentation
•
Customer collaboration over contract negotiation
•
Responding to change over following a plan
That is, while there is value in the items on the right, we value the items on the left more."
©Agile Manifesto Copyright 2001: Kent Beck, Mike Beedle, Arie van Bennekum, Alistair Cockburn, Ward Cunningham, Martin
Fowler, James Grenning, Jim Highsmith, Andrew Hunt, Ron Jeffries, Jon Kern, Brian Marick, Robert C. Martin, Steve Mellor, Ken
Schwaber, Jeff Sutherland, Dave Thomas.
This declaration may be freely copied in any form, but only in its entirety through this notice.
The 12 Agile Principles
The 12 Agile Principles are a set of guiding concepts that support project teams in implementing agile projects. Use these concepts
to implement agile methodologies in your projects.
1.
Our highest priority is to satisfy the customer through early and continuous delivery of valuable software.
2.
Welcome changing requirements, even late in development. Agile processes harness change for the customer's
competitive advantage.
3.
4.
Deliver working software frequently, from a couple of weeks to a couple of months, with a preference to the shorter
timescale.
Business people and developers must work together daily throughout the project.
5.
Build projects around motivated individuals. Give them the environment and support they need, and trust them to get
the job done.
6.
The most efficient and effective method of conveying information to and within a development team is face-to-face
conversation.
7.
8.
Working software is the primary measure of progress.
Agile processes promote sustainable development. The sponsors, developers, and users should be able to maintain a
constant pace indefinitely.
9.
Continuous attention to technical excellence and good design enhances agility.
10.
Simplicity — the art of maximizing the amount of work not done — is essential.
11.
The best architectures, requirements, and designs emerge from self-organizing teams.
12.
At regular intervals, the team reflects on how to become more effective, then tunes and adjusts its behavior
accordingly.
The Agile Roadmap to Value
The Roadmap to Value is a high-level view of an agile project. The stages of the Roadmap to Value are described in the list
following the diagram:
•
•
In Stage 1, the product owner identifies the product vision. The product vision is a definition of what your product is, how it will
support your company or organization’s strategy, and who will use the product. On longer projects, revisit the product vision at
least once a year.
In Stage 2, the product owner creates a product roadmap. The product roadmap is a high-level view of the product requirements,
with a loose time frame for when you will develop those requirements. Identifying product requirements and then prioritizing and
roughly estimating the effort for those requirements are a large part of creating your product roadmap. On longer projects, revise
the product roadmap at least twice a year.
•
In Stage 3, the product owner creates a release plan. The release plan identifies a high-level timetable for the release of working
software. An agile project will have many releases, with the highest-priority features launching first. A typical release includes
three-to-five sprints. Create a release plan at the beginning of each release.
•
In Stage 4, the product owner, the master, and the development team plan sprints, also called iterations, and start creating the
product within those sprints. Sprint planning sessions take place at the start of each sprint, where the scrum team determines
what requirements will be in the upcoming iteration.
•
In Stage 5, during each sprint, the development team has daily meetings. In the daily meeting, you spend no more than 15
minutes and discuss what you completed yesterday, what you will work on today, and any roadblocks you have.
•
In Stage 6, the team holds a sprint review. In the sprint review, at the end of every sprint, you demonstrate the working product
created during the sprint to the product stakeholders.
•
In Stage 7, the team holds a sprint retrospective. The sprint retrospective is a meeting where the team discusses how the sprint
went and plans for improvements in the next sprint. Like the sprint review, you have a sprint retrospective at the end of every
sprint.
Agile Project Management Roles
It takes a cooperative team of employees to complete a project. Agile project teams are made up of many people and include the
following five roles:
•
Development team: The group of people who do the work of creating a product. Programmers, testers, designers, writers, and
anyone else who has a hands-on role in product development is a member of the development team.
•
Product owner: The person responsible for bridging the gap between the customer, business stakeholders, and the
development team. The product owner is an expert on the product and the customer's needs and priorities. The product owner
works with the development team daily to help clarify requirements. The product owner is sometimes called a customer
representative.
•
Scrum master: The person responsible for supporting the development team, clearing organizational roadblocks, and keeping
the agile process consistent. A scrum master is sometimes called a project facilitator.
•
•
Stakeholders: Anyone with an interest in the project. Stakeholders are not ultimately responsible for the product, but they
provide input and are affected by the project's outcome. The group of stakeholders is diverse and can include people from
different departments, or even different companies.
Agile mentor: Someone who has experience implementing agile projects and can share that experience with a project team.
The agile mentor can provide valuable feedback and advice to new project teams and to project teams that want to perform at a
higher level.
Agile Project Management Artifacts
Project progress needs to be measurable. Agile project teams often use six main artifacts, or deliverables, to develop products and
track progress, as listed here:
•
Product vision statement: An elevator pitch, or a quick summary, to communicate how your product supports the company's or
organization's strategies. The vision statement must articulate the goals for the product.
•
Product backlog: The full list of what is in the scope for your project, ordered by priority. Once you have your first requirement,
you have a product backlog.
•
Product roadmap: The product roadmap is a high-level view of the product requirements, with a loose time frame for when you
will develop those requirements.
•
•
•
Release plan: A high-level timetable for the release of working software.
Sprint backlog: The goal, user stories, and tasks associated with the current sprint.
Increment: The working product functionality at the end of each sprint.
Agile Project Management Events
Most projects have stages. Agile projects include seven events for product development. These events are meetings and stages
and are described in the following list:
•
Project planning: The initial planning for your project. Project planning includes creating a product vision statement and a
product roadmap, and can take place in as little time as one day.
•
Release planning: Planning the next set of product features to release and identifying an imminent product launch date around
which the team can mobilize. On agile projects, you plan one release at a time.
•
Sprint: A short cycle of development, in which the team creates potentially shippable product functionality. Sprints, sometimes
called iterations, typically last between one and four weeks. Sprints can last as little as one day, but should not be longer than
four weeks. Sprints should remain the same length throughout the entire projects.
•
Sprint planning: A meeting at the beginning of each sprint where the scrum team commits to a sprint goal. They also identify the
requirements that support this goal and will be part of the sprint, and the individual tasks it will take to complete each
requirement.
•
Daily scrum: A 15-minute meeting held each day in a sprint, where development team members state what they completed the
day before, what they will complete on the current day, and whether they have any roadblocks.
•
Sprint review: A meeting at the end of each sprint, introduced by the product owner, where the development team demonstrates
the working product functionality it completed during the sprint.
•
Sprint retrospective: A meeting at the end of each sprint where the scrum team discusses what went well, what could change,
and how to make any changes.
Agile Project Management Organizations, Certifications, and Resources
There is a big agile project management world out there. Here are a few of the useful links to members of the agile practitioner
community:
•
Agile Alliance: The Agile Alliance is the original global agile community, with a mission to help advance agile principles and
practices, regardless of methodology.
•
Scrum Alliance: The Scrum Alliance is a nonprofit professional membership organization that promotes understanding and
usage of scrum. The Scrum Alliance offers a number of professional certifications:
•
Certified Scrum Master (CSM)
•
Certified Scrum Product Owner (CSPO)
•
Certified Scrum Developer (CSD)
•
Certified Scrum Professional (CSP)
•
Certified Scrum Coach (CSC)
•
Certified Scrum Trainer (CST)
XProgramming.com: Ron Jeffries, one of the originators of the extreme programming (XP) development approach,
provides resources and services in support of XP's advancement on the XProgramming.com site.
Lean Essays: Lean Essays is a blog from Mary and Tom Poppendieck, thought leaders in the use of lean concepts within
the software development space.
PMI Agile Community: The Project Management Institute (PMI) is the largest nonprofit project management membership
association in the world. The agile section of PMI's website provides access to papers, books, and seminars about agile project
management. PMI supports an agile community of practice and a certification, the PMI Agile Certified Practitioner (PMI-ACP).
Platinum Edge: Since 2001, my team at Platinum Edge has been helping companies successfully take their project
management practices to a higher level. We provide training classes worldwide and also develop transition strategies and
coaching for organizations moving to agile project management. Visit the training section of our site to find an upcoming Certified
Scrum Master, Certified Scrum Product Owner, PMI-ACP preparation, or agile overview class near you.
Agile Estimating & Planing
Agile Estimating and Planning
Introduction & Review Course Outline
Agile Overview
Why Plan and What Makes a Good Plan?
Why Traditional Planning Fails
Agile Planning
Estimating with Story Points
{15-minute break}
Estimating with Ideal Days
3-Step Feature Prioritization Process
Measuring and Forecasting Velocity
Critical Chain Estimating and Scheduling
Why
Agile
Works
Wrap
Up Planning
& Evaluations
© 2011 Kevin Aguanno. All rights reserved.
An Overview of Agile
(C) 2011 Kevin Aguanno.
2
Agile Estimating & Planing
Agile Manifesto
Adherents stress:
Individuals and interactions over processes and tools
Working software over comprehensive documentation
Customer collaboration over contract negotiation
That is, while there is value in the items on the right, we
Responding
to change
value the
items onover
the following
left more. a plan
© 2001 The Agile Alliance
© 2011 Kevin Aguanno. All rights reserved.
Agile Development Principles
Project Characteristics:
Early and continuous delivery of usable deliverables
Usable deliverables measure progress
Accept changing requirements, even late in project
Simplicity in all aspects
Short
delivery cycles is essential
Sound, flexible
design/architecture
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
3
Agile Estimating & Planing
Iterative and Incremental Delivery
Month 1
Month 2
A/B/C
A
B
Waterfall
Iterative
A
B
A1
A
B1
Incremental
Agile
C
C1
A1,2
Month 3
C
A+B
B1,2 C1,2
A
B
C
A+B+C
A1,2,3 B1,2,3 C1,2,3
The Agile Approach is Iterative AND Incremental
© 2011 Kevin Aguanno. All rights reserved.
Predictability Varies as should
Metrics
Deterministic
(Plan-Based)
(ObservationBased)
Focus is on
adherence to
plan
Empirical
Focus is on
delivering
value to
customer
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
4
Agile Estimating & Planing
To Recap…
Agile methods are built upon the engine of
iterative and incremental delivery
Benefits:
Improved responsiveness to change
More customer input/control/feedback allowed
Less risk (building the wrong thing, building
the right thing wrong)
Visible/verifiable
progress
© 2011 Kevin Aguanno. All rights reserved.
How Scrum Manages Requirements
Changes
SCRUM Structure
Initial List
of Features
Grouped List
of Features
Feature 1
Feature 1
Feature 3
Sprint #1
Feature 2
Feature 7
Feature 3
Feature 4
Planning Feature 2
Feature 5
Feature 4
Sprint #2
Feature 6
Feature 5
Feature 7
Closure
Feature 6
Product Backlog
By Kevin Aguanno. (C) 2002 Element K Journals.
(C) 2011 Kevin Aguanno.
5
Agile Estimating & Planing
Progress Metrics
XP: Velocity (Features Completed / Planned)
Scrum: Sprint Burndown Chart (Est. Hours
Remaining
vs. Date)
FDD: Cumulative
Features
Completed (#
Features vs. Week)
© 2011 Kevin Aguanno. All rights reserved.
Quality Management
Common quality management techniques
suggested by agile methods include
Early and continuous testing (more time to fix
defects, less cost for remedial activities)
Test-Driven Development (focus on objective
quality criteria)
100% functional testing each build (or at least
each iteration)
Code/Design inspections/pair programming
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
6
Agile Estimating & Planing
Deliverables Acceptance
Using agile methods, final sign-off/acceptance of
deliverables is usually trouble-free, due to
Test-Driven Development (start with useracceptance tests)
Customer involvement in (re)prioritization
Short iterations with demonstrations at iteration
end (frequent customer feedback)
These elements of agile methods make sign-off
easier when dealing with multiple sponsors.
© 2011 Kevin Aguanno. All rights reserved.
Agile Methods are Harder to
Implement in
Some Situations
Large teams
Complex team organizational structures
Geographically-scattered teams
Life- or mission-critical applications
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
7
Agile Estimating & Planing
Why Plan and
What Makes a Good Plan?
“Planning is everything. Plans are nothing.”
Field Marshal Helmuth Graf von Moltke
(1800-1891)
Why Plan?
Planning is a quest for value, an attempt to
find the optimal solution to what should be
built and how to build it.
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
8
Agile Estimating & Planing
Planning improves the chances of
success
Reducing by:
Risk
Thinking through the possibilities allows us to take
preventative actions
Improving Understanding
Helps prevent building the wrong thing
Supporting
Making trade offs,
Data provides
a basis Decision
for understanding
etc.
Conveying Information
Conveys
expectations
Describes one
possibility
of future project events
Trust & plans
CreatingEstablishing
reliable estimates
What makes a good plan?
Stakeholders should find it “good enough” to
use as a basis for decision making
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
9
Agile Estimating & Planing
Why Traditional Planning
Fails
“No plan survives contact with the enemy.”
Field Marshal Helmuth Graf von Moltke
(1800-1891)
The Cost of Traditional Planning
Feature Usage Within Deployed Applications
Often
13%
Always
7%
Never
45%
Sometimes
16%
Rarely
19%
Source: Chaos Report v3 www.standishgroup.com
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
10
Agile Estimating & Planing
We traditionally plan by task, not
byfocus
feature
Traditional methods
on the completion of tasks
rather than delivering features.
Customers get little value from the completion of tasks.
Features are the true measure of customer value.
When we review traditional task-based schedules, we tend
With
effort attasks
feature
prioritization
across multiple
to look
forlittle
forgotten
rather
than for missing
features.
releases, we tend to build all features in one release,
regardless of importance/value to the business.
© 2011 Kevin Aguanno. All rights reserved.
Tasks rarely finish early
Parkinson’s Law : “Work expands to fill the time available for
its completion.”
People’s natural tendency is to not work as fast when there is
lots of time available for a task.
An official schedule showing a week to complete a task gives
implicit “permission” to take that full week.
If done early, people may “gold plate” the solution by adding
extra features not requested by the sponsor.
People also spend more time researching novel approaches
to the solution if they perceive that they have lots of time.
There may be a fear that if people finish early, they may be
accused of “padding” their estimates or that they will be
expected to complete their ©other
work
too.
2011 Kevin
Aguanno.early
All rights reserved.
(C) 2011 Kevin Aguanno.
11
Agile Estimating & Planing
Delays cascade through the
schedule
Traditionalproject
task-based plans
focus on dependencies
between tasks.
Late completion of one task can cause following tasks to
also be late.
This is exacerbated by the earlier point that tasks rarely
finish early.
As a result, in traditionally-planned projects, testing rarely
gets to start early and early completion is rare.
Multi-tasking causes further
delays
Multi-tasking hurts
productivity
.
With two
tasks, productivity
improves
as athe
person
switch
to one while
other can
is blocked
by something.
We rarely only have two tasks,
however,
and
productivity
drops off
after
two tasksrapidly
are
assigned concurrently.
Apart from time lost when
switching between tasks (or
projects), a person loses
focus/concentration.
(C) 2011 Kevin Aguanno.
Effects of Multi-Tasking on Productivity
90
80
70
60
50
40
30
20
10
0
1
2
3
4
5
# Concurrent Tasks
Source: K. Clark and S. Wheelwright.
Managing New Product and Process
Development: Text and Cases. The Free
Press, 1993.
© 2011 Kevin Aguanno. All rights reserved.
12
Agile Estimating & Planing
Multi-tasking causes further
delays
Multi-tasking
becomes(cont’d)
a significant issue once
some tasks finish late.
It is usually encouraged to increase overall team
member utilization, rather than maintaining
sufficient slack to cope with typical project
Loading the team tovariability.
100% capacity is like loading a
highway to 100% capacity - no one makes any
progress.
© 2011 Kevin Aguanno. All rights reserved.
Features are not developed by
priority
In traditional plans:
Work is prioritized and sequenced for the
convenience of the development team.
All requirements/work must be completed, so
the sponsor should not care about the
sequence.
Near the end of the
project, the team scrambles
to meet the schedule by dropping features, but
with no effort to prioritize features up front,
critical features could get dropped.
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
13
Agile Estimating & Planing
We tend to ignore uncertainty
We assume that the requirements analysis led
to a complete and perfect specification.
We assume that sponsors will not change
their minds, refine their opinions, or come up
with new needs during the project.
We ignore uncertainty about how we will build
the product.
We assign precise estimates to this uncertain
work.
© 2011 Kevin Aguanno. All rights reserved.
Estimates become commitments
The only way we will know the project costs for
sure is to look at the actuals when the project is
Humans cannot seeover.
the future, so we estimate
based on our experience and the information at
hand
including
inherent uncertainties.
Each
estimate
has its
a confidence
level (probability)
associated with it.
In traditional projects, these estimates get seen as
commitments, even when they are at less than
100% probability.
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
14
Agile Estimating & Planing
Reduction in Uncertainty
1.8
1.6
1.4
1.2
1
0.8
0.6
0.4
0.2
0
Agile Planning
“A good plan […] executed now is better than a
perfect plan executed next week.”
General George S. Patton Jr. (1885-1945)
(C) 2011 Kevin Aguanno.
15
Agile Estimating & Planing
Agile approach to projects
Plan on a multi-disciplinary team.
Include sponsor/product owner, project manager, developers,
designers, and testers/QA.
Break
project into short iterations.
Timebox each iteration. Typically, 2-4 weeks.
Deliver something each iteration.
Iterations deliver products that are of releasable quality.
on business
priorities.
Deliver featuresFocus
(not tasks)
using user
stories, prioritized by the
business.
Inspect and adapt.
Update the plan to reflect actual experiences and the benefits
of new knowledge.
Adjust priorities at the start of each iteration to maximize the
ROI.
© 2011 Kevin Aguanno. All rights reserved.
Agile teams have three levels of
planning
Release Plans
To prepare project-level schedule, resource plans, and
overall scope.
Iteration Plans
To identify high-priority features to be completed in the
next iteration.
To plan the work (tasks) required to build the selected
features.
Day Plans
task.
(C) 2011 Kevin Aguanno.
Informal discussion during the daily meeting/call to
coordinate work and share information.
Planning the activities leading
up to the completion of a
© 2011 Kevin Aguanno. All rights reserved.
16
Agile Estimating & Planing
What is Release Planning?
Building a high-level project schedule
identifying:
# Iterations & their start/end dates
Releases & their start/end dates
Key business milestones
Interlocks with other projects
Initial contents for each iteration
(stories/features, not tasks)
© 2011 Kevin Aguanno. All rights reserved.
Release Planning
Constraints
- Schedule
Requirements
- User Stories
- Features
Estimate Size
Prioritization
and Grouping
1) Business Priority
2) Technical
Dependencies
3) Logical Groupings
- Budget
Divide into
Iterations
1) Choose Iteration
Length
2) Estimate Velocity
3) Divide Into Iterations
4) Prepare High-Level
Schedule
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
17
Agile Estimating & Planing
3-Step Feature
Prioritization Process
"Strategy is a style of thinking, a conscious and
deliberate process, an intensive implementation
system, the science of insuring future success."
Dr. Pete Johnson
(a.k.a. “Dr. Strategy”)
Factors:
After estimating story size,
prioritize the list
1. Calculate the business priority
a) Financial value (NPV, IRR, payback, etc.) or customer service
value
b) Cost of developing/supporting (can divide actual costs for last
iteration by # story points for an avg. $/point to use in foreward
c) Amount of learning (about planning)
product and process) and personal
skill development (tools, etc.)
d) Amount of risk removed
e) Legal/Compliance requirements
2. Factor in technical dependencies
3. Adjust for logical groupings
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
18
Agile Estimating & Planing
Risk can be an important deciding
factor
Avoid
Do First
Do Last
Do Second
Value
© 2011 Kevin Aguanno. All rights reserved.
Project Backlog Contents:
Example - Identify Backlog Items
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
19
Agile Estimating & Planing
Project Backlog Prioritization
1. Calculate the business priority
Factors:
a) Financial value (NPV, IRR, payback, etc.) or
customer service value
b) Cost of developing/supporting (can divide actual
costs for$/point
last iteration
byforeward
# story points
for an avg.
to use in
planning)
c) Amount of learning (about product and process) and
personal skill development (tools, etc.)
d) Amount of risk removed
e) Legal/Compliance requirements
© 2011 Kevin Aguanno. All rights reserved.
Project Backlog Prioritization:
Example - Assign Business Value
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
20
Agile Estimating & Planing
Project Backlog Prioritization:
Example - Sort by Business Value
© 2011 Kevin Aguanno. All rights reserved.
Project Backlog Prioritization:
Example - Factor in Logical Dependencies
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
21
Agile Estimating & Planing
Project Backlog Prioritization:
Example - Estimate Complexity (Points)
© 2011 Kevin Aguanno. All rights reserved.
Estimating for Release Plans
When at the “Estimating Size” step of the release
planning process, you can use one of two methods:
Story Points
A unit of measure for expressing
overall size, complexity, risk,
etc. of a user story/feature.
An abstract unit, not directly convertible to hours, days, etc.
Based on completion of the story/feature by the whole team.
A day of developmentIdeal
workDays
with full utilization (no multitasking, no interruptions, no technical difficulties).
Needs to be added up for all people involved in defining and
completing the story.
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
22
Agile Estimating & Planing
Estimating With
Story Points
“It is better to be roughly right than precisely
wrong.”
John Maynard Keynes
(1883-1946)
Estimating with Story Points
Use one of two techniques to get started:
Find the smallest user story and assign it a value of “1”.
Or, find a medium-sized story and assign it a value of
Then, as a group, assign “5”.
all remaining stories a value
between 1 and 10 based upon their relative
and
riskshould
to the be
other
stories.
E.g. acomplexity
story that is
a “4”
twice
as complex
as a story that is a “2”.
Don’t over-analyze. Ask a few questions of the
product
owner,
make
some
assumptions,
take a
guess,
and
move
on to
the next story.
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
23
Agile Estimating & Planing
Estimating with Story Points
Use a 0-10 point(cont’d)
scale (zero for simple “freebies”)
You can spend too much time trying to distinguish between a 6
and a 7, for example, so try to use:
0 for simple, “free” no-cost or low-cost stories. (Explain that by
putting too many of these in a single iteration, they will start to
up into points.
13x0 Studies
> 0.) show that we
1, 2, and 3 foradd
low-complexity
stories.
are good at distinguishing between simpler levels of complexity.
58
forfor
medium
complexity.
high complexity.
10 for very high complexity.
You can use 20, 40, and 100 for estimating epics and themes.
Epics are large user stories you have not bothered to break down
yet.
Themes are groupings of related
stories that can be treated as one
unit for planning purposes. E.g. reports.
© 2011 Kevin Aguanno. All rights reserved.
The Agile Planning Game
(C) 2011 Kevin Aguanno.
24
Agile Estimating & Planing
Avoiding the dangers of group
estimating
There is a human tendency towards “group
think”
If you go around a room asking estimates to
gain a consensus, some with deviating
opinions will not speak up due to inadvertent
To fix this, everyone
needs to present their
group pressure
estimates simultaneously.
© 2011 Kevin Aguanno. All rights reserved.
An example
User Story
As a site visitor, I want to
be able to subscribe to the
company newsletter
Initial Simultaneous Estimate
John Mary Paul
13
5
8
Simultaneous Re-estimating after a Brief Discussion
User Story
John Mary Paul
As a site visitor, I want to
8
5
5
be able to subscribe to the
company newsletter
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
25
Agile Estimating & Planing
Handle simultaneous estimating using
“planning
poker”
Each estimator
has a setcards
of cards
Special-purpose
Fibonacci series
cards - printedcards
out and laminated
(1,2,3,5,8,13,21,34)
Regular playing cards (Ace = 1 point; 2-10 = face
value, J/Q/K = 20/50/100 points, and ace=infinity)
Basic Planning PokerTM process
Facilitator reads out the user story + notes
Team may ask product owner questions (high
level)
When questions answered, or timebox is out,
everyone selects the card with the # points and
puts it facedown on the table.
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
26
Agile Estimating & Planing
Dealing with discrepancies
On the facilitator’s cue, everyone turns over their card
If there was a big range, team discusses high and low estimates;
perhaps, because someone thought of something others forgot
Everyone puts their card backabout.
in the deck and rethinks the story.
The team then comes back to the table to try again for a
theand
second
round.
The process isconsensus
repeated, on
over
over until
a consensus is
reached, or all remote concerns have been dealt with outside of
this project.
Process ends when consensus is reached, or when the difference
is minimal and explainable. Please note that timeboxing is a good
way to constrain the time for these activities.
© 2011 Kevin Aguanno. All rights reserved.
Finally, apply adjustment factors to
A best practicethe
is toestimates
add adjustment factors to the
estimates after the planning poker rounds have
completed.
These “fudge
areoptions
added in to:
Discourage
poorlyfactors”
conceived
Adjust for fuzzy requirements or lack of stakeholder
buy-in for the project
Adjust for resource availability issues
for largework
teams
Add time forAdjust
dysfunctional
environments
Adjust for technical or business risk
Etc.
Don’t get too granular or heavy-handed with these
adjustment factors.
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
27
Agile Estimating & Planing
Estimating With
Ideal Days
“Ideals are like stars: you will not succeed in touching
them with your hands, but like the seafaring man on
the
ocean
desert
of waters,
themdestiny.”
as your
guides,
and
following
them,you
youchoose
reach your
Carl Schurz (1829 - 1906)
Estimating with Ideal Days
Ideal time differs from elapsed time because of the natural
overhead and distractions we experience:
Supporting the current release
Sick time
Meetings
Demonstrations
HR activities
Phone calls
Email
Training
Reviews / walk-throughs
Task switching when multi-tasking
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
28
Agile Estimating & Planing
Estimating with Ideal Days
(cont’d)
Problems arise when
estimates are given in “days”
with no qualification as to what a “day” means.
Using the term “Ideal Days” helps to relieve this
situation.
Ideal Days is a measure of size, not duration.
Assign one estimate to a story that is the sum of the
Ideal Days estimates for each role required to
complete the story (management, analysis, design,
development, and testing).
© 2011 Kevin Aguanno. All rights reserved.
Story Points vs. Ideal Days
Story Points
Help drive cross-functional
behaviour
Estimates do not decay as
skills develop, etc.
A pure measure of size
Faster than Days
estimating Ideal
Ideal Days
More in-depth analysis of the
tasks required
story.to build a
Easier to explain to outsiders,
though
there
is acompared
risk of
having
Ideal
Days
to calendar days
Easier than Story Points to
estimate at first
My Ideal Days are not your
Ideal
Days
(skillestimates)
levels affect
Ideal
Days
Chance of missing input from
a key role
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
29
Agile Estimating & Planing
Measuring & Forecasting
Velocity
“The order in which you do something determines the
velocity with which you can act, or, the velocity with
which you act determines the order in which you can
do something.”
Tim O’Connor
Velocity
A measure of the team’s rate of progress. Calculated by
summing up the number of story points or ideal days that the
teamif completed
in its most
iteration.
For example,
a team completed
tenrecent
story points
last iteration,
assume they can do ten again this iteration.
Agile methods estimate size, not duration. Duration is derived
from the size.
Story points or ideal days are turned into a schedule by
applying velocity.
Add up all of the story point or ideal days totals for the project.
Get the team’s velocity for a specific iteration length.
Divide the point or day total by the velocity to determine the
This number
forms the
for the
release plan.
of basis
required
iterations.
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
30
Agile Estimating & Planing
Velocity (cont’d)
The beauty of using velocity as a measure for
planning, is that it doesn’t matter if our estimates are
correct, just that they are consistent.
With consistent estimates, measuring velocity over
the first few iterations will allow us to prepare a more
reliablenew
schedule.
To estimate velocity
projects, you can use:
historical values (if team, tools, technology, etc. are the
same)
run an iteration to get actuals (or 3 iterations and take
avg. or range)
Or, make ©a2011
forecast
Kevin Aguanno. All rights reserved.
Estimating Initial Velocity:
Using Historical Values
For iteration 1, use the actual velocity from a
past project only if:
Same team
Same technology/solution (e.g. developing
version 6.1 based on existing version 6.0)
Similar types of scope/backlog items
For iterations 2 to n inside a project, use the
last iteration’s velocity
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
31
Agile Estimating & Planing
Estimating Initial Velocity (Simple):
Forecasting
Velocity
for
Fixed
Team
NOT the best approach,
but one that
we need
in our toolkit.
Steps:
Estimate the # hours/day available to work on the project for each team
member.
(Typically,
60%-70%
productivity
for dedicated
resources.)
2. Select
the number
of team
members
to be used
- only those
producing
deliverables, not managers, etc.
3. Select an iteration length
4. Determine the total # hours spent on the project during an iteration. (= #
hrs/day x # people on team x # days in iteration)
Pick a few random stories and expand them into tasks and estimate the # effort
hours per task, getting a total # hours for each story.
Gather enough stories so that the # hours for each story adds up to the # hours
available in an iteration.
7. Count up the story points for the selected stories to determine projected
velocity.
1.
5.
6.
Weakness: Assumes all team members included in calculation are equally
productive and that they are all equally producing deliverables - does not
identify overburdened resources
© 2011 Kevin Aguanno. All rights reserved.
Estimating Initial Velocity (Advanced):
Forecasting
Velocity for Optimal Team
This method is more accurate than the simple method.
Steps:
Select a sampling of user stories of varying size and importance (usually 5-8 is
enough).
2. Do an old-fashioned, detailed, bottom-up estimate in hours per resource type
to design/build each story.
3. Select an iteration length
4. Determine how many stories will fill up the hours available in an iteration for the
most utilized resource (i.e. most # hours of work for each story - usually the
developers)
5. Now keep adding developers to increase the number of stories that can fit in
the iteration until you optimize the less-utilized resources; or, stop when you hit
the # developers available to the team.
6. Add up the story points assigned to all the stories that can fit into the iteration
with the chosen team size - this number is your initial forecast velocity.
1.
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
32
Agile Estimating & Planing
Building the Initial Release Plan:
Carving
Up the Project Backlog
Using the forecast velocity, carve up the project
backlog into chunks of the appropriate size (+/- a
two willthan
likelythe
bevelocity
OK) forecast,
If a chunk ispoint
muchorsmaller
but the next piece would push it way over, then look
down the list for the next piece that would fit and
Eachmove
chunkit represents
the the
scope
for one
iteration
up the list into
current
chunk
For our ongoing example, let’s assume an initial
forecast velocity of 10 points.
© 2011 Kevin Aguanno. All rights reserved.
Building the Initial Release Plan:
Example - Carving Up the Project Backlog
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
33
Agile Estimating & Planing
Building the Initial Release Plan:
Plotting Iterations on a Calendar View
Plot the iterations on a calendar view with real
project start dates to get a realistic view.
On high-uncertainty/high-risk projects where the end
date will not move, it is good practice to leave one or
two iterations before the end of the project to
Scope
increases
absorb:
The risk of technology challenges and defect
correction work affecting velocity
The risk of poor team performance
© 2011 Kevin Aguanno. All rights reserved.
Building the Initial Release Plan:
Example - Plotting on a Calendar View
Note: In this example, we dropped the original scope for Iteration 9
(Additional Resources, Bibliography, Dedication) as it was not possible to
achieve this by our Feb. 15 deadline while still having some
2011unmovable
Kevin Aguanno.project
All rights end
reserved.
contingency/buffer to protect©our
date.
(C) 2011 Kevin Aguanno.
34
Agile Estimating & Planing
Identifying Constraint Dates
Mark on the calendar:
Interlocks/dependencies with other projects
Using another’s
deliverable
Providing
deliverables
to another
Key business milestones/constraint dates/periods
Major presentations (e.g. architecture review board
meetings, trade show demos, board of directors
presentations,
Business events
affecting theetc.)
project (e.g. system
change blackouts, office closures, etc.)
Holidays/vacation periods (e.g. Christmas week,
Canada Day/Independence Day week, etc.) that
affect productivity
© 2011 Kevin Aguanno. All rights reserved.
Building the Initial Release Plan:
Example - Identify Constraint Dates
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
35
Agile Estimating & Planing
Defining Releases
Release: A wave of solution development ending in
a deployment/use of the solution by the business,
consisting of one or more iterations.
Most projects have 1-3 releases, though some
release every iteration.
A release should have enough “critical mass” for the
business to bother going through the costs of
acceptance testing and deployment.
© 2011 Kevin Aguanno. All rights reserved.
Building the Initial Release Plan:
Example - Defining Releases
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
36
Agile Estimating & Planing
Adjusting Release Plan
Now move stories/features from iteration to
iteration
to reflect:
Dependencies
Key business milestones/constraint
dates/periods (demos, blackouts, etc.)
Lower productivity periods due to planned
holidays
Resource leveling
Required release functionality
© 2011 Kevin Aguanno. All rights reserved.
Building the Initial Release Plan:
Example - Adjusted Release Plan
By reducing the # points achievable in the Christmas period, scope items (features) flow out to the right,
cascading through the remainder of the schedule.
We had to drop feature 17 (Index) to leave a buffer in Iteration 9.
We could now include features 18, 15, and 2 (Additional Resources, Bibliography, Dedication) to fill in unused
© 2011 8.
Kevin Aguanno. All rights reserved.
capacity in Iteration
Release 1, to be used for early endorsements, would not include 3 chapters that will appear in the final release.
(C) 2011 Kevin Aguanno.
37
Agile Estimating & Planing
Iteration Planning
- Actual Velocity
Requirements
- Reprioritized
Analysis
Release Plan
Inputs
Gather
Acceptance
Criteria
Plan by Task
Verify
Resource
Requirements
1) Identify Tasks (WBS)
2) Estimate by Hours of
Effort
3) Prepare Schedules
Very similar to how we plan/estimate today, except focus is only
on#ahours
smallas
portion
of possible,
the project.
By estimating
late as
we can be more
precise as risks pass and uncertainty goes down.
© 2011 Kevin Aguanno. All rights reserved.
Critical Chain Estimating
& Scheduling
“An expert is not someone who gives you the
answer, it is someone that asks you the right
question.”
Eliyahu Goldratt
(1948- )
(C) 2011 Kevin Aguanno.
38
Agile Estimating & Planing
Estimating Hours of Effort
Hypothetically, if we run a project over and over
again, the random variances in the actual duration of
tasks will follow a standard Beta distribution. Note
the tail showing worst-case
scenarios.
Median
Duration
Estimating Hours of Effort
We (cont’d)
normally estimate at
that 90% of the time, our
estimate is big enough.
If we estimate
confidence,
half at
the50%
time
we will have enough time
and thewon’t.
other half we
Parkinson’s Law says that
if wemost
estimate
90%,
then
of thatattime
we
could have finished much
earlier,
but to
thefilltask
expanded
its
available duration. © 2011
(C) 2011 Kevin Aguanno.
90% confidence, meaning
50%
Median
90%
Duration
Kevin Aguanno. All rights reserved.
39
Agile Estimating & Planing
Estimating Hours of Effort
(cont’d)
Agile estimating says
that we should estimate at 50%
confidence at the task level, avoiding buffers on each
task, and instead strategically place buffers in the
This is called the
Critical Chain Method of
schedule.
estimating/scheduling.
Two buffer types:
Feeder buffers (when two work streams come together)
Project buffers (before key milestones or at the end of
the project
to protect
key dates)
These buffers
can be
much smaller
than having
buffers on individual tasks
© 2011 Kevin Aguanno. All rights reserved.
Within an iteration, use Critical
Chain scheduling with buffers
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
40
Agile Estimating & Planing
Why Agile Planning
Works
“If anything is certain, it is that change is certain.
The world weexist
are planning
fortomorrow.”
today will not
in this form
Philip Crosby
(1926-2001)
Why Agile Planning Works
Replanning occurs frequently
Estimates of size and duration are separated
Plans are made at different levels
Plans are based on features, not tasks
Small stories keep the work moving
Work in Progress is eliminated every iteration
Uncertainty
andlevel,
planned
Trackingisisacknowledged
done at the team
not for
individual level
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
41
Agile Estimating & Planing
Wrap Up
“We should be taught not to wait for inspiration to start
a thing. Action always generates inspiration.”
Frank Tibolt
(1897-1989)
Techniques You can Start Using
Today
Design around Iterative and Incremental
Development
Immediate, visible, verifiable progress
Simplifies solution, lowers risk
Increase customer satisfaction
Procrastinate your estimating to reduce risk, improve
Do Just-In-Time Estimating
accuracy, and speed up initial estimating
Plan at Different Levels
Create plans with different levels of details for
different audiences.
© 2011 Kevin Aguanno. All rights reserved.
(C) 2011 Kevin Aguanno.
42
Agile Estimating & Planing
Help is Available
Agile adoption strategy workshop
Agile methodology customization for your
organization
Agile methodology training (developers)
Agile methodology training (managers)
Agile health check training for auditors and
Ongoing mentoring
of agile pilot projects
PMO reps
© 2011 Kevin Aguanno. All rights reserved.
Questions?
Kevin Aguanno (your speaker) is available for consultation at
[email protected]
He is the author of over 20 books, audiobooks, DVDs, and
CD-ROMs related to this subject matter:
(C) 2011 Kevin Aguanno.
Books:
CD-ROMs:
Audiobooks:
DVDs:
43
Agile Glossary
A glossary of commonly-used terms unique to agile projects. The most prominent
definition of each term is used, and where there is debate within the agile community on
the meaning of these terms, other definitions may be mentioned.
Active Customer
Participation
Regular involvement by the project sponsor or a delegate and
possibly key stakeholders in the day-to-day decision making on
the project. One of the key principles of agile management
methods. Active customer participation provides transparency,
improved customer control, improved customer satisfaction, faster
decision
making,many
and faster
clarification of
requirements.
Adaptive Software
An agile method
that applies
agile management
techniques
Development
to earlier rapid application development methods. See
http://en.wikipedia.org/wiki/Adaptive_Software_Development.
Agile
A management philosophy that focuses on delivering value with
approaches that are lightweight and responsive to change.
Agile Manifesto
A statement describing the core agile philosophy. The original
signers of the Agile Manifesto were proponents of several agile
software development methods, resulting in a software
development flavour to how the manifesto was worded; however,
the underlying concepts
apply across many different management
www.agilemanifesto.com.
not just software development. See
ASD
See Adaptive Softwareareas,
Development.
Backlog
A list of items that have still to be completed. There are several
types of Backlogs used in agile methods. See Product Backlog,
Project Backlog and Iteration Backlog.
Backlog Maintenance
The process whereby new deliverables/user stories/features are
added to the list of work to be potentially completed during a
project; this list is called the Project Backlog.
(See also Project
Backlog and Product Backlog.)
Budget Burndown
A graph showing the amount of authorized funding (budget)
Chart
remaining on a project, trended over time. Typically, it is updated
once per Iteration to reflect the amount remaining after the actual
costs for
completed
subtracted.
Burndown Chart
A graph showing
thethe
changes
in a Iteration
total that are
represents
a quantity
remaining, trended over time. It starts at an original value (plotted
on the vertical axis), and trends to the right, with the goal of
reaching zero as it crosses the horizontal axis. Burndown Charts
cometoina several
types;
seethat
Budget
Burndown
Chart,atProduct
Burnup Chart
A graph similar
Burndown
Chart
trends
data starting
Burndown
Project
zero on the left-hand
side andChart,
trendsand
upwards
to Burndown
the right asChart.
the
number grows over time. See Burndown Chart.
Agile Glossary © 2011 Multi-Media Publications Inc.
Page 1 of 11
Chicken
Colocation
Critical Chain
Crystal Methods
(Crystal
Clear/Orange/Red/etc.)
Daily Scrum
Defined Method
Deterministic Method
DSDM
A term used in the Scrum method for a project stakeholder who
does not have direct control over a project. The contrast for a
Chicken is the project sponsor (called Product Owner in Scrum)
Moving team members so that they
together
at one location,
whoare
is called
a Pig.
allowing the use of face-to-face communications. See also Onsite
Customer.
A method of preparing task estimates and project schedules that
removes hidden contingencies in task estimates and strategically
places a portion of those removed contingencies in specific places
on the project schedule. Specific techniques are used for sizing
these contingencies (called Buffers) and unique metrics are used
http://en.wikipedia.org/wiki/Critical_Chain_Project_Management.
for tracking the use of these contingencies (e.g. Buffer Burn
A scalable family of iterative
incremental
Rate).
See development methods
that provides different levels of formality for projects of varying
complexity. The simplest, least-formal method flavour is called
teams.
teamand
size,
orfor
complexity
increases,
of
CrystalAs
Clear
is risk,
meant
lower-risk
projects the
withlevel
small
method formality increases, moving through several flavours
through Crystal Orange, Crystal Red, etc. See
http://alistair.cockburn.us/Crystal+light+methods.
A short daily meeting wherein team collaboration and knowledge
sharing are encouraged, issues are identified to management, and
commitment is reinforced through the asking of three standard
questions. The first question (“Did you complete everything you
planned on doing yesterday?”) is about the past and is intended to
uncover issues within 24 hours of them appearing. The second
question (“What are you going to work on today?”) is to facilitate
completing
work this
Iteration?”)
is again
intended
mentoring
and your
knowledge
sharing
among team
members
andtoalso
identify
issues
to
the
project
management
within
24
hours
of them
to reinforce commitment from team members. The last question
appearing.
The
meetings
are
usually
held
with
participants
(“Is there anything going to slow you down or stop you from
standing up (i.e. no chairs) which encourages the participants to
See Deterministic Method
the meeting
short.
A method that is based upon akeep
preparing
a detailed
forecast of the
future (estimates and a plan) and then measuring and managing
any variances to that plan in order to get the project “back on
plan.”.
See Dynamic Systems Development Method.
Agile Glossary © 2011 Multi-Media Publications Inc.
Page 2 of 11
Dynamic Systems
Development Method
A method managed by the DSDM Consortium that formalizes
earlier Rapid Application Development techniques with a greater
focus on the delivery of business value in an iterative, incremental
fashion. See www.dsdm.org.
Empirical Method
A method based upon developing only a high-level plan for the
project, getting started, and then monitoring and controlling
several variables (such as budget burn rate, quality levels,
Velocity, and others) to keep the project’s parameters within
tolerance rages.
Extreme Programming
An agile method foracceptable
solution development
that focuses mostly on
Extreme Project
Management
FDD
Feature-Driven
Development
Ideal Day
IID
Increment
the technical development work, rather than project management
activities. XP was developed concurrently with Scrum, and is
most
commonly
implemented
simultaneously
where
provides
the solution
development
processes. with
MoreScrum
information
Scrum provides the project management processes and XP
A term often used asata http://www.extremeprogramming.org/.
synonym for “Agile Project Management,”
usually when referring the project management processes that
need to be in place to manage Extreme Programming projects.
See Feature-Driven Development.
An agile method that contains both project management processes
and some solution development processes. FDD is notable for its
significant guidance and structure for Iteration Zero activities.
An agile unit of high-level estimating that assesses work effort for
a User Story. Compared to Story Points, Ideal Days have a
number of drawbacks: key roles may be missed, the work effort
associated with some tasks may be missed without preparing a
Work Breakdown Structure first, the estimated work effort may
not consider the impact of an individual’s skill level or
performance, estimates do not typically include the impacts of
multi-tasking interruptions, and estimates can degrade in accuracy
over time as Development.
skill levels improve later in the project lifecycle.
See Iterative Incremental
A piece ofOverwhelmingly,
working/completed
new
that will
be
agilefunctionality
community prefers
estimating
in Story
added on to an existing base the
solution.
Points over estimating in Ideal Days.
Agile Glossary © 2011 Multi-Media Publications Inc.
Page 3 of 11
Incremental
Development
A classification of solution development methodologies
characterized by their up-front prioritization of features and then
the building of the features with one Increment being completed
every Iteration. One benefit of Iterative Development methods is
the ability to deliver business value early as, after several
Iterations, the emerging solution may have enough working
features to be considered useful for some business purpose. At
this point, the project could be terminated, saving time and
money, or it could continue adding Increments of functionality
until the solution is deemed complete. Another benefit of these
methodswill
is abe
high
level into
of quality
to the ability
to put the
Iteration
A project schedule
divided
severaldue
Iterations
wherein
work
will
be
performed
that
will
slowly
evolve
the
entire
solution
riskiest elements in early Iterations so that the design can
be
over
time.
Iterations
are
managed
as
a
Timebox
with
fixed
start
validated through a Spike, plus the Regression Testing that
and every
end
dates.
Iteration Backlog
A list containing all of happens
the work
(expressed
as tasks) that needs to
Iteration.
be completed during an Iteration. Along with the task name, the
Iteration Backlog usually contains a task owner, original effort
estimate in hours, and an estimate to complete the task in hours.
tasksplan
in the
effectively
Iteration Plan
The detailedThe
project
forIteration
the tasksBacklog
to be performed
by form
the the Work
Breakdown
Structure
(WBS)
for
the
Iteration.
project team members during an Iteration. Iteration plans are
developed at the start of each Iteration and are based on the
contents of the Iteration Backlog. A complete iteration plan
would include a schedule (perhaps but not necessarily shown as a
Gantt Chart), a resource plan, and a financial plan - but only for
the specific Iteration. Higher-level project plans, such as a quality
plan
risk
arewhere
handled
at the Release
Iteration Zero
The agile termorfor
themanagement
first projectplan
phase
important
pieces Planning
level. before a team proceeds
of preparation work are performed
through the solution design/build Iterations. Iteration Zero
activities include initial high-level requirements gathering,
analysis, and prioritization; high-level design; high-level
prioritized
Project
Backlog,
thePoints),
initial Release
Plan, the
andinitial
perhaps
estimating
(usually
in Story
and building
the Iteration
Plan for
the first
design/build
Release Plan.
Outputs
of Iteration
Zeroiteration
include (Iteration
the initial #1).
Agile Glossary © 2011 Multi-Media Publications Inc.
Page 4 of 11
Iterative Development
Building a product or service over the course of multiple
Iterations, with the goal of performing design activities in early
Iterations, constructing in middle Iterations, and quality assurance
activities in later Iterations. With Iterative Development, features
of the solution are completed across several Iterations. The
difference between Iterative Development and Linear
Development is that Iterative Development provides opportunities
Iterative Incremental
An approach for
to developing
a new product
or service that
prepares
demonstrating
in progress
Development
a high-level design
of the entirework
solution
up front,and
the capturing
slowly project
stakeholder
the end
of each Iteration.
builds that
solution feedback
over time,atwith
functionality
being delivered
during every Iteration, in order of business priority. Agile
methods are Iterative Incremental Development methods, but are
lightweight/flexible
than
other IID methods
such as the
Kaizen
A Japanese more
term that
comes from Lean
management.
See
Rational
Unified
Process.
Retrospective.
Kanban Board
A technique derived from Toyota’s implementation of Lean
Manufacturing where a signs are used to notify others of the status
of a particular production stage. On agile projects, teams often
implement this via a “Kanban Board” which is divided into
columns, each column referring to the status of a User Story; for
example, not started, designing, building, testing, and completed.
User Stories, summarized on Story Cards or Post-It Notes, are
moved by the team from one column to another as the User Story
works its way through the solution design/build process. The
Kanban Board gives a very visible way for any stakeholder to
Lean Development
An agile
thatofapplies
the basic
principles
of be
lean
quickly
seemethod
the status
an Iteration,
it candevelopment.
also
used by
manufacturing
and applies
them toand
product
the
solution
development
team
to
signal
the
next
team
member
in
Model Storming
A term covering the just-in-time design modeling sessions that
agile
team
members
perform
throughout
the
project.
In
agile
the development process that a piece of work is now ready for his
projects, detailed solution design is not completed at the start of
or her action.
the project (see Iteration Zero); rather, only a high-level design is
completed, and then during the various Iterations of the project,
the team members perform the detailed design activities for the
User
Stories
they are
developing
on a just-in-time
basis - this is
Muda
A Japanese
term
that comes
from
Lean management.
See Waste.
called Model Storming.
Agile Glossary © 2011 Multi-Media Publications Inc.
Page 5 of 11
Onsite Customer
Agile methods require frequent interaction with the key business
stakeholders who give direction to the team, provide clarification
on, make decisions on the spot, and immediately escalate issues.
In Extreme Programming, this is called Onsite Customer, with the
thatand
at risk
leastmanagement
one key business
stakeholder
is working
Pair Programming
Aintent
quality
technique
from Extreme
the core team
members.
Programmingcollocated
where twowith
programmers
are sitting
at one computer
creating software. One writes the software, while the other looks
over his or her shoulder to inspect the newly-written code for
defects at the time they are created. Another benefit is that the
two can brainstorm alternate solutions to problems, gaining the
benefits of the knowledge and experience of both programmers,
resulting in a better solution. This technique can apply more
Pig
A term from
Scrumtoidentifying
a project stakeholderforwho
has one could
broadly
non-programming
direct
control
over aspects of asituations;
project. Pigs example,
include project
team
have
two
designers
working
together
on
one
design
task
to
ensure
members, the project manager (called Scrum Master), and the
that
the resulting
wasThe
optimal
and of
defect
sponsor
(called
Productdesign
Owner).
opposite
a Pigfree.
is known
Planning Game
A method of estimating the Story
Points
required
to
complete
a
as a Chicken.
Chicken.
User Story. In the Planning
Game,See
a cross-functional
team briefly
discusses a User Story with the Product Owner (or delegate) to
understand the relative complexity of building the feature. Then,
the team members simultaneously turn over cards that have their
estimate written on the reverse. By showing their cards
simultaneously, the team members avoid the impacts of “group
think” - a process whereby a dominant voice (or peer pressure)
sways meeker team members into providing the estimate favoured
by the dominant members of the group. Using the Planning
Game, the voices of dominant team members are allotted equal
weight as those of other team members, allowing a brief
discussion to ensue to better understand outlying (higher or lower
than average) estimates. Once the team has discussed the reasons
behind the outlying estimates, the team members once again each
turn over a card that reflects their possibly-revised estimate. Over
the course of a few estimating rounds, the team will likely
converge on a common estimate. Another benefit to the Planning
Game isInc.
the group bonding and improved cross-functional
Agile Glossary © 2011 Multi-Media Publications
Page 6 of 11
knowledge sharing that can take place during the discussions of
Product Backlog
Product Owner
Project Backlog
A list of all possible features that could be included in a product
over the course of its lifecycle. The Product Backlog may be
divided into a number of product versions, each of which will
constitute a project and each of which will have its own Project
Backlog. The Product Backlog is usually owned and maintained
by a strategic business unit such as marketing or product
A term fromdevelopment.
the Scrum method
for the business
person
The Product
Backlog
used toinbuild
strategic
responsible for delivering
value
via theisproject
exchange
for a
product
detailing theThis
product
lifecycle.
monetary
and roadmaps
resource investment.
person
may also be
known as the project sponsor. In some projects, the Product
Owner may delegate day-to-day project interaction and decisions
to another
business
as a business
A list of solution
features
andresource
other keysuch
deliverables
that analyst
remain or subject
to be completed on thematter
project.
At a minimum, the Project
expert.
Backlog contains a list of the features and other deliverables to be
created during the project, listed in priority sequence, along with a
size estimate for each, usually expressed in Story Points. The
Project Backlog is owned by the business sponsor (Product
Owner). Both internal (the core project team) and external
stakeholders (Chickens) can add items to the Project Backlog as
they are uncovered during the project. The business sponsor will
then be responsible for inserting the new items into the Project
Backlog at the appropriate level of priority, with some guidance
from the core project team (so that dependencies between features
are respected). The Project Backlog gets updated frequently
throughout the project using the Backlog Maintenance process. In
Project Burndown
A line graph showing a trend line for the total number of Story
the Scrum
Backlog
is oftenThis
called the
Chart
Points remaining
withinmethod,
a projectthe
asProject
it changes
over time.
total“Product
number Backlog”
of points remaining
from
the Project
Backlog.
though thiscomes
is often
confusing
given
the
The
vertical
axis
reflects
the
total
number
of
points
of
work
alternate meaning of Product Backlog described in this document.
remaining
to be
completed,
while
the horizontal
axis is divided
The
alternate
meaning
in this
document
is the newly-emerging,
into the Iteration planned
for themeaning.
project. The slope of the trend
preferred
line, if extended to the right, will show the number of required
iterations to complete all of the scope on the Project Backlog,
where it crosses the x axis. In the Scrum method, this graph is
often called the “Product Burndown Chart” but emerging usage
tries to eliminate
confusion by deprecating thisPage
alternate
name.
Agile Glossary © 2011 Multi-Media Publications
Inc.
7 of 11
Refactoring
Over time, multiple changes to a component to accommodate new
User Stories/features can lead to a sloppy implementation of the
component. This can lead to poor solution performance, or a
design that is so convoluted that it makes it difficult to
understand, maintain, or to extend with new functionality.
Refactoring is the process whereby sloppy solution components
Regression Testing
Retestingare
portions
of a solutiontothat
were
already
tested inand
earlier
laterRegression
restructured
make
them
moreonefficient
Iterations.
testing
is important
agile projects,
understandable.
where designs emerge over
time, and that changes made in later
Iterations may impact solution components built in earlier
Release
A planning construct that includes one
or more Iterations.
Iterations.
Generally, Iterations build small increments of functionality into a
solution and there is often little justification of deploying the
output of each Iteration to the extended business stakeholder
community. Releases are a way of recognizing that, while the
business still reviews an end-of-iteration demonstration of the
work completed in each Iteration in order to assess progress and
provide feedback, there still needs to be a critical mass of
functionality created before the business would go through the
cost of
and
effort required
to deploy
it; for
therefore,
a Release is a
Release Plan
The equivalent
a high-level
project
schedule
agile projects.
The Release
Plan contains
a view ofenough
the overall
timeline for
of the
grouping
of Iterations
that includes
functionality
the
project,
showing
key
milestones,
the
start
and
end
dates
for
business to achieve some value in taking on the costs of bothering
Releases,
andit.the
start and
endconsist
dates of
forone
each
Release
to deploy
A project
will
orIteration.
more Releases.
Plans also list the User Stories/features to be delivered during
each Iteration. The Release Plan gets updated at the start of each
Retrospective
A continuous
improvement
activity
performed
at the
of an and any
Iteration
to learned
reflect
actual
productivity
(seeend
Velocity)
Iteration where
lessons
are captured
for immediate
changed
project scope or prioritization.
application in the upcoming
Iteration.
Running Tested
A measurement used in Extreme Programming to track the
Features
growing “completeness” of a solution as it evolves over many
Iterations.
Scrum
An agile method developed by Jeff Sutherland with later
contributions by Ken Schwaber. Scrum is an agile method that
focuses on project management processes rather than solution
development processes. It is the most common agile method.
Scrum Master
The Scrum term for a project manager.
Agile Glossary © 2011 Multi-Media Publications Inc.
Page 8 of 11
Spike
Sprint
Sprint Backlog
Sprint Burndown
Stand-Up Meeting
Story
Story Card
Story Point
A functional test or proof of concept that assesses whether a
solution design approach is feasible. A spike requires detailed
design of one simple transaction or message (possibly an artificial
transaction used just to perform the spike) that tests whether
overall design decisions are valid and whether the selected
approach is possible. Spikes often travel through many
interconnected components, testing the interfaces between the
components and how the system will behave as a whole. Spikes
See Iteration. are not used to build required functional components of the
See Iterationsolution;
Backlog. rather, they are used only to gather data to make design
See Burndown Chart.
decisions or to validate whether prior decisions were correct.
See Daily Scrum.
See User Story.
An index card (or Post-ItTM Note) used to capture User Stories
during planning sessions. Story Cards contain a brief summary of
a User Story (usually expressed in a sentence or even just a few
words), the estimate of the story’s complexity (usually in Story
Points), the story’s priority, and any notable information about the
story that emerged during stakeholder discussions. Story Cards
are
a low-tech
for documenting
User
Stories
that allows
A unit of measure
for themethod
complexity
of completing
a User
Story.
stakeholders
rapidly
and prioritize
the stories
moving
Story Points to
include
thegroup
following
factors: work
effort,by
technical
the
cards
around
on
a
table
or
when
posted
on
a
wall.
risk, resource constraints, business risk, requirements instability,
stakeholder commitment, and others. Story Points are the
preferred unit of measure for estimating User Stories as they have
many advantages over other alternatives such as Ideal Days.
Agile Glossary © 2011 Multi-Media Publications Inc.
Page 9 of 11
Test-Driven
Development
Timebox
User Story
Velocity
Waste
An agile management practice for quality management. There are
two different aspects to Test-Driven Development, one that
affects solution designers and one that affects solution builders.
For the former, customer acceptance criteria are gathered for each
User Story at the time the story is documented, and these
acceptance criteria are passed on to the solution designers; to
achieve a high level of efficiency, the designers, in turn, will use
these acceptance criteria as illustrations of requirements,
designing a solution that satisfies the acceptance criteria, but no
more than that. Solution builders will take these same acceptance
criteria and turn them into test cases, which get written before the
solution
satisfying
those
acceptance
criteria isand
built. These same
A fixed period
of time
in which
work
will be scheduled
test
cases
are
used
to
verify
whether
the
solution
meets the
performed. If the forecast duration of the work exceeds
the
original
customer’s
to ensure
the solution
passes
Timebox
length,expectations,
then work needs
to bethat
removed
from the
easily
through
acceptance
testing
at
the
end
of
the
project,
and
Timebox or resources need to be added to complete the work to
A way of documenting awithin
feature
of given
a solution
that
meets
a
help optimize
the
project
delivery.
time.
See
Iteration.
business requirement.the
Generally,
User
Stories
reflect steps within
a larger business transaction workflow (often defined in a Use
Case) and can be documented on Story Cards, among other
A measure of the
amountUser
of work
completedupduring
Iteration.
Stories
onnumber
thean
Project
Backlog.
It ismethods.
usually expressed
as anshow
absolute
of points
or ideal
days. Alternately, it can also be expressed as a percentage
showing the ratio between the number of points completed versus
the number of points planned for a given Iteration. Velocity can
be a measure of actual performance (historical Velocity) or
(forecast
Velocity
Any task onpredicted
a project performance
that uses resources
butVelocity).
which does
not is used to
translate
Project Backlog
Release is
Plan,
to assess
a team’s
createabusiness
value forinto
the acustomer
considered
Waste.
Features
that
are
not
completed
during
an
iteration
are
often
performance,
and to
the accuracy
of a team’s
estimates.
thought
of as waste,
asassess
they consumed
resources
but did
not make
it into the customer deliverables, which means that they are (as of
yet) creating no business value. Waste also includes items that
delay the project, features added above the optimal number for
maximizing the business case/delivery of value, and
misunderstanding requirements (also known as “building the
wrong thing.”)
Agile Glossary © 2011 Multi-Media Publications Inc.
Page 10 of 11
Whole Team
XP
An agile concept whereby a holistic team, representing all
required roles, works together to perform planning, design,
estimating, and similar activities. By working together across job
functions, the team members can better collaborate, the project
can benefit from the knowledge and experience from all of the
roles, and the team can build closer working relationships
See Extremeproject
Programming.
across an organization’s functional boundaries.
Agile Glossary © 2011 Multi-Media Publications Inc.
Page 11 of 11
Kevin Aguanno
PMP, IPMA-B, MAPM, Cert.APM
Certified Executive Project Management Strategy Consultant
Specialist in Adoption of Agile Management Methods
Phone: (416) 540-8570 / Fax: (905) 986-5777
Web: www.AgilePM.com / Email: [email protected]
PM Consulting Offerings
Project KickStartTM - Getting a project started in the right direction is a big contributor to project success. Tis offering will help teams new to project management or
the project approach and plans will help those
reducewith
the large,
risk ofcomplex
project projects, where an independent review of
Don’t Forget PM Training!
failure and identify additional efficiencies.
Kevin Aguanno is an award-winning trainProject HealthCheckTM - When things don’t appear to be going
er and university instructor with courses
well, an outside expert assessment will identify what you’re doing
on the following
PMDevelopment
topics:
• Introduction
to Systems
well, and what could be improved. Trough interviewing stakeLifecycles (SDLCs): Waterfall to Agile
holders, team members, the project sponsor and the project manag•
Introduction to Recovering Troubled
er—in addition to reviewing key project documents—this offering
Projects
Troubled Project
Despite
ourproject.
best-laid plans, someassessesRecovery
the health of- an
in-flight
• Project Scheduling from Traditional to
times projects get mired in technical, management or personnel isExtreme
sues and needless bureaucracy. Let us help you with our expertise in
• Earned Value Management, Metrics and
quickly assessing the situation and making the necessary changes to
Financial Controls
•
Project
Closeout Best Practices
get
a
project
back
on
track.
Individual PM Competence Assessments - Tap into years of ex• Rewarding Team Members to Improve
perience assessing project managers of all experience levels to meaProject Performance
sure their competence against international standards. We provide
• Project Risk Management
individualized recommendations for skills development and project
• Fundamentals of Project Management
management career planning—a great reward for your star perform• IPMA Level-D Exam Preparation
Project Management/SDLC ers.
Methodology Consulting - Over
time, our standard project governance and delivery processes tend
to get inefficient as new elements get added to prevent the reoccurrence of past failed
projects. Eventually, productivity suffers as all projects become burdened with needless bureaucracy. Let us help you identify the right methodologies for your projects,
and then help you adapt them to match your individualized business environment,
smoothing the transition to the new methods with phased adoption roadmaps. We
can also help improve existing methodologies with incremental changes to improve
project efficiency while still preserving necessary project oversight.
Agile Consulting Offerings
Agile Project KickStartTM - Scrum and other agile methods tell us how to efficiently
execute highly-complex or high-change projects; however, most fail to give guidance
on how to effectively steer a project through the various stages of pre-initiation reviews
and funding approvals. Tis offering helps you estimate an agile project business case
and plan your agile project at the right level of detail to get it through your project
fundingAgile
approval
process, while
still maintaining
a quick,
lightweight
Contract
Review
- Once your agile
project’s
businessapproach.
case is Get
Agile Training Also Available
approved, you’ll need to get some form of help
agreement
in
place
befrom an expert in making agile work in large enterprises.
tween the business sponsor and the delivery team. Tis might be a
Kevin Aguanno is an award-winning
formal contract between two companies, or it may be a less formal
trainer and university instructor with the
document of understanding (DOU) between two departments in
following agile courses available as public
the same organization. Tis offering gets you expert help to build
or private sessions. Prepare to write the
your agile contract—either time and materials or fixed price—to
PMAC’s Certified Agile Project Manager
• Introduction to Agile Project Manageminimize
your
risk
while
still
giving
the
sponsor
the
flexibility
deexam or the newment
PMI agile exam.
Agile Project HealthCheckTM - Agile projects use different metsired
from
an
agile
approach.
rics and reporting techniques than traditional project management
• Agile PM Upgrade for ScrumMasters
approaches. As a result, PMOs and risk managers have a difficult
• ScrumMaster Bootcamp
time assessing whether an agile project is healthy or if there are early
• Agile Estimating and Planning
warning signs that it is getting into trouble. Tis offering brings in
• Agile Bootcamp for Project Sponsors,
Product Owners and Business Analysts
an expert assessor to review your agile project and let you know if
Organizational Agile
Readiness
Assessment
Considering
a
move
• Conducting an Agile Project Health
your project is agile... or fragile.
Check: New Perspectives for PMOs,
to agile? If so, you should know what challenges to expect—specific
Risk Managers, and Auditors
to your organization—and what to do about them. Get help from
• Advanced Agile Management Techa top industry expert in enterprise agile adoption as he assesses your
niques
personnel, your processes, your support systems and tools, and your
governance structure to see how ready is your organization. Te final
Agile
- Transitioning to agile requires significant changes in your
report includes findings and
andAdoption
recommendedStrategy
improvements.
management processes and metrics, your project delivery processes, and how your
team members work together. Most organizations face serious challenges—some quite
significant—when adopting agile methods. Why reinvent the wheel where others have
already gone before you. Have one of the top industry experts on agile transformations
Agile help
Methodology
Consulting
- Having
trouble adapting
agileyour
methods
you develop a customized,
phased,
agile adoption
strategy for
group.to your
unique company circumstances or to your individual project? Get help from an agile
methodology guru who can assist you with incorporating individual agile techniques
or tailoring a whole agile method.
Phone: (416) 540-8570 / Fax: (905) 986-5777 / Web: www.AgilePM.com
/ Email: [email protected]
Managing Agile Projects, First Edition
by Kevin Aguanno (ed)
Multi-Media Publications Inc.. (c) 2004. Copying Prohibited.
Reprinted for Jayalakshmi L, Cognizant Technology Solutions
[email protected]
Reprinted with permission as a subscription benefit of Skillport,
http://skillport.books24x7.com/
All rights reserved. Reproduction and/or distribution in whole or in part in electronic,paper or
other forms without written permission is prohibited.
Managing Agile Projects, First Edition
Chapter 11: Requirements Documents that Win the Race
Kirstin Kohler
Time-constrained projects ask for requirements approaches
that are agile: that is, adapted to the project needs and without comprehensive documentation. But how can
Barbara Paech
this be achieved? Our approach provides the steps toward the solution of this question. It supports the identification of the essential content of the requirements document
as well as the selection of the appropriate modeling technique. The essential content is determined by conducting a systematic risk analysis, which allows identifying the
most important elements of the requirements documentation. For the requirement document to be useful, it must be precise and understandable for all project participants.
The appropriate modeling technique is selected by taking the identified content and the context of the project into account. This chapter reports work in progress. It describes
the motivation, related work and first ideas.
Introduction
It is well known and widely accepted that a lot of problems in software development are caused by deficiencies in the requirements phase. [20] Nevertheless, a lot of
companies lack requirements engineering activities. [17] Especially in projects where time-to-market is critical to success, there is usually not enough time for investments in
the requirements engineering process. [16] In order to overcome this resistance against requirements engineering in industrial settings, it is not necessary to invent a new
and hopefully better method. Instead, one should focus on making existing methods more attractive. [22] The goal of our work is to make documentation of requirements
more attractive for time-to-market projects.
Creating and maintaining requirements documents requires substantial effort. [19] This is why it is often neglected, especially when schedules are tight. Whereas Extreme
Programming puts the onsite customer on a project, and thereby reduces most kinds of documentation, [5] our
experience in industrial projects shows that documentation of requirements is crucial for the transfer of knowledge between stakeholders of the
actual project as well as to subsequent development projects. Thus, it cannot be completely disregarded. With our approach, we want to balance the divergent goals of
creating good documentation and keeping a tight schedule. Our slogan is "keep the documentation as small as possible but as substantial and useful as needed for the
project." Our approach gives advice on how to put this slogan into practice. It supports
the following two steps: (1) identify the essential part of the documentation, and (2) choose the appropriate modeling technique to document them. We reflect the project
context [23] in both of these steps, especially in the definition of "essential" and "appropriate". With our work, we do not invent a new requirements engineering method, but
rather provide[20]
guidance
van Lamsweerde,
on how to use
A. "Requirements
existing methods
Engineering
efficiently. So
in the
far Year
we have
00: A
limited
Research
the framework
Perspective."
according
Proc. 22nd
to twoInternational
dimensions: Conference
(1) it supports
ononly documentation of
requirements,
(2) it considers
only
GUI-intensive
systems.
Softwareand
Engineering,
Ireland,
June
2000.
[17]Morris, P., Masera, M., and Wilikens, M. "Requirements Engineering and Industrial Uptake." Requirements Engineering. 3, 1998.
[16]Mead, N. R. "Why Is It so Difficult to Introduce Requirements Engineering Research Results into Mainstream Requirements Engineering
Practice?" Proc. Fourth International Conference on Requirements Engineering. Illinois, June 2000.
[22]Wiegers, K.E. "Read My Lips: No New Models!" IEEE Software. September/October 1998.
[19]van Schouwen A.J., Parnas, D. L., and Madey J. "Documentation of Requirements for Computer Systems." Proc. IEEE International
Symposium On Requirements Engineering, San Diego, California, 1993.
[5]Beck, K. Extreme Programming Explained: Embrace Change. Boston: Addison Wesley, 2000.
[23]With context we mean important factors influencing the software project.
Basic Steps of the Approach
In order to document requirements for time to market projects, it is important to make a trade off between quality and schedule. Gaps or faults in the requirements phase, as
a consequence of missing documentation, lead to dissatisfied customers due to quality problems in the end product. In contrast, "high quality" software development
including comprehensive documentation takes longer, so customers often choose competing products. The product is of less value due to an unsatisfying market
penetration. Narrowing these conflicting dependencies to the scope of requirements documentation means making the tradeoff between no documentation leading to bad
quality and complete documentation leading to delayed product delivery. The solution is to keep the documentation as small as possible but as substantial and useful as
needed for the project. We accomplish this by supporting the two steps "Identify essential content" (ensures small and substantial) and "Choose appropriate modeling
technique" (ensures useful). Figure 11-1 shows the two basic steps of our framework in relationship to the basic ingredients: the project risk, conceptual information model,
the project context, and the modeling technique. How these ingredients are integrated in our approach is described in the following subsections, where the steps are
Page 2 / 9
elaborated in more detail.
Reprinted for CTS/316124, Cognizant Technology Solutions
MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited
Managing Agile Projects, First Edition
Figure 11-1: Steps and concepts of the approach.
Identify Essential Content
The basic idea is not to document the complete requirements, but instead concentrate on the most important or essential parts. Finding and separating these essential parts
poses a classical filtering problem: separating the requirements that are worth being documented from those that are not critical and need not be documented. In general,
a filter separates material or waves according to specific characteristics like grain size or frequency. The materials in our case are the requirements, and we use a
conceptual information model to classify the
requirements. The filter in our approach separates requirements according to risk. It separates those requirements that are accompanied with a high risk from those that
are accompanied with a low risk. The size of the risk (comparable to the size of grains passing the filter) is influenced by the project context. We provide an approach for
assessing the risk by considering different risk types, as shown later in this chapter. The next step is to document the requirements; therefore, one has to choose a
Requirements documents are a medium of communication and knowledge
transfer.
In order to gain the most benefit out of them, they have to be precise and
representation
technique.
understandable for project participants and involved stakeholders (besides other qualities like correctness, consistency, and so on). Choosing the appropriate modeling
Choose
Modeling
Technique.
technique is essential. The modeling technique has to fit to the
contentthe
thatAppropriate
is documented,
as well as
to the people who will read the document. For example, the navigation
of dialogues can be documented by using Constantine's abstract
prototypes, [9] whereas the interaction between system and users in terms of function calls might be documented by use cases. [7] Depending on the individual project team
members (who might include graphic designers, for example) specification languages like UML might not be suitable. This means that, when deciding about the appropriate
modeling language, the content as well as the project context have to be considered in order to make the documentation valuable. Later in this chapter, we will describe how
The arrow leading back to the start in Figure 11-1 indicates
thatcontext
our approach
not
limited to
waterfall
projects wherein all requirements are known at the
the project
guides is
the
selection
of classical
the modeling
technique.
beginning. The technique should be applied in iterative projects too. It can be applied independent of the process model of the project, and fits at the point where one
has roughly understood the requirements (or a subset of them) and has to document them in more detail. Our approach helps to decide which part of these
to document and how to document them.
[9]Constantine, L., Lockwood, L. Software Forrequirements
Use. Boston: Addison Wesley, 1999.
[7]Cockburn, A. Writing Effective Use Cases. Boston: Addison Wesley, 2001.
Identify the Essential Documentation Content
We elaborate on the step of identifying the essential documentation content by explaining the three concepts we have built on: the conceptual information model, the
project
risk,
projectWhat
context.
Before filtering the essential requirements, we have to make explicit
what
weand
arethe
filtering.
is the totality of requirements we are choosing from? To improve the
understanding of a complex subject, physicists and chemists usually introduce models to help with representation. We
Page 3 / 9
Reprinted for CTS/316124, Cognizant Technology Solutions
MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited
Managing Agile Projects, First Edition
needed a similar model that allows us to think and argue about requirements, especially in the context of the filtering process. Unfortunately,
however, there is not a standard model for GUI-intensive applications comparable to the Parnas' model for embedded systems [19] (at least we are not aware of one after
an extensive literature search). Thus, we developed our own conceptual information model for GUI-intensive applications.
Conceptual Information Model
The conceptual information model describes the various elements and abstraction levels for requirements of interactive applications (excluding non-functional
requirements). The model is based on Kovitz' understanding [13] that requirements activities lead to design decisions. During the requirements phase, decisions about
the effect generated by the software to be developed are made. For interactive applications we identified 12 types of these "design decisions" (see Figure 11-2).
Figure 11-2: Conceptual information model consisting of 12 types of design decisions.
These can be categorized into 4 groups (decisions about tasks to be supported by the software, decisions about functions implemented by
the software, decisions about the application kernel, and decisions about the user interface). Each of these groups is on a different abstraction
level. For the sake of brevity, we will not go in the details of this model, but rather we will refer the reader to Kohler and Paech. [11] The elements of the model allow us to
argue on a conceptual level about different types of requirements. Therefore, one can explicitly name which type of the requirements should or need not be documented. As
a simple example, if a new interface for an existing legacy system has to be implemented, it is important to specify the dialogs and navigation of the user interface, whereas
the documentation of the application kernel requirements is less important.
The 12 elements in this model form a tree, in the sense that the elements of lower levels depend on the decisions made before. The decision to support "the task of book
ordering" leads to specific dialogs and functions like a "dialog to confirm selection" and "a function to calculate invoice." The tasks span a tree of dependent decisions. The
set of all "tasks" to be supported builds a set of trees as illustrated in Figure 11-3. Each triangle in the picture represents one "task tree". This does not mean that the
decision to document a lower level requirement implies that the corresponding higher-level requirement must be documented. It must only be clear which tasks a specific
functional requirement belongs
to.
Figure 11-3: Set of task trees. Dots indicate the design decisions of Figure 11-2.
It is so far an open question of how to identify the essential tasks, and which ones should be documented at all.
Page 4 / 9
Reprinted for CTS/316124, Cognizant Technology Solutions
MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited
Managing Agile Projects, First Edition
Now we come back to the filtering process. Similar to testing of time-constrained projects, [3] we use the concept of risk analysis to guide the selection of the essential
requirements.
Risk
We define risk as the possibility of suffering a loss. [10] This means that to asses the risk, we have to know the probability and the loss linked with the risk. We base our risk
analysis on a method introduced by Kontios [12] who defined an effect chain consisting of risk factor, risk event, risk outcome, risk effect, and utility loss (see Figure 11-4, left
side). Without going into the details of Kontios' method, we explain the elements in the context of the requirements documentation (see Figure 11-4, right side).
Figure 11-4: Kontios' risk effect chain instantiated for the requirements documentation.
The risk event in our example is the missing documentation of requirements concerning the user interface (the design decisions we explicitly decide not to document).
Missing documentation of user interface requirements can cause misunderstandings, which lead to wrong, superfluous, or missing navigation and dialogs in the software
(risk outcomes). To judge the extent of the risk event and outcome, one has to
investigate which risk factors make the event likely (for example, on a distributed team, the probability [24] to cause a misunderstanding due to missing documentation is
high) and which risk effects cause a high damage (for example, a late product delivery due to superfluous functionality that might result in a missed window of opportunity
and a loss of market share). The project context is essential for both of these questions. The project context defines the risk factors and therefore the probability that the risk
event happens.
And the project goals that are also defined through the context define the risk effects caused by the risk (the utility loss). Therefore, the risk analysis can be
n What factors of the project context increase the probability of a misunderstanding?
reduced to the questions:
n What project goals increase the utility loss caused by a misunderstanding?
The reflections about risk can be transferred to our conceptual information model. For each of the 12 elements of the model one has to consider which context factors
enlarge the risk that a missing requirement of this type leads to a misunderstanding. But before this can be done, we have to define how to describe the context. How
can one be sure to consider all relevant factors?
Project Context
The problem of context description gained importance within the last years in the domain of knowledge engineering, and constructing experience factories for software
projects. [4] But due to the fact that this is a young research community, and the relevant factors pretty much depend on the usage of the packaged experience, there is no
silver bullet of context description. We used a scheme proposed by Birk [6] and adapted it to our needs in requirement engineering. Table 11-1 contains all factors to
consider for a project characterization.
Table 11-1: Attributes for the context description.
Reprinted for CTS/316124, Cognizant Technology Solutions
Page 5 / 9
MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited
Managing Agile Projects, First Edition
Attribute
Number
Experience
Roles
Customer
Suppliers
Distribution of stakeholders
Availability of stakeholders
Application domain
Lifecycle & history
Type of product
System size
Lifetime of the product
Architecture
Product quality goal
Business goals
Development process
Techniques
Tools
Standards
Weighting of activities
Duration of the project
Work products
Example
Stakeholders
Number of people in the development team
Experience in OO technologies
Requirements engineer, user interface developer, graphic designer, etc.
Development for customer X
Usage of COTS products
Requirements engineers and developers at the same location, or a distributed development team
People that developed the former product version left the company. User access.
Product
Web system, embedded system
Reimplementation of an existing product. Maintenance.
Consumer product
20 components. 100 KLOC.
The product has to be supported until the end of 2010
Client/Server architecture
Goals
Reliability is more important than usability
Time-to-market is more important than usability
Process/Technology
Iterative development. RUP.
Onsite customer interviews for elicitation of requirements. Prototyping of user interfaces.
DOORS to manage requirements
Documentation of requirements according to standard IEEE 1233-1998
30% of the total development effort is spent on the requirements phase
The development of the project will be finished within one year
Test cases have to be documented
With the information model, the risk analysis, and the attributes of a project context description, we have now all tools at hand to support the filtering of essential
requirements. A risk analysis of a given project can be conducted by combining the elements of our information model with the various attributes of the project context. For
each project attribute, one has to determine the effect and the probability of a
misunderstanding caused by missing documentation.
Our approach supports practitioners not only by guiding them to the risk analysis. In addition, we provide a set of heuristics. By conducting the risk analysis on a generic
level (without considering a specific project context) and limited to the four main groups of elements in our information model (tasks, system functions, application kernel,
user interface) we identified generic heuristics for the selection of documentation content. They are listed in Table 11-2.
Risk Event
Missing documentation of
tasks
Rick Factor That Enlarges The Probability
Rick Effect That Enlarges the Damage
Table
11-2:
Heuristics
for the risk effect Business
chain. Goals: Tasks to be supported by the software are critical to the
Lifecycle and History: Big changes
from
"as-is"
to "to-be" tasks.
business' success.
Type of Product: Consumer product with a large variety of different
users. Complex user tasks to be supported by the software.
Missing documentation of
functions
Missing documentation of
application kernel
Missing documentation of
user interface
Suppliers: Parts of the system have to be built by COTS products.
Evaluation of COTS products is based upon system functions.
Experience: Developers are not experienced in the algorithms.
Lifecycle and History: No experience of how users will react since this is a
new development
Business Goal: Time-to-market is important and forces us to buy COTS
products to hit a window of opportunity.
Product Quality Goal: The accuracy of the product has to be improved to
increase market share.
Product Quality Goal: Usability of the product is required due to mass
production and associated high support costs otherwise.
Business Goals: Usability is important to reduce costs for training and
support.
The left hand column lists the risk event. We listed one risk event for each decision type: tasks, function, application kernel, user interface. The second column contains
context attributes (risk factors) that enlarge the probability of the risk event. For example, a big change from "as-is" to
Page 6 / 9
Reprinted for CTS/316124, Cognizant Technology Solutions
MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited
Managing Agile Projects, First Edition
"to-be" tasks (risk factor) will increase the probability that a missing documentation of tasks causes damage is high.
The right column contains risk effects and their related product and business goals (given by the project context). They define the size of the damage caused by the risk.
For example, if time is critical for the business success of the company (risk effect) damage caused by the risk event "missing documentation of tasks" is high. If, for a
given project, more than one attribute in a row matches, the risk of omitting this type of requirements in the documentation is high. If either the risk factor or the risk effect is
high, the situation has to be judged individually. In that case, Table 11-2 gives a hint for a potential risk.
Our tables help in executing the risk analysis; however, this risk analysis still requires some extra effort. The identification of essential requirements is necessary for
[13]Kovitz,
project
managers
to focus development
efforts. We strongly
believe
that anand
explicit
riskGreenwich:
analysis isManning
the best compromise
"all or nothing."
B.L. Practical
Software Requirements.
A Manual
of Content
Style.
Publications between
Co., 1998.
[11]Kohler, K. and Paech, B. "Task-driven Requirements in object-oriented Development." Perspectives on Requirements Engineering. Eds. J. Leite and J. Doorn. Kluwer
Academic Publishers, 2003.
[3]Bach, J., "Heuristic Risk-Based Testing." SoftwareTesting and Quality Engineering Magazine. 11,1999.
[10]Dorofee, A. J., Walker, J., et al. Continuous Risk Management Guidebook. Pittsburgh, PA: Software Engineering Institute, 1996.
[12]Kontio, J. "The Riskit Method for Software Risk Management, version 1.00, CS-TR-3782." Computer Science Technical Reports. College
Park, MD: University of Maryland, 1997.
[24]Note that for now we do not propose to denote probabilities by number.
[4]Basili, V., Caldiera, G., and Rombach, H. "Experience Factory." Encyclopaedia of Software Engineering. Vol. 1. John Wiley & Sons, 1994.
[6]Birk, A. "A Knowledge Management Infrastructure for Systematic Improvements in Software Engineering." PhD Theses in Experimental
Software Engineering. Vol. 3. Fraunhofer IRB Verlag, 2001.
Choose the Appropriate Modeling Technique
After having decided what to document, it is now a question of how to document. There is a large variety of modeling techniques available, ranging from natural
language to formal languages like Z. [18] One has to choose the modeling technique that fits best for representing the requirements. It has to fit the content that is
documented, as well as to the people who will read the document.
n ACRE [15] is a framework containing 12 methods for requirements acquisition that are judged by the authors according to their suitability
During the last few years, a variety of methodologies have emerged that aim to guide the selection of technologies or methods:
in different projects. The framework is limited to the 12 methods, and does not cover modeling techniques for documentation. Furthermore, there is a limited number of
project characteristics covered by the framework; for example, the characteristics do not consider the needs of specific applications like interactive or embedded
As part of the PROFES project [6] the concept of PPDs (Product-Process-Dependency-Models) was developed. PPDs describe the impact of a specific
n systems.
technology (like inspections) on a specific product quality goal (like reliability) when applied to a certain process. PPDs also contain a description of the context.
Although this approach seems to be very promising, it is very generic because it is suitable for all kinds of software engineering techniques and not especially
tailored for our purpose of requirements [8]
documentation.
He proposes to choose the appropriate development approach
n In Agile Software Development, Cockburn brought up the concept of the Crystal Family.
dependent on the three characteristics: number of people, criticality of the software, and project priority. We believe that this approach does not consider enough
project characteristics.
We propose a two-fold approach for the selection of the appropriate modeling language. As illustrated in Figure 11-5, we assume the existence of a repository containing a
characterization and description of all available requirements engineering modeling techniques. By specifying the essential content in terms of its design decision types, and
by specifying the project context, the appropriate modeling technique can be determined. We will elaborate on this by referring to the underlying concepts: the decision types,
and the project context description:
n By defining the essential content, one already has selected a subset of decision types, as defined in the conceptual information model. The type of decisions
determines a subset of suitable modeling techniques because not every modeling technique is suitable to describe all types of design decisions. Kohler and Paech [11]
provide a tabular overview of models used in common processes, like RUP [2] or Usage Centered Design, [9] to document design decision types. Typically, after this
selection process, there is still more than one modeling technique left to choose from. Figure 11-6 illustrates this with an example. Based on the decision type "user
interface," three techniques (use-cases, storyboards, and abstract prototypes) are selected by function S1, which represents the selection based on the decision type.
Page 7 / 9
Reprinted for CTS/316124,
Cognizant
Technology
Solutions
n To further narrow down the appropriate modeling technique, the project context should
then be Publications
considered.Inc.,
TheKevin
output
of function
S1,
MultiMedia
Aguanno
(c) 2004,
Copying Prohibited
Managing Agile Projects, First Edition
together with the project context, are inputs for a second selection function, S2. In S2, for each of the specified techniques, the project context attributes are compared to
the attributes of the technique description. The technique with the best match is the result of this final selection mechanism. In the example of Figure 11-6, the project is
characterized by a distributed team consisting of software engineers. Therefore, use cases are selected as an appropriate modeling technique. Storyboards require
special drawing skills and are more difficult to exchange and discuss between different development sites.
Figure 11-5: A repository of requirements engineering techniques for the selection of the appropriate modeling
technique.
Figure 11-6: Selection of the modeling technique based on decision type and context.
The context attributes describing the stakeholders and the process and technology (compare with Table 11-1) support this part of the selection process. Most important of
these context attributes are the stakeholders. Their experience with special modeling techniques and their
individual roles (testers, graphic designers, etc.) have a very high impact on the acceptance of the modeling technique. This is supported by
empirical findings from McPhee and Eberlein [14] who showed that the usefulness of requirements engineering techniques is correlated with the familiarity of stakeholders
with that technique. In addition other "non-requirements engineering" tools and techniques that are already established in the process may influence the selection process.
For example, if UML class diagrams are in use to document the systems design, one should also use them to document the input/output data of the user interface.
So far, our
approach of choosing the appropriate modeling technique consists of initial concepts. This is especially true when considering the relationship between context
[18]
Potter, B., and Sinclair, J. Formal Specification and Z. London: Prentice Hall, 1996.
attributes and the selection of the modeling technique. This challenge needs further investigation.
[15]Maiden, N., and Rugg, G. "ACRE: Selecting Methods For Requirements Acquisition." Software Engineering Journal. May, 1996.
[8]Cockburn, A. Agile Software Development. Boston: Addison Wesley, 2002.
[2]Armour, F., Miller, G. Advanced Use Case Modelling, Boston: Addison Wesley, 2000.
[14]McPhee, Ch., and Eberlein, A. "Requirements Engineering for Time-to-Market Projects." Proc. 9th Conference and Workshop on the
Engineering of Computer-based Systems. ECBS, Sweden, 2002.
Summary and Future Work
Our approach fits the recommendations for documentation of agile software development given by Cockburn [8] who states "Don't ask for
Page 8 / 9
Reprinted for CTS/316124, Cognizant Technology Solutions
MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited
Managing Agile Projects, First Edition
requirements to be perfect" and" Capture just enough." Whereas Cockburn does not give any advice for how to find out what is "enough," we give concrete guidance on
the selection process of critical elements. In addition, it substantiates the demand for adaptiveness as postulated
by the agile community. [1] In that sense, we make the "agile requirements process" more concrete. Therefore, we built our approach on two practices: the systematic
consideration of risk, and the consideration of the project context to drive the documentation in time-constraint projects.
So far, we have provided the skeleton that is now ready to be fleshed out with more details [21]
to guide practitioners in their requirements engineering processes. Our
We want to validate the context attributes through expert
similarly toon
Vegas
who validated
n
future interviews,
work will concentrate
the following
topics: a characterization schema for testing techniques. By doing
this, we will further adapt our characterization scheme for the needs of requirements engineering.
n
n
n
We want to provide more heuristics similar to those listed in Table 11-2. They should not only support the risk analysis for the selection of decision types, but also for
the selection of a subset of task trees as illustrated in Figure 11-3 to determine which tasks must be documented and which can be omitted.
During future projects, by collecting empirical data to investigate the dependency between project context characterization, the selection of the content, and the selection
of a modeling language. We want to better understand the relationship between context attributes and the choices that have to be made based on these attributes.
Knowing these dependencies would be a first step to automatically support the selection process.
[1]And
of course we want to evaluate the complete approach to empirically prove, that our approach is beneficial for the requirements phase of time-constrained projects.
<http://www.agilealliance.org>.
[21]Vegas, S., "Characterization Schema for Selecting Software Testing Techniques." Thesis. Madrid: Universidad Prolitecnica de , February
2002.
Page 9 / 9
Reprinted for CTS/316124, Cognizant Technology Solutions
MultiMedia Publications Inc., Kevin Aguanno (c) 2004, Copying Prohibited