Agile Project Management

Jim Highsmith

Chapter 7

The Speculate Phase

“Plans are guides, not straightjackets”

Good context…

“Agile teams plan, but they recognize that reality always intrudes.

Plans have to adapt because the customers’ understanding of their requirements changes, because estimates of variety or other reasons.

Plans are both conjectures about the future – our best guess at what will occur given the information we have – and guides to the future – determining what we want to occur and making it happen.

Development generates new information that in turn creates the need to replan.”

Speculating on Product and Project

The “product” of this phase is a release plan based on

capabilities or stories to be delivered rather than

activities.

Two critical components of an iterative planning and

development process:

Short iterative timeboxes and features

Short iterations act to accelerate projects

Short timeframes requires the team to figure out faster ways of

accomplishing all aspects of development… QA activities are

completed every iteration (not at the “end”)

Feature Driven Development (FDD)

First goal: “make the process visible, and understandable, to the customer team.”

… instead of making the technical work understanding to the engineering team.

Customers understand products, components of products, and features of those components.

Features are the interface between development engineers and product teams

Index cards:

Break features down into chunks that can be implemented.

On the front: requirements information for planning purposes

On the back: technical task information enabling the development team to estimate effort and manage its work

Agile project speculation helps the team:

• Determine how the product & its features will evolve in the current release

• Balance anticipation with adaptation as the project unfolds

• Focus on the highest-value features early in the project

• Think about the business goals, project objectives, & customer expectations

• Provide necessary cost and schedule information to management

• Establish priorities for tradeoff decisions

• Coordinate interrelated activities and features across teams

• Consider alternatives and adaptive actions

• Provide a baseline for analyzing events that occur during the project

Through their actions, performance measurements, and vision, agile leaders

constantly need to encourage teams to learn and adapt as projects evolve.

Product Backlog

Its objective: to expand the product vision, through

evolutionary requirements definition process, into a

product feature list… of backlog.

The backlog list is maintained by the product manager

and is the major input for release, wave* and iteration

planning.

* wave (or milestones) plans span several iterations

Feature details… evolve over the development phases

Envision phase

The team creates a preliminary feature or product breakdown

structure, identifying features

Speculate phase

The team expands the list, and for each feature creates one or

more “story” cards that contain basic descriptive and

estimating information.

Explore phase

In the specific iteration in which a story is planned for

implementation, the requirements are determined in detail, and

the story is built and tested

From the list of stories…

The Product team and engineering team need to discuss

prioritization and scheduling issues during the

assignment of stories to iterations within the release

plan.

Note. characteristic of agile projects is the volatility of

stories in the backlog.

Planning for each iteration… the stories to be included in that

iteration can change from the original release plan.

What is a feature, a Story

“A piece of a product that delivers some useful and

valuable functionality to a customer.”

Difference between a story and a feature

A story is a small piece that delivers useful functionality, but may not

deliver a complete function

Stories evolve over time… they don't represent a set of “fixed” req’ts

Example

Feature: As a credit analyst I need the ability to check a customer's credit

rating.

As a credit analyst, I need the ability to:

• Check the prior payment history with this customer

• Check this customer’s credit bureau status

• Calculate our internal credit rating based on history and credit

report.

Figure 7-2 The Focus of Stories

Release Planning

Allocate work to iterations in a release plan

Use stories to involve the product team in the process

Detailed Iteration Planning

Stories are broken down into technical tasks… to be used by the development team

Small stories… sufficient to implement only what is needed for the story

Not having demonstrable customer-understood stories causes project to get off track quickly…

… furthermore, by combining tasks from several stories during an iteration, most perceived inefficiencies can be eliminated

“Some stories will invariably take longer, or appear to take

longer, than one iteration to complete.

Usually when teams are pressed to decompose a “big” story into

bite-sized stories, they figure out a way.

Inability to break things down in this manner is usually an issue

of lack of experience rather than a un decomposable story.”

“Dark holes”

The danger of building technical features before customer

ones

The longer the technical team “stays dark” – building techie

stuff – the further off track the project can get before receiving

feedback from the customer team.

Story Cards

Agreements between customers and team members to discuss detail requirements during an iteration.

“Discussion is critical to understanding, which in turn is critical to estimating.”

Story Card Information (Figure 7-5)

• Story identifier and name

• Story description: sentence or two describing the feature in customer terms

• Story type (C=customer domain, T=technology domain)

• Estimated work effort… needed to deliver the story, including time for req’ts gathering, design, coding, testing & documentation

• Estimated value point (coming in Ch. 8)

• Req’ts uncertainty (erratic, fluctuating, routine, stable): an exploration factor

• Story dependencies: Dependencies that could influence implementation sequencing

• Acceptance tests: criteria the customer team will use to accept or reject the story

Stories… uncertainty and risk factors…

… influence scheduling and the team’s approach to

implementing.

High risk (erratic and fluctuating) stories: scheduled in

early iterations

… to get a handle on whether is can be implemented as

well as whether it will take more time and/or money

… there will be technology areas or features that run the

gamut from low to high risk.

… intent is to improve development effectiveness and

productivity.

Creating a Backlog

“A list of capabilities, features, and stories that the product team has identified.”

In a well-functioning agile team, collaboration among customers, product specialists, and developers supersedes documentation in importance and improves the entire req’ts understanding process.

Approaches to business/product analysis & story definition…(e.g. use cases)

Whatever… three things are essential:

1. Identifying roles or personas that exist in the customer’s environment

2. Identifying functions performed by these personas

3. Breaking that functionality down into implementable chunks – stories.

“… paving cow paths”

… means automating business processes as is, without

thinking too much about whether or not the business

processes are effective or efficient.

A “dangerous” assumption in many agile methods…

Customers have done their homework…

1. They understand tier business processes

2. They have done the necessary business process analysis

and rationalization

3. They understand how automation might change

processes themselves.

Agile teams… ignoring and becoming developer-centric

Miss the opportunity to increase delivery of extra customer

value.

Release Planning

“… the roadmap of how the team intends to achieve the

product vision within the project objectives and constraints

identified in the Project Data Sheet (PDS).”

Most traditional project management plans utilize a list of

tasks to construct work breakdown structures (WBSs) to

organize the work.

Work… concentrate first on deliverables, work- or task-driven

plans… which often degenerate into detailed, prescriptive plans.

The more quickly the link can be made between customers

and features they requested and get feedback… the more

likely the product development effort will be successful.

Release Planning (continued)

Its primary task: assigning stories to iterations, based on value

and risk.

Release planning should be a collaborative team effort – product

team, development team and executives.

The team needs executive input at the beginning of the Release

Planning… and towards the end.

Gold Plating… Standish Group presentation of two case studies…

Federally mandated state child welfare projects …

Florida: begun in 1990, delivery expected 1998, cost of $32

million with staff of 100

“last review”… cost estimated at $170 million, delivery 2005

Minnesota: begun in 1999, delivered in 2000, cost of $1.1

million with staff of 8

Two other studies …

Dupont: estimated that only 25% of the features implemented

were actually needed.

Other: 45% of the features were never used and only 20%

were used often or otherwise.

Simplicity – the art of maximizing the amount of work

not done – is essential (Agile Manifesto)

Agile… focus and balance

“… focusing on the project’s key vision and goals and

forcing hard tradeoff decisions that bring balance to the

product.

… short iterations in agile development, combined with

end-or-iteration customer review, make the entire team

– developers, customers, management – face reality.

Agile practices incorporate change into the development

process. while at the same time reducing project size by

constant and intense concentration on essentials.”

Iteration 0 … helps balance anticipation with adaptation.

Zero implies nothing useful implies that nothing useful

to the customer gets delivered initially.

What gets done in Iteration 0 (prior to launching into

iterative story development)?

Product being integrated with another app may require data

architecture work to define the interfaces

Electronic instrument work might require a preliminary

component architecture

Team using unfamiliar architecture may need training time

… some projects require more “initialization” work that

others.

Iterations 1 – N

Need to create a plan, assigning stories to iterations for the duration of the project…

completion dates, staffing, costs … other planning information

Activities in laying out this plan:

• Determine how identified risks will influence iteration planning

• Identify schedule target (the product manager’s “desired” schedule, without respect to achievability

• Develop a them for each iteration

• Assign story cards to each iteration, balancing value, risks, resources, and dependencies as needed

• Summarize the release plan in some combination of story card layout (Figures 7-6 though 7-8, page 148-9)

• Adjust the completed plan as necessary, using the tradeoff matrix as a guide.

Customer value and risk… drivers

The risk list should be reviewed.

Assessment should be made to assess the impact and how mitigation

might effect the release plan

High value stories might need to be deferred in favor of high risk

stories…

Marketing, management, or a customer might “select” the delivery

date… these expectations are “real”

In many cases a target date becomes a constraint on the project.

At the outset “there are many unknowns”… requiring development and

customer teams and executives to work together to resolve the unknowns…

For example, everyone should be looking at features to reduce in scope (or

cut)

The process of negotiating between target and planned dates works only when all

parties are working collaboratively to achieve a common goal. It does not work in a

situation in which parties are being arbitrary and capricious.

Each iteration should have a “theme”

Essential to ensuring that the team balances breadth and

depth of features.

Helps to focus the team in ways that a list of individual stories

may not.

e.g. “Demonstrate the basic instrument data acquisition capability” and

“Prove that our high-risk valve design is viable”

Techniques to ensure a reliable plan

For each iteration, add time for changes identified during the

previous iteration review… story card titled “Rework and

Contingency”

Set aside one or more iterations at the end of the project…

especially for projects with a high exploration factor

Release Planning is not prescriptive!

Prior to the start of the 1st iteration… and given the

development of the initial prioritized “Backlog” list and

the “expected” delivery date…

Iteration length is specified, expected work per iteration is

specified

… iteration “themes” are specified and the appropriate stories

associated with the each theme are assigned to iterations based

on “value” and “risk”.

The sum of the work associated with each story assigned to an

iteration should be less than or equal to the expected work per

iteration.

First Feasible Deployment

“The first iteration in which the product could

potentially be deployed.”

Customers would understand that the product has only

certain features, but they are willing to work with that

limited functionality.

NOTE. The result at the end of each iteration is “done-done,”

deployable pieces of product… they may or may not be

actually deployed.

Iteration results for Web-based systems might be deployed.

Estimating … is a guess!

The “subtleties:

• Estimating the unknown

• Estimating by stories rather than tasks

• Estimating progressively

• Estimating can be a huge time waster

• Estimating versus sizing

• Using “story points” versus staff hours

Story point (relative size) estimating is preferred… but

staff hours are also used

Team member estimates should be used for iteration plans

• Important for team development and cohesion… team

member should be responsible and accountable for

iteration plans!

• As the project progresses, team members should get

better at estimating for the next iteration…

“learning from doing… ”

Chapter 8

Final thoughts…

Three key activities needed before “story development”

1. Articulating a product vision

2. Defining the project’s objectives and constraints

3. Creating an iterative, story-based release plan

The “release plan” is constructed from the feature/story “Backlog”…

… that evolves during the Envision and subsequent Speculate phases.

“When you get the backlog and release plan done, the rest is relatively easy!”