Agile Project Management Jim Highsmith Chapter 7 The Speculate Phase
Welcome message from author
This document is posted to help you gain knowledge. Please leave a comment to let me know what you think about it! Share it to your friends and learn new things together.
Transcript
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!”
Related Documents
