Tag Archives: planning

Using Actuals with Estimates

I work with a group that’s been estimating in pair hours for a while. We’ll describe a story, everybody will write their estimate on a card, somebody collects the estimates, and we make an overall estimate. (The tricky part is that an estimate needs to include the tasks that aren’t yet known but that will be discovered.)

We also track actuals. Whenever it’s convenient, but definitely at the end of each day, the pair adds its tick marks onto the board.

We’ve used a couple approaches to coming up with "the" estimate. One was to have the longest-standing team member propose a consensus number => not consistently right. Then we tried taking the maximum estimate => usually too high.

Now, we’re keeping track of who made what estimate. We compare estimates to actuals and decide who was the "winner" – the one with the most accurate estimates that week. When it’s time to do new estimates, we let that person hear all the estimates, and they make the overall estimate we record.

It’s too early to say how well this works. The same winner showed up twice in the first month, which may be an early indicator.

My estimates? I’m almost always too optimistic. So I’m going to pay more attention to how the winner thinks about our tasks.

Agile Project Management, XP Style


How do you plan the overall shape of a project in XP? This article summarizes planning with little reference to the programming aspects of XP.



  • Team: the customers, programmers, and managers who are jointly working on the system.
  • Customer: the person or group defining the need for the system and what it does.
  • Programmer: the person or group that estimates and implements the system.


  • Exploration: part of the release cycle: when customers create stories, and programmers estimate them.
  • Iteration: part of the release cycle: a fixed-length time for implementation of stories. An iteration is time-boxed: if all stories can't be completed, stories are dropped rather than the iteration extended.
  • Release: delivery of system (usually to end users).


  • Story: a feature or capability of the system that a customer values.
  • Estimate: the cost (usually time) to implement a story. There have historically been two ways of doing estimates in XP: relative (a story is estimated as costing 1 to 3 "story points"), or absolute (so many hours for a pair).
  • Release Plan: a flexible, overall plan that tells which stories are expected in which iteration, for a whole release.
  • Iteration Plan: a small plan that tells which features are expected in the current iteration.

Capsule Summary

In XP, planning at implementation can take place at any time, but an XP project usually has different emphases at different times.

Exploration: The team learns about the problem and the technology options for a solution. The programmers estimate the cost of each story. Exploration typically lasts one to four weeks. Result: All important stories are understood (reasonably well) and estimated (in story points).

Release Planning: The programmers tell how many story points per iteration they expect to deliver. The customer plans which stories will be in the release, and in approximately what order they should be implemented. Result: A release plan.

Iterations: The team implements another group of stories, whichever ones the customer thinks are the most important at that time (and whose cost lets them fit into the iteration).  Iterations have a standard size, typically one to three weeks. Result: Working system that the customer can test.

Release: The team readies the system for release to a broader group. Releases are typically one to three months apart. Result: System delivered to end users.


From even the small description above, we can see several implications:

  • All the cycles are very short. The whole release cycle occurs in weeks to months.
  • The release plan is created approximately a quarter of the way through the release cycle.
  • The plan can be revised (by the customer!) at any time. At the start of each iteration, the customer decides which stories are most important at that time.
  • This flexibility places a burden on the programmers: they must be prepared to implement any feature next. XP uses specific programming techniques to make this possible in the software realm, and teams can use conditional estimates for special cases ("3 for the first one and 1 for each one after that").

The Estimates

The programmers work with the customers to make sure both parties agree on the meaning of a story. Then, the programmers give an estimate representing how much effort they believe is involved to deliver that feature.

Some teams use relative estimates. A common style is 1 to 3 points; anything bigger than 3, the customer is asked to split the story into smaller stories.) The programmers typically think of a 1 as being, "If this were all I was doing, I could do it in 1 week."

Why the relative estimates instead of absolute estimates (e.g., 12 days)? Because people tend to better at relative sizes ("this is about the same work as that"), and they tend to be better at thinking in terms of working time than in estimating their overhead.

Other teams use absolute estimates. (This is the approach Kent Beck is currently recommending.) This is typically done in pair-hours (the cost for two people working together for one hour). 

What if we later find out an estimate is wrong? The team can update their estimates at any time as they learn more. (And yes – if things suddenly get expensive or cheap, it can have a big impact on the release, and the customer may re-assess the overall plan.)

The Release Plan

Once every story has an estimate, the programmers declare how much much capacity they think they will average per iteration ("the velocity"). (A reasonable, conservative guess is "1/4 pair-hour per programmer per week.")

The customer creates the release plan as a list of features in priority order, grouped into iterations according to the estimate and the velocity. The customer can split any story that doesn't quite fit (and have the programmers estimate the new stories).

For example, assuming a declared velocity of 40 hours per iteration and a team planning to do 3 iterations:

Iteration Stories
Iteration 1 Text screen – 10 hours
Simple query – 30 hours
Iteration 2 Boolean query – 20 hours
Simple screen – 20 hours
Iteration 3 Printing – 30 hours
Distribution – 10 hours

The customer can decide whether the goal for the release is a certain list of features or a certain release date. (Iterations have a fixed duration, but the overall release may or may not be time-boxed.) This plan can (and often should) after each iteration, as the team learns more.

The First Iteration

XP suggests a special goal for the first iteration: it needs to provide a minimal, end-to-end solution involving every major component. (Many components will be present in only skeletal form.)

In the example above, the team might split "Simple query" and "Printing," and find a way to fit super-simple versions of each into the first iteration.

The first iteration provides a skeleton for the rest of the implementation, and it helps address high risks in the project. The team is free to completely change the structure around later, but the first iteration provides a starting point.

Other Iterations

Use however many story points the team finished in the last iteration as the estimate for how many points will be done in the next iteration. (This is called the "Yesterday's Weather" rule: the best predictor for today's weather was yesterday's weather.)

For example:

  Expected Velocity Actual Velocity Accumulated
Projected in
3 Iterations
Iteration 1  40 20 20 60
Iteration 2  20 40 60 100
Iteration 3  40 40 100 100

The velocity may bounce around some at first, but it usually stabilizes.

Notice that in the release plan we originally expected to get 120 points in 3 iterations, but we only completed 100 points worth. And at the end of the first iteration, it looked even bleaker. This is a place where the customer's involvement is crucial: the customer can split or simplify stories, move the end date, ask for more people, cancel the project, or do whatever they need to do given the status of the project.

How does a team increase its velocity? If a team feels they're on track to finish early, they'll ask for more work in the middle of the iteration.

Iteration Planning

Going a level deeper, XP uses a similar process for deciding what to do in an iteration.

  1. The customer selects stories for the iteration. (This is subject to "Yesterday's Weather" – scheduling only as many hours as were completed in the previous iteration.)
  2. The team discusses each selected story, and brainstorms tasks that would implement them.
  3. Team members accept and estimate tasks.
  4. The team adjusts and balances the tasks to make sure they fit into the iteration.

The tasks for an iteration are in the development team's purview. It's typical for the customer to be present during this planning, as there will often be questions. These are the two most common approaches to task estimation:

  • No estimates on tasks: the team eyeballs the tasks to make sure none look too large (e.g., not bigger than half a day's work)
  • Hour-based absolute estimates: the number of pair-hours a task is expected to take. Some teams try to estimate individual programmers' velocities; more common is to use an estimate for the team as a whole.

The iteration planning is usually done the first morning of an iteration.

The iteration plan will often change during an iteration as a team learns about tasks they missed, or come up with a better or different way to do things.

What's Interesting About XP's Planning Processes?

  • Extremely short cycles.
  • Use of conversations and tests about stories rather than documents.
  • Use of estimates, velocity, and fixed-length iterations.
  • "Yesterday's Weather" rule adjusting estimates every couple weeks.
  • First iteration as a backbone for the implementation and a driver of risk identification.
  • Commitment to flexibility, e.g., minimizing dependencies so stories can be implemented in arbitrary order.


[Written Nov. 5, 2001. Updated Feb. 27, 2002 due to feedback from Kurt Keutzer and Ivan Tomek. Minor revisions May 27, 2006.]

Review – Agile Estimating and Planning

Agile Estimating and Planning, Mike Cohn. Pearson Education, 2006.
My back-cover review was “Mike Cohn explains his approach to Agile planning, and shows how ‘critical chain’ thinking can be used to effectively buffer both schedule and features. As with User Stories Applied, this book is easy to read and grounded in real-world experience.” Let me add that he also discusses estimation, prioritization, some financial analysis, and monitoring. (Reviewed Jan., 2006)

Twenty Ways to Split Stories

The ability to split stories is an important skill for customers and developers on XP teams. This note suggests a number of dimensions along which you might divide your stories. (Added July, 2009: summary sheet (PDF), French translation (PDF).)

Splitting stories lets us separate the parts that are of high value from those of low value, so we can spend our time on the valuable parts of a feature. (Occasionally, we have to go the other way as well, combining stories so they become big enough to be interesting.) There's usually a lot of value in getting a minimal, end-to-end solution present, then filling in the rest of the solution. These "splits" are intended to help you do that.

The Big Picture

Easier Harder Why
Research Action It's easier to research how to do something than to do it (where the latter has to include whatever research is needed to get the job done). So, if a story is too hard, one split is to spend some time researching solutions to it.
Spike Implementation Developers may not have a good feeling for how to do something, or for the key dimensions on which you might split a story. You can buy learning for the price of a spike (a focused, hands-on experiment on some aspect of the system). A spike might last an hour, or a day, rarely longer. 
Manual Automated If there's a manual process in place, it's easier to just use that. (It may not be better but it's less automation work.) For example, a sales system required a credit check. The initial implementation funneled such requests to a group that did the work manually. This let the system be released earlier; the automated credit check system was developed later. And it was not really throw-away work either – there was always going to be a manual process for borderline scores.
Buy Build Sometimes, what you want already exists, and you can just buy it. For example, you might find a custom widget that costs a few hundred dollars. It might cost you many times that to develop yourself.
Build Buy Other times, the "off-the-shelf" solution is a poor match for your reality, and the time you spent customizing it might have been better spent developing your own solution.

User Experience

Easier Harder Why
Batch Online A batch system doesn't have to interact directly with the user.
Single-User Multi-User You don't face issues of "what happens when two users try to do the same thing at the same time." You also may not have to worry about user accounts and keeping track of the users.
API only User Interface It's easier to not have a user interface at all. For example, if you're testing your ability to connect to another system, the first cut might settle for a unit test calling the connection objects.
Character UI or Script UI GUI A simple interface can suffice to prove out critical areas.
Generic UI Custom UI At one level, you can use basic widgets before you get fancy with their styles. To go even further, something like Naked Objects infers a default user interface from a set of objects.


Easier Harder Why
Static Dynamic It's easier to calculate something once than ensure it has the correct value every time its antecedents change. Sometimes, you can use a halfway approach: periodically check for a needed update, but don't do it until the user requests it.
Ignore errors Handle errors While it's less work to ignore errors, that doesn't mean you should swallow exceptions. Rather, the recovery code can be minimized.
Transient Persistent Let's you get the objects right without the worries about changing the mapping of persisted data.
Low fidelity High fidelity You can break some features down by quality of result. E.g., a digital camera could start as a 1-pixel black-and-white camera, then improve along several axes: 9 pixels, 256 pixels, 10,000 pixels; 3-bit color, 12-bit color, 24-bit color; 75% color accuracy, 90% color accuracy, 95% color accuracy." (William Pietri)
Unreliable Reliable "Perfect uptime is very expensive. Approach it incrementally, measuring as you go." (William Pietri)
Small scale Large scale "A system that works for a few people for moderate data sets is a given. After that, each step is a new story. Don't forget the load tests!" (William Pietri)
Less "ilities," e.g., slower More "ilities" It's easier to defer non-functional requirements. (A common strategy is to set up spikes as side projects to prove out architectural strategies.)


Easier Harder Why
Few features Many features Fewer is easier.
Main flow Alternate flows (Use case terminology.) The main flow – the basic happy path – is usually the one with the most value. (If you can't complete the most trivial transaction, who cares that you have great recovery if step 3 goes bad?)
0 1 Hardware architects have a "0, 1, infinity" rule – these are the easiest three values to handle. Special cases bring in issues of resource management.
1 Many It's usually easiest to get one right and then move to a collection.
Split condition Full condition Treat "and," "or," and "then" and other connector words as opportunities to split. Simplify a condition, or do only one part of a multi-step sequence.
One level All levels One level is the base case for a multi-level problem.
Base case General case In general, you have to do a base case first (to have any assurance that recursive solutions will terminate).


These "splits" may help give you ideas when you're looking for a way to move forward in small steps. While it's important to be able to split stories, don't forget that you have to reassemble them to get the full functionality. But you'll usually find that there is a narrow but high-value path through your system.

[Developed for XP Day speech, Sept., 2005. January 6, 2006: Thanks to William Pietri for sharing his suggestions on the fidelity, reliability, and scale dimensions. Fixed typo, 7-19-06. Added "connectors", 1-8-11.]

Overview of “Extreme Programming Explained, 2/e”

Kent Beck has released a new edition of Extreme Programming Explained. This note discusses some highlights and compares it to the first edition.

Quick Summary

The second edition of Extreme Programming Explained is out.  This note is just a quick summary (read the original!), with some comments of mine in italics.

There’s an added value, Respect. There are more practices, organized as primary and corollary practices. Primary practices can stand alone; corollary practices need the support of other practices. These work together to make adopting XP be able to be more incremental than "try all these together." This book suggests a simpler approach to planning. Finally, there’s good material on the philosophy and background of XP.

Even if you’re familiar with the first edition, this book gives you a better picture of what XP means.


What is XP?

  • a mechanism for social change
  • a style of development
  • a path to improvement
  • an attempt to reconcile humanity and productivity
  • a software development discipline

These point to more ambitious goals than "a dozen developers in a room" that the first edition mostly claimed.

What are its values?

  • Communication
  • Simplicity
  • Feedback
  • Courage
  • Respect

"Respect" is listed as a new value.

What are its principles?

  • Humanity: balancing individual and team needs
  • Economics: built on the time value of money and the option value of systems and teams
  • Mutual benefit: "the most important XP principle and the most difficult to adhere to"
  • Self-similarity: make the small echo the large (and vice versa)
  • Improvement
  • Diversity
  • Reflection
  • Flow: from lean manufacturing, not from psychology – deliver a steady flow of value by engaging in all development activities simultaneously
  • Opportunity: see problems as opportunities
  • Redundancy
  • Failure: "If you’re having trouble succeeding, fail."
  • Quality
  • Baby steps
  • Accepted responsibility


There are still practices in XP (more than ever). Now, they’re divided into primary practices and corollary practices. Primary practices are ones that are generally safe to introduce one at a time, or in any order. Corollary practices are riskier: they require the support of other practices.

The approach to introducing practices is a lot more gentle-sounding: there’s the idea that you can change yourself, not impose practices on others. Beck advises not changing too fast. This all sounds more gentle than "do all 12 practices" that came through from the first edition.

Primary Practices

These are generally similar to many earlier practices, turning up the knobs a little.

Sit Together: but "tearing down the cubicle walls before the team is ready is counter-productive"

Whole Team: a cross-functional team.

Informative Workspace: a workspace that meets human needs, and a place for big visible charts.

Energized Work: a reinterpretation of "40-hour week" and "sustainable pace"

Pair Programming

Stories: "units of customer-visible functionality." And, "Every attempt I’ve seen to computerize stories has failed to provide a fraction of the value of having real cards on a real wall."

Weekly Cycle: an iteration: plan, write tests & code.

Quarterly Cycle: plan a quarter using themes.

Slack: include things that can be dropped if you get behind.

Ten-Minute Build: automatically build and test everything.

Continuous Integration

Test-First Programming

Incremental Design

Corollary Practices

Real Customer Involvement

Incremental Deployment

Team Continuity

Shrinking Teams: a proposal to reduce teams by making one person as idle as possible, rather than easing the load on everybody. Another element derived from lean thinking.

Root Cause Analysis: the five whys.

Shared Code

Code and Tests: as the primary permanent artifacts.

Single Code Base: one code stream. "Don’t make more versions of your source code… fix the underlying problem."

Daily Deployment

Negotiated Scope Contract

Pay-per-use: "money is the ultimate feedback"

First Edition Practices

For comparison:

The Planning Game: Quarterly Cycle and Weekly Cycle address this. The planning approach in 2/e is simpler.

Small Releases: Incremental Deployment and Daily Deployment carry this much further.

Metaphor: this was always the least well understood practice, and discussion of it has been more or less eliminated from this edition.

Simple Design: Incremental Design and to some extent Single Code Base.

Testing: Test-First Programming

Refactoring: Not called out; I think of it as part of Incremental Design.

Pair Programming

Collective Ownership: Now called Shared Code.

Continuous Integration

40-Hour Week: Energized Work, and to some extent Slack, cover this.

On-Site Customer: Sit Together, Whole Team, and Real Customer Involvement cover this area.

Coding Standards: Not called out explicitly; probably more of a consequence of Shared Code and Pair Programming.

As you can see, some are the same, some have a name change, and some (notably metaphor and the more programming-oriented practices of refactoring and coding standards) are not discussed.



There’s a strategy for all levels of planning:

  • List the items
  • Estimate
  • Set a budget
  • Agree on the work to be done (without changing estimates or budgets)

Planning should involve the whole team.

Beck now suggests estimating in real pair hours (two people working together for an hour). This is a shift from the relative estimates used before.


Testing is built around two principles:

  • Double Checking (e.g., test and code)
  • Defect Cost Increase (making it cheaper to fix it now)

The argument in 1/e about a flat cost of change curve is gone. Instead, the Defect Cost Increase is leveraged to identify testing as important.

Automated customer and programmer tests are important. Use test-first, at both levels.


Design is incremental: "design always." "Once and only once" is still important. Kent suggests these guidelines for simplicity:

  1. Appropriate for the intended audience
  2. Communicative
  3. Factored
  4. Minimal

He has a nice chart comparing design based on instinct, versus thought, versus experience. Sometimes an instinctual design may be good enough, other times, the thought design is good enough, other times experience is required.

"Designing software is not done for its own sake in XP. Design is in service of a trust relationship between technical and business people."

"The price of this strategy is that it requires the discipline to continue investing in design throughout the life of the project and to make larger changes in small steps, so as to maintain the flow of valuable new functionality."


There are different types of scaling.

To scale according the number of people:

  1. Turn the problem into smaller problems
  2. Apply simple solutions
  3. Apply complex solutions if any problem is left.

Uses the "conquer and divide" strategy. "Chip away at complexity while continuing to deliver."

Safety- and security-critical software may require some modest changes.



After Winslow Taylor. The consequences are bad, resulting from separation of planning from execution, and having a separate quality department.

Toyota Production System

"Every worker is responsible for the whole production line."

Ongoing improvement comes from elimination of waste – kaizen.

"If you use a part immediately, you get the value of the part itself as well as information about whether the upstream machine is working correctly." […] "The greatest waste is the waste of overproduction. Software development is full of the waste of overproduction."

Applying XP

(Note: not "adopting" XP.)

There are many ways to start.

Change yourself first, then offer the fruit of that to others. "Continuous" learning is not really continuous.

Two types of groups find it easiest to start XP: those aligned with its values, and those in pain.


There’s not a binary answer to "Am I doing XP? "The goal is successful and satisfying relationships and projects, not membership in the XP club."


Think "multi-site," not "offshore."

"Jobs aren’t going in search of low salaries. Jobs are going in search of integrity and accountability."

"Without dramatic improvement, though, the global market for software will stagnate as more attractive investments are found in manufacturing and biotechnology." Kent’s been quoted as saying "All methodology is based on fear." I think this sentence captures one of the fears XP is intended to address.

The Timeless Way of Programming

"Harmony and balance are the aims of XP."

Community and XP

"A supportive community is a great asset in software development."


The first edition was a manifesto to programmers. The new edition has a broader audience.

The practices are more extreme, the rhetoric less so. The mechanics of programming XP-style are a little less explicit (but there are certainly plenty of books out there on test-driven development, refactoring, and so on.) The philosophy shines through more clearly.

The result is a worthy follow-on.

Extreme Programming Explained, by Kent Beck and Cynthia Andres. Addison-Wesley Professional, 2004. ISBN 0321278658.

[Written January, 2005.]

Customer Value – Unbundling

Working story by story lets you create value in independent pieces. You can bundle or unbundle these to meet your needs.


A traditional view of development is that we accumulate a number of requirements, then analyze, design, etc. until we have a system.

The word "requirement" creates an illusion – that just because someone said something, it is required. I’ve heard people speak of "desirements," and that’s closer to the truth.

A set of requirements usually has parts that are more valuable, and parts that are less valuable. It also has parts that are cheaper to implement, and those that are more expensive to implement. We need to put those two bits of data together to decide what to do.

I once worked with a system analyst for a corporate IT group who was unable to see value in having pieces. She would develop a set of requirements, but could not prioritize them: "they’re all equally important." The reality was, the requirements were a mix:

  • regulatory requirements (implement by Jan. 1 or face substantial fines or shuttering of the business),
  • new features to enable new business
  • enhancements to existing features (make this dialog require two less clicks to get through), and
  • minor changes (fix spelling).

These have very different characteristics: some support existing business, some support new business. Some have important deadlines, others don’t.

What’s the impact of an inability to prioritize? What happens if we insist on getting all these at once? The direct impact is an increase in risk: we risk shuttering the business for a spelling change. That’s hardly what the real customer wants. There are indirect impacts as well:  people get confused about what’s really important; they act like they have plenty of time and resources (whether or not that’s true); they often don’t seek creative solutions.

The Pareto Principle often applies: 80% of the value comes from 20% of the work. If we can find a creative solution for that 20%, we can come out way ahead.


The previous section suggested that there is value in splitting things apart. But clearly there’s value in having things together too: I buy a newspaper with many sections, and I don’t buy my car in a kit.

Bundling lets us take advantage of differences in customer preferences. Let’s take the newspaper for an example. Suppose the following table shows how much (in cents) people value each section.

Who News Sports Comics
Abe 15 10 5
Bob 5 15 10
Charlie 10 5 15

If we sell the sections separately, the most we’d sell for is 15 cents, and the least is 5 cents:

Per Section

Total income
Price Sales Income
5 3 15 45
10 2 20 60
15 1 15 45

If we were selling sections one at a time (each for the same price), we’d sell them for 10 cents, and take our maximum profit of 60 cents. But we know we’re leaving money on the table: one customer would be willing to spend more, another less. But customers won’t tell us what their real price is.

Bundling represents a way to capture this "excess": suppose we sell each paper with all three sections for 30 cents. Each customer is willing to pay that, so now we’ll get 3 * 30 = 90 cents total income for these three readers. That beats 60 cents by quite a bit!

Another value in bundling is value that customers place on our integration work. As newspaper readers, we may be glad to have somebody else who goes out and selects the right mix of pieces for us. This can be a value of the brand: we trust that we’ll get a consistent level of quality from the integrator. For newspapers, it’s convenient to get a bundle in the morning, right on the doorstep (or at least at the foot of the driveway).

Bundling may have other virtues, but let’s go back to the unbundling side.


Bundling can be nice for the supplier we described above, but there are lots of suppliers. What happens when we put them together in a market?

Consider a shirt. You can buy it in a nice boutique, with helpful clerks, carpeted floors, a live pianist, and so on. This bundle is combining your shirt with other aspects that make it an experience. Or, you can  buy your shirt at a "big-box" retailer, where you have to wander around a giant store crowded with screaming kids, select your shirt out of huge pile, and then stand in a long checkout line.

Some people want a shirt plus an experience, others just want a shirt. If the boutique were all that existed, the seller could charge everybody the premium. But when the discounter comes into the picture, the people who value just the shirt are pulled away. Worse still for the boutique, the ones who want a shirt but value the experience somewhat, are also pulled away. This puts the boutique in a dilemma – they can’t compete on price without reducing the experience, and if they raise the price to support an improved experience, other customers will leave.

As suppliers, it’s to our advantage to bundle, but competitors have an incentive to use the unbundled parts to compete.


So should we bundle or not?

The trick is that the value propositions aren’t symmetric:

  • a bundle is valuable to a consumer because it is convenient and the average price of the parts is "good enough."
  • a bundle is valuable to a producer because it captures more of a customer’s money.
  • unbundling is valuable to a consumer because it lets them pay the minimum price for each part.
  • unbundling is valuable to a producer because it lets them pick off the customers who most value a part.

As a producer, we try to balance these challenges like this:

  • retain the ability to unbundle by not unnecessarily combining things
  • retain the ability to bundle by combining parts into attractive offerings

In software, we have seen creative ways to make this modularization possible:

  • frameworks
  • components and glue code
  • plug-in architectures
  • keys that activate extra features in applications
  • level and part editors in games, to enable users to create their own variations

These approaches all help a producer maintain the valuable parts, and provide the flexibility to bundle or unbundle them as the market supports.

[Written December, 2004.]

Review – Agile Project Management with Scrum

Agile Project Management with Scrum, Ken Schwaber. Microsoft Press, 2004.
This book presents stories from several software teams adopting Scrum. It takes stories from several perspectives such as “The Product Owner” or “Scaling Projects using Scrum.” What I like best is that he describes the situation, and then tells you how the team addressed it, so you can practice your own thinking about how you’d improve projects. (Reviewed Nov., 2004)

Customer Value: Short-Term and Long-Term

Consider both short-term and long-term value when selecting stories to implement.

Finding Value

XP books often say to choose stories by value to the customer, but don't always say much about how to find that value. ("Customer" in XP represents the role that selects and prioritizes stories; others call this the product manager or product owner.)

One breakdown I find useful is to think about short-term and long-term value. For each combination, there may be several types of value; some are described below.


Total Value

Negative Positive
Current Value Low Malicious Compliance
Demonstrate Capability
Teambuilding / Quick Win
Information / Infeasibility
High Ego
Wrong Guess

Low Current Value, Negative Total Value

This quadrant represents the worst case.

Malicious Compliance

The team and the customer both know the feature isn't wanted (or may actually hurt the system), but they develop it anyway to hurt the money folks. Or, the development team knows the feature isn't valuable, but doesn't warn or attempt to convince the customer of that. (People are allowed to be wrong, but we want them to give their best judgment.)

High Current Value, Negative Total Value

This quadrant represents things that benefit the short-term only. In both these cases, sometimes the development team will "know" the feature has low total value. They certainly should make their case to the customer. But one of the reasons there's a customer involved is because the customer can recognize value in some things developers would not.


Some features are chosen because the customer wants to make a mark, not because they're truly expected to be valuable when considered in the long run. Often times, the customer may get warning about this. (Unfortunately, extraordinary features may also draw the same warnings.) This is a place where the vision comes into play – is this feature consistent with that vision?

Wrong Guess

Some features are expected to be worth more, but the guess turns out wrong. That's going to happen sometimes. But it's still worth looking for warning signs that a feature isn't going to be as useful as expected.

Low Current Value, Positive Total Value

This quadrant represents features that are an investment.

Demonstrate Capability

Sometimes a team is put to a test: develop this feature, so we can see whether to trust you with more, and to assess the team's capability and/or commitment. A pilot project has this flavor; a pilot is often not trivial (because then it wouldn't prove anything) and not huge (because then there's too much risk).

Teambuilding / Quick Win

This applies particularly for a new team or one that's not been successful in a while. A feature may not be particularly valuable, but it can provide something the team can gel around. Often, this feature can be something that is visible and that everybody can understand. For a particular team, it may be a good choice, even though a gelled team might start with a different story.

Information / Feasibility

A feature may be developed for the information it provides, to enable a better course of action later. Sometimes, that information may establish that something is not viable or not important. That can be very valuable information; it helps us adjust to reality and move on to something more valuable.

There are a couple interesting twists: sometimes the information that some aspect of a project is non-viable is significant enough to cause a project to be canceled or to change its goals significantly. By getting this important information early, a project can save huge amounts of money. (After all, if it's non-viable, you'll certainly find this out by the end, regardless of how much you've spent to get there.) Think like a venture capitalist – you may have a portfolio of things; some will fail, some will be strong performers, a few will be huge hits.

Sometimes, you do a feature to convince someone else that it's not feasible or not as useful as expected. The XP-style "spike" does an experiment to find out whether something will work. It's often much better to do a quick experiment than waste hours or days arguing about it.

Option Value

A feature may not be valuable itself, but investing now gives us the ability to deliver other valuable features later (especially if that's cheaper, faster, etc.) This sometimes provides a push for breadth in a project – rather than focus on one specific area, paint the whole product lightly first. Totally different areas may reveal different challenges, and will help you move in any direction later.

Some infrastructure stories fit this category. A feature may be needed to enable other features to build on it. In XP, the team tries to minimize features like this, preferring to build infrastructure a little at a time. (One reason is that the customer is not always in a position to judge the value of pure infrastructure.)

High Current Value, Positive Total Value

This quadrant represents the obvious winners: features that you know you should do.

Direct Value

Features with direct value are the bread-and-butter features: those that will result in making or saving money in their use, those that are obviously useful, those that provide a straightforward new capability.


Some features are even more valuable in combination with other features. For example, print preview is of some use by itself, but even more use when combined with the ability to print.


Domination is a special type of synergy: it helps a product establish itself as dominating an area. For example, "we have the most comprehensive style sheets on the market," "we have the best performance," etc. It can play to the bandwagon effect, making a product desirable because other people want it.


Some features are valued because they lock the end-user in to a product. For example, a proprietary file format may prevent others from reading your information. Note that this can back-fire too – this is something a company values more than end users do. Lock-in may slow down movement of customers who want to leave, but it also keeps people away in the first place.


Features with direct value are the easiest to choose, but not always the best. Be aware of opportunities that may seem low in value now, but can be extra valuable later. And guard against features that will never become valuable.

[Written October, 2004. Thanks to Christian Pekeler for catching a couple minor errors.]

ISO Certification for XP at LogicaCMG

Paul Grew (Paul.Grew@logicacmg.com) of LogicaCMG shares his XP team's experience with getting ISO 9000 certification.

"LogicaCMG Mobile Payments have been using XP to create new products for the telecoms market since the last quarter of 2003. They adopted all the practices described in Kent Beck's book and were mentored by Exoftware for 9 months. They have been though an ISO TickiT recertification audit and came out favourably with the auditor being complimentary about our process. It was felt that the process should be as simple as possible from the point of view that: if it is said that a process is followed then the development team must have evidence to prove it."

[Paul provided this diagram:]

Life cycle

[Written June, 2004, by Paul Grew.]

Review – User Stories Applied

User Stories Applied, Mike Cohn. Addison-Wesley, 2004.
This book is all about user stories, focused on the XP-style customer or the Scrum-style product owner (although programmers and others should know this material as well). Mike describes what stories are, how to generate them, and how to estimate and plan with them. He contrasts them to use cases and IEEE-830 “The system shall” requirements, and includes a catalog of “story smells.” The book closes with an example of a system described with 30+ stories, and its tests.

A customer needs to know more than stories (including how to manage up-front analysis that might financially justify a product or feature,  linkages to outside groups, innovation, and more.) But those aren’t this book’s topic: this book sets out to provide a clear, very well-written, and concise guide to using stories with a software team. It does a great job: I’m seeding copies with several people! (Reviewed June, ’04)

Review – Radical Project Management

Radical Project Management, by Rob Thomsett. Prentice Hall, 2002.
I don’t know why the title says “Radical”, as throughout the book it’s “eXtreme Project Management.” Thomsett develops a project management approach that considers value throughout the project’s whole life cycle. He works through a lot of issues around stakeholders, risks, and estimation. He has a nice “slider” tool that lets stakeholders say what’s important to them. I don’t think this is the most agile project management approach imaginable, but I could see it helping teams work interface with large projects and more traditional project management. (Reviewed Feb., ’04)

Fisheye Lens Project Management

A traditional project plan has an ethos, "Plan the work, work the plan." The planning process will work out all the expected tasks, estimate them all, and assign workers to the tasks. This has several problems: the sheer mass of data makes it hard to see what’s really important, the plan is vulnerable to changes in direction, and it’s hard to keep up to date.

XP and Scrum (and some but not all other agile methods) take a different approach: the set of features currently under development is tracked at a high level of detail (with an iteration plan or sprint backlog), the set of features planned for the next release are tracked at less detail (release plan or product backlog), and features further out are tracked at even less detail.

There’s a type of lens known as a fisheye lens. (You can see a sample picture at here). This lens gets a 180-degree field of view, so it shows a much wider area than a typical lens. But it does it in a way that appears distorted: things in the center appear mostly normal, but as you get closer to the edge, it looks more distorted.

I see the agile methods described above as acting like that: lots of detail in the center (the now), and less detail in the periphery (the future), but still enough detail to let you make sense of the big picture. When you consider that agile methods focus on high business value first (slicing by feature rather than by technology), they truly focus on what’s important.

(For more on XP, see www.xp123.com, www.xprogramming.org, or www.extremeprogramming.org; for information on Scrum, see www.controlchaos.com.)