Agile Project Management

Jim Highsmith

Chapter 8

Advanced Release Planning

Failure to keep Release Plans current!

Management needs to know how a business problem will be solved, its

cost, how long it will take, and how much risk is involved!

Agile teams response: “How do we commit to something with a

reasonable assurance of delivery and at the same time leave room for

change, learning and surprises?”

Key is in understanding the purpose of the release plan… to:

– Foster a better understanding of project viability and feasibility

– Outline assessment and mitigation of risk

– Enhance a team’s ability to prioritize capabilities and stories

– Give the team a “feel” for the entire project

– Enable answers to management questions about value, schedule, and cost

– Create a comfort level about the project with both ream members and

management

– Create a plan for partial deployment

Wish-based planning

(balancing capacity and demand)

Managers think they can push teams hard enough they will

respond “heroically”… typical view

Reality… the result is dysfunctional teams, not high performance

teams.

… managers wishing the team can deliver 50 features in the next release

because of market demand, even though developers know that 30 features

is more realistic.

Wish-based planning results

Plans created where demands exceed capacity and development groups are

forced to accept the demands

Schedules and features are missed

Management typical response… improve estimating and planning

skills until the desired plan emerges

Developers often lack…

Appropriate estimating skills

… putting themselves in poor positions by always saying no

Good negotiating skills

Management and marketing “folks” are adept at negotiating

Developers are at a disadvantage with a lack of these skills

The ability to respond to managements use of plans as

“motivators.”

Internal motivation always trumps external / forced

motivation

Multi-level Planning

Executive and managers need some degree of

predictability… for financial and marketing planning

… as well as the ability to adapt to new situations and

information.

… as well as needing to monitor project status

Best perspective… to think at the capability level and

not the story level

Team’s plan reflects reasonable commitment to deliver the

planned capabilities

… but retains flexibility at the story level regarding which

stories would implement the capability

Product Planning Structure (Figure 8-2)

Iteration plan… the day-to-day

work plan for the development

team.

Wave plan… spans several

iterations and planned at the

story level… may represent a

partial deployment release

Release plan… results in a

deployable product (capability

or feature level)

Product roadmap… shows a

multi-release map for a

product’s evolution… over

several years

Roadmap (2 years)

Release (12 months)

Wave (3 months)

Iteration (2 weeks)

Large financial products software company

Product management group had 2-3 year roadmap of business

areas and capabilities to be implemented.

… worked out an 18 month feasible release plan of 300

capabilities for several teams

… each team developed a 3-month story-level wave plan and

then developed detailed story and task level iteration plans.

Each of the plans was updated periodically.

Product Planning Structure (Table 8-1)

Characteristic Release Wave Iteration

Timeframe Long-rage Medium-range Short-range

(6+ months) (3 months) (1-4 weeks)

Level of Detail Capability Story Story/task

Commitment Type Project feasibility Capability

commitment

Story commitment

Deployment Final release to

customer

Possible interim

relapse to

customer

Customer review

process

Capabilities

Capability describes a high-level business or product function

that is complete and valuable…

a story delivers a piece of useful and valuable functionality to a customer.

Story may be 2-10 days of work

Capability may be somewhere between 20-100 days

Capability cases bridge the gap between the wants and needs of

the business and what the system is to do for the business users.

Team's can commit to delivering a set of capabilities, while leaving the

detailed requirements and specifics about implementation (the stories) to

the project team.

Companies need predictability and flexibility. Using a capability-story approach can

provide both predictability at the capability level and flexibility in exactly how those

capabilities are delivered at the story level.

Creating a Product Backlog & Roadmap

Backlog grows over time… as capabilities are converted

to stories

Information about each backlog item improves…

Detail is not added until it is really needed… to avoid normal

changes (Just-In-Time philosophy)

System Change Requests (SCRs) are also added (typical

for legacy applications)

…maintenance requests, persistent defects, small

enhancements, technical debt reduction

Product Lifecycle (Figure 8-3)

Product conceptualization phase leads to a project chartering

session to through the product vision, project scope and

boundaries and release planning activities.

… generating release, first-wave, and first-iteration plans.

… new stories are identified and the backlog list is updated

Product

Conceptualization

Cycle

Initial Product

Development

Cycle

Continuing Product

Development

Cycle

Product Deliver

Continuous Flow of Value

Product

Release

Plan(s)

Product

Backlog

Product

RoadmapWave and

Iteration

Plans

Note: “… UML modeling can be valuable as a documenting technique, but is also

has caused many organizations to go diagram crazy.”

Optimal Planning Structures…

… oriented to mature agile organizations.

Two scenarios:

1. A product development effort in which the product

is continuously evolving over a multi-year period

“most typical”

2. A major product development or re-development

effort in which the minimum releasable functionality

takes 12 or more months to deliver

… a significant amount of functionality must be developed

before an initial release can be made

Value Point Analysis

Stories are small chunks of functionality… and estimates are either in terms of relative size (story points) or absolute terms (hours).

Value points… translate this data to cost?

Beneficial …value points:

– indicate to executive management a serious, quantitative approach to value

– assist teams in making priority decisions during release, wave, and iteration planning

– can assist teams in negotiating depth of story functionality (e.g. is a 3-value-point story worth 21 story points?)

– help increase ROI by pushing the planning of high-value capabilities and stories earlier

Value Point Determination

Done by the “product team”, headed by the Product Manager.

The development team needs to estimate effort at some level (story, capability) to develop a full release plan…

Value Point estimating can be just-in-time (JIT)

Story Point estimates have a built-in feedback process to correct bad estimates… not the case for value point estimates

Two methods to produce relevant & useful value point estimates:

1. Limit estimates to a short series of numbers (1, 2, 3, 5, 8, 13)

2. Allocate total value points on a percentage basis to capabilities (caps the number of value points in a set of stories)

Capability point values (1, 2, 3, 5)

5 capabilities with capability points 2, 3, 3, 5, 1

Convert to percentages 2/14, 3/14, 3/14, 5/14, 1/14 14%, 21%, 21%, 36%, 8%

Assign value points to the stories in each capability… and sum these for each capability

Total value points for each capability should have a 14%, 21%, 21%, 36%, 8% distribution

Story Cards with Value Points (Figure 8-4)

During iteration planning… if stories with low value-points but

high story-points, an assessment of whether or not the low-value

story (V-2) is worth the estimated work (C-21) should occur.

As a sales associate,

the ability to calculate

the total amount of

the sale

V-13 C-13

As a sales supervisor, the

ability to verify the

adequacy of the customer's

credit rating.

V-2 C-21

As a sales executive, the

ability to view all sales b

product type, geographic

region, and sales associate.

V-3 C-8

Value and Cost Delivered (Figure 8-5)

0

50

100

150

200

250

300

350

400

450

1 2 3 4 5 6 7 8 9

Cum Value (NPV)

Cum Cost

# Stories

# S

tori

es, D

oll

ars

Iterations

NPV

Actual

Costs

Non-customer facing stories

… technical debt reduction stories, refactoring stories.

Technical stories that support customer facing ones.

These are typically investment type stories.

Priority setting issue… who decides?

Product teams do not usually understand technical debt

reduction, maintenance items and technical infrastructure

stories.

Collaboration and trust is needed… a prerequisite

characteristic of a mature agile development process

Planning themes and priorities…

To bring an appropriate focus to business value, project need both an overall “vision” and shorter-term “themes” that implement the vision.

Themes can be useful for iterations and in larger projects for waves

Types:

Business function groupings of capabilities, features or stories

Business process flow is a sequence of business functions that produces some final result (e.g. order-to-shipment, bill-to-payment… )

Risk mitigation focus early on… where technical hurdles need to be overcome

Partial deployment plans… may impact feature/story implementation priorities and create wave themes

“The key question a team should ask itself at the end of

each iteration is, “What is keeping us from shipping a

product right now?”

Note… when practicing one iteration-at-a-time

planning, higher level themes may get lost.

Teams should not get in a positon where pieces of

multiple capabilities are finished… but nothing is usable

to the customer.

Increasing productivity…

Do better, or do less!

Familiar data: “… over 64% of software functionality is rarely or never used, whereas just 20% was often or always used.”

One of he reasons for projects becoming larger and larger is the absence of immediate feedback on efforts to accomplish individual features… the source of “featuritis”

User requirements… list of 50 to 200 items.

“The most interesting thing… learned… was by the time we got to 20, nobody is interested in the remaining 80 or more items.

Agile project can improve productivity by doing less in two dimensions – breadth (the list of requirements) and depth (implementing a req’t or story but altering the depth of functionality.

Risk Analysis and Mitigation

Core risks that dominate software projects:

1. Inherent schedule flows

2. Requirement inflation (creep)

3. Employment turnover

4. Specification breakdown

5. Poor productivity

“The best bang-per-buck risk mitigation strategy we

know is incremental delivery.”

Tom DeMarco and Tim Lister

APM techniques that address schedule risk…

• Team involvement in planning and estimating

• Early feedback on delivery velocity

• Constant pressure to balance the number and depth of features with capacity constraints

• Close interactions between engineering & customer teams

• Early error detection/correction to keep a clear working product

“Requirements evolution is a rational process in which the development and customer teams are constantly evolving the requirements of the product while considering other constraints.”

Requirements evolution is a joint effort where all parties participate in deciding on features.

Requirements creep occurs when there isn’t a joint effort, when customers or developers add features indiscriminately.”

Risk: Specification breakdown

When customers and the product team fail to agree on

specifications.

The product manager, aided by the executive sponsor,

is charged with either stopping specification breakdown

or halting the project until the specification process can

be fixed.

The product manager and team are responsible for

creating a viable specification decision making process.

Planning and Scanning (looking forward)

Frequent re-planning based on progress to date and new

information gathered during development iterations is essential to

deal with the uncertainty risk.

Too great an emphasis on adaptation (we can always fix or

refactor later) means that you do not take advantage of

information that should be known.

Example: Spending a week at the beginning of a project defining

customer req’ts and constructing a skeleton data model may

improve the quality of the plan and speed of development.

Agile teams can place too much emphasis on adaptation or evolution and too little on

anticipation (in planning, architecture, design, requirements definition).

Failure to take advantage of knowable information leads to sloppy planning, reactive

thinking, excessive rework, and delay. Remember: Agility is the art of balancing.”

Scanning

… looking ahead to learn the unknown as quickly as

possible.

• Reduce uncertainty by a systematic, proactive, and early

gathering of information or identifying the information that

needs to be gathered at a future point.

• Managing risks… estimating the probability something will

happen and the negative impact that would result.

• Managing assumptions… continually scanning to determine if

the assumptions still are valid

• Maintaining a key future decisions list… assuring that the

appropriate information needed is available at the future point

in time.

Timeboxed Sizing

For capabilities … during release planning

Constraining size rather than estimating size was much

faster than trying to discuss and agree on the scope.

Early sizing in release planning is inexact regardless of

method used… so

For timeboxed sizing to work… all parties need to

understand the benefits and the limitations of the

approach.

Other story types

“The overriding concept should be that all work should be accounted

for in release and iteration planning.”

Maintenance and enhancements requests (SCRs)… converted to

stories.

Task Cards… circumstances where several days of work cannot be

included in a story card.

Change Cards… the feedback from customers and product managers at

the end of each iteration may result in change requests.

Inter-team Commitment Story Cards… large projects where one team

commits to do work for another team.

Decision milestones… critical point in the project where decisions are

required. see Figure 8-6

Performance cards… key operations and performance req’ts (non-

functional req’s) see Figure 8-7

Work-in-Process versus Throughput

Note: Multitasking (moving from one project to another) adds task switching overhead.

Figures 8-8 and 8-9

DAYS

2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36 38 40 42 44 46 48 50 52

Project1

Project2

Project3

Analysis

Design

Programming

DAYS

2 4 6 8 10 12 14 16 18 20 22 24 26 28 30 32 34 36

Project1

Project2

Project3

Multitasking

Non-multitasking strategy

Assumes zero time for task switching

"More throughput and less work-in-progress"

Emerging Practices

Kanban is a new technique for managing a software development process in a highly efficient way.

Kanban underpins Toyota's "just-in-time" (JIT) production system.

Although producing software is a creative activity and therefore different to mass-producing cars, the underlying mechanism for managing the production line can still be applied.

A software development process can be thought of as a pipeline with feature requests entering one end and improved software emerging from the other end.

Inside the pipeline, there will be some kind of process which could range from an informal ad hoc process to a highly formal phased process. In this article, we'll assume a simple phased process of: (1) analyze the requirements, (2) develop the code, and (3) test it works.

Handout

Consolidated Development

Background Management approach to staffing… and dealing with conflicting priorities among new development, customization, and maintenance work…

• IT organizations tend to divide into new development and maintenance

• Independent software vendors (ISV) put new development, maintenance & enhancement into a single group with customization for particular clients handled by a separate group.

New developments teams seem to get bogged down in maintenance work and key customers want their customizations work done quickly.

Sutherland

Single organization works on all facets of delivery (new functionality, enhancements, SCRs)

Governed by a strategic prioritization system

Allocating work to three simultaneous, overlapping iterations

Consolidated Development (continued)

Sutherland

Weekly iterations target maintenance or minor enhancements

Monthly iterations target specific enhancements

Quarterly iterations target major new functionality

Prioritization is a strategic organizational process – involving the product manager, the CEO and other key executives.

Approach requires:

Agile delivery is a proven approach & management supports the process

Continuous integration and automated testing is ingrained in the process

Effective functioning and integrated product management, development, and QA

Hyper-development and Release

????

FINAL THOUGHTS

Release planning gives the team a game plan that

compensates for the often short iteration focus of agile

projects and gives product marketing a context in which

to make key priority decisions about capabilities and

stories.

Release planning gives management and executives a

baseline against which to determine the feasibility of

delivering a high-quality, releasable product within the

identified constraints.