Tag Archives: XPlorations

Estimable Stories in the INVEST Model

Estimable stories can be estimated: some judgment made about their size, cost, or time to deliver. (We might wish for the term estimatable, but it’s not in my dictionary, and I’m not fond enough of estimating to coin it.)

To be estimable, stories have to be understood well enough, and be stable enough, that we can put useful bounds on our guesses.

A note of caution: Estimability is the most-abused aspect of INVEST (that is, the most energy spent for the least value). If I could re-pick, we’d have “E = External”; see the discussion under “V for Valuable”.

Why We Like Estimates

Why do we want estimates? Usually it’s for planning, to give us an idea of the cost and/or time to do some work. Estimates help us make decisions about cost versus value.

When my car gets worked on, I want to know if it’s going to cost me $15 or $10K, because I’ll act differently depending on the cost. I might use these guidelines:

  • < $50: just do it
  • $50-$300: get the work done but whine to my friends later
  • $300-$5000: get another opinion; explore options; defer if possible
  • $5000+: go car shopping

Life often demands some level of estimation, but don’t ignore delivery or value to focus too much on cost alone.

We’ll go through facts and factors affecting estimates; at the end I’ll argue for as light an estimation approach as possible.

Face Reality: An Estimate is a Guess

If a story were already completed, the cost, time taken, etc. would be (could be?) known quantities.

We’d really like to know those values in advance, to help us in planning, staffing, etc.

Since we can’t know, we mix analysis and intuition to create a guess, which could be a single number, a range, or a probability distribution. (It doesn’t matter whether it’s points or days, Fibonacci or t-shirt sizes, etc.)

When we decide how accurate our estimates must be, we’re making an economic tradeoff since it costs more to create estimates with tighter error bounds.

How Are Estimates Made?

There are several approaches, often used in combination:

  • Expert Opinion AKA Gut Feel AKA SWAG: Ask someone to make a judgment, taking into account everything they know and believe. Every estimation method boils down to this at some point.
  • Analogy: Estimate based on something with similar characteristics. (“Last time, a new report took 2 days; this one has similar complexity, so let’s say 2 days.”)
  • Decomposition AKA Divide and Conquer AKA Disaggregation: Break the item into smaller parts, and estimate the cost of each part — plus the oft-forgotten cost of re-combining the parts.
  • Formula: Apply a formula to some attributes of the problem, solution, or situation. (Examples: Function Points, COCOMO.)
    • formulas’ parameters require tuning based on historical data (which may not exist)
    • formulas require judgment about which formulas apply
    • formulas tend to presume the problem or solution is well-enough understood to assess the concrete parts
  • Work Sample: Implement a subset of the system, and base estimates on that experience. Iterative and incremental approaches provide this ongoing opportunity.
  • Buffer AKA Fudge Factor: Multiply (and/or add to) an estimate to account for unknowns, excessive optimism, forgotten work, overheads, or intangible factors. For example: “Add 20%”, “Multiply by 3″, or “Add 2 extra months at the end”.

Why Is It Hard to Estimate?

Stories are difficult to estimate because of the unknowns. After all, the whole process is an attempt to derive a “known” (cost, time, …) from something unknowable (“exactly what will the future bring?”).

Software development has so many unknowns:

  • The Domain: When we don’t know the domain, it’s easier to have misunderstandings with our customer, and it can be harder to have deep insights into better solutions.
  • Level of Innovation: We may be operating in a domain where we need to do things we have never done before; perhaps nobody has.
  • The Details of a Story: We often want to estimate a story before it is fully understood; we may have to predict the effects of complicated business rules and constraints that aren’t yet articulated or even anticipated.
  • The Relationship to Other Stories: Some stories can be easier or harder depending on the other stories that will be implemented.
  • The Team: Even if we have the same people as the last project, and the team stays stable throughout the project, people change over time. It’s even harder with a new team.
  • Technology: We may know some of the technology we’ll use in a large project, but it’s rare to know it all up-front. Thus our estimates have to account for learning time.
  • The Approach to the Solution: We may not yet know how we intend to solve the problem.
  • The Relationship to Existing Code: We may not know whether we’ll be working in a habitable section of the existing solution.
  • The Rate of Change: We may need to estimate not just “What is the story now?” but also “What will it be by the end?”
  • Dysfunctional Games: In some environments, estimates are valued mostly as a tool for political power-plays; objective estimates may have little use. (There’s plenty to say about estimates vs. commitments, schedule chicken, and many other abuses but I’ll save that for another time.)
  • Overhead: External factors affect estimates. If we multi-task or get pulled off to side projects, things will take longer.

Sitting in a planning meeting for a day or a week and ginning up a feeling of commitment won’t overcome these challenges.

Flaws In Estimating

We tend to speak as if estimates are concrete and passive: “Given this story, what is the estimate?”

But it’s not that simple:

  • N for Negotiable” suggests that flexibility in stories is beneficial: flexible stories help us find bargains with the most value for their cost. But the more variation you allow, the harder it is to estimate.
  • I for Independent” suggests that we create stories that can be independently estimated and implemented. While this is mostly true, it is a simplification of reality: sometimes the cost of a story depends on the order of implementation or on what else is implemented. It may be hard to capture that in estimates.
  • Factors that make it hard to estimate are not stable over time. So even if you’re able to take all those factors into account, you also have to account for their instability.

Is estimating hopeless? If you think estimation is a simple process that will yield an exact (and correct!) number, then you are on a futile quest. If you just need enough information from estimates to guide decisions, you can usually get that.

Some projects need detailed estimates, and are willing to spend what it takes to get them. In general, though, Tom DeMarco has it right: “Strict control is something that matters a lot on relatively useless projects and much less on useful projects.”

Where does that leave things? The best way is to use as light an estimation process as you can tolerate.

We’ll explore three approaches: counting stories, historical estimates, and rough order of magnitude estimates.

Simple Estimates: Count the Stories

More than ten years ago, Don Wells proposed a very simple approach: “Just count the stories.”

Here’s a thought experiment:

  • Take a bunch of numbers representing the true sizes of stories
  • Take a random sample
  • The average of the sample is an approximation of the average of the original set, so use that average as the estimate of the size of every story (“Call it a 1″)
  • The estimate for the total is the number of stories times the sample average

What could make this not work?

  • If stories are highly inter-dependent, and the order they’re done in makes a dramatic difference to their size, the first step is void since there’s no such thing as the “true” size.
  • If you cherry-pick easy or hard stories rather than a random set, you will bias the estimate.
  • If your ability to make progress shifts over time, the estimates will diverge. (Agile teams try to reduce that risk with refactoring, testing, and simple design.)

I’ve seen several teams use a simple approach: they figure out a line between “small enough to understand and implement” and “too big”, then require that stories accepted for implementation be in the former range.

Historical Estimates (ala Kanban)

For many teams, the size of stories is not the driving factor in how long a story takes to deliver. Rather, work-in-progress (WIP) is the challenge: a new story has to wait in line behind a lot of existing work.

A good measure is total lead time (also known as cycle time or various other names): how long from order to delivery. Kanban approaches often use this measure, but other methods can too.

If we track history, we can measure the cycle times and look for patterns. If we see that the average story takes 10 days to deliver and that 95% of the stories take 22 or fewer days to deliver, we get a fairly good picture of the time to deliver the next story.

This moves the estimation question from “How big is this?” to “How soon can I get it?”

When WIP is high, it is the dominant factor in delivery performance; as WIP approaches 0, the size of the individual item becomes significant.

Rough Order of Magnitude

A rough order of magnitude estimate just tries to guess the time unit: hours, days, weeks, months, years.

You might use such estimates like this:

  • Explore risk, value, and options
  • Make rough order of magnitude estimates
  • Focus first on what it takes to create a minimal but useful version of the most important stories
  • From there, decide how and how far to carry forward by negotiating to balance competing interests
  • Be open to learning along the way


Stories are estimable when we can make a good-enough prediction of time, cost, or other attributes we care about.

We looked at approaches to estimation and key factors that influence estimates.

Estimation does not have to be a heavy-weight and painful process. Try the lighter ways to work with estimates: counting stories, historical estimates, and/or rough order of magnitude estimates.

Whatever approach you take, spend as little as you can to get good-enough estimates.

Related Material

Postscript: My thinking on this has definitely evolved over the years, but I’ve always felt that Small and Testable stories are the most Estimable:)

Resources on Set-Based Design

yellow woods

“Two roads diverged in a yellow wood,

yet I could travel both.”

—Not Robert Frost


A reading list on set-based design (part of lean product development).


Applied Fluid Technologies. Information on boat design.


Baldwin, Carliss, and Kim Clark. Design Rules, Volume 1: The Power of Modularity. MIT Press, 2000. ISBN 0262024667. Modularity and platforms, from a somewhat economic perspective; not overly focused on software modularity. (No volume 2 yet:(


Kennedy, Michael. Product Development for the Lean Enterprise: Why Toyota’s System is Four Times More Productive and How You Can Implement It. Oaklea Press, 2008. ISBN 1892538180. Business novel, touches on set-based approaches. 


Kennedy, Michael and Kent Harmon. Ready, Set, Dominate: Implement Toyota’s Set-Based Learning for Developing Products, and Nobody Can Catch You. Oaklea Press, 2008. ISBN 1892538407. Second novel, also touches on set-based approaches. 


Morgan, James, and Jeffrey Liker. The Toyota Product Development System. Productivity Press, 2006. ISBN 1-56327-282-2. Overview of lean product development, touches on set-based approaches. 


Poppendieck, Mary and Tom. "Amplify Learning." The importance of communicating constraints (rather than solutions) in set-based development. 


Shook, John. Managing to Learn: Using the A3 Management Process to Solve Problems, Gain Agreement, Mentor, and Lead. Lean Enterprise Institute, 2008. ISBN 1934109207. A3 reports as the heart of lean management.


Sobek II, Durward, Allen Ward, and Jeffrey Liker. “Toyota’s Principles of Set-Based Concurrent Engineering,” Sloan Management Review, Winter, 1998. Basic description and principles of the approach. 


Wake, Bill. “Set-Based Concurrent Engineering.” Overview of several variations of set-based design in software. 


Ward, Allen, Jeffrey Liker, John Cristiano, Durward Sobek II. “The Second Toyota Paradox: How Delaying Decisions Can Make Better Cars Faster,” Sloan Management Review, Spring, 1995. Looks at how set-based concurrent engineering lets Toyota do better than other carmakers. 


Ward, Allen. Lean Product and Process Development. Lean Enterprise Institute, 2007. ISBN 978-1-934109-13-7. Description of knowledge waste, set-based concurrent engineering, and a different view of the PDCA cycle.


This is based on a list originally prepared for Agile 2009 by Bill Wake and Jean Tabaka.

Intensifying Stories: Running with the Winners

For a given story headline, many interpretations are possible. These vary in their quality and sophistication. I call this the intensity or depth of a story. Story intensity is a knob you can control, dialing it down for earlier delivery, dialing it up for a more complex product.

For example, consider the story "System Cross-Sells Item." The simplest version could suggest the same item to everybody. The next version could have the system suggest a bestseller in the same category as a shopping-cart item. The most sophisticated version might consider past purchases from this and millions of other users, take into account the customer's wish-list, and favor high-margin items.

Lowering Intensity

The most common way to move the intensity dial is to lower intensity. This is the domain of various story-splitting strategies such as 0-1-Many or Happy Path First. These techniques are usually used to pull out the most valuable parts of a story, or to help ensure it can be implemented in a short time-frame (e.g., an iteration).

Story splitting is an important tool, but in the rest of this article we'll focus on going the other way.

Why Intensify?

The ability to intensify is valuable because we are uncertain about what is most valuable. We have hypotheses, but reality can often surprise us.

Think of it as placing bets. Suppose you have six alternatives. You can bet everything on one choice, or you can place small bets on each alternative with followup bets when you see which one is winning. Put this way, it seems clear we're better off starting with small bets, unless we're already sure about which will win.

The Lean Startup community has a related idea. They note that startups often pivot from one business model to another as they try to create a business. One pivot is called a zoom-in pivot: take a subset of the original product, and build a business on just that. An example is Flickr: it started as a game with a sharing component, but was zoomed in to focus on just the photo-sharing aspects.

Intensifying: Three Approaches

There are three common ways to intensify stories:

  1. Improve quality attributes
  2. Apply story-splitting techniques backwards
  3. Invent intensifiers that add in more options or capabilities

Improve Quality Attributes

The most straightforward way to intensify a story is to improve some quality attribute. Quality attributes, also known as non-functional requirements or "ilities," have a scale that tells how good something must be. Intensifying is just a matter of targeting a better number.

For example, suppose our system must support 125 transactions/second. We could intensify this by raising that to 500 transactions/second.

This form of intensifying is the least creative: take an attribute and ask for one 5x as good.

Be careful: some increases can be extremely expensive. A system that is 99% available can have 3.5 days of downtime per year; one with 99.9999% availability can have only ~30 seconds of downtime per year. A desktop machine might support the first one, but the second one might require a sophisticated and expensive multi-site setup.

Apply Story-Splitting in Reverse

For any story we've already split down, we can of course intensify it by combining everything back together.

But we can also use story splitting techniques as a way to generate new possibilities. For example, the 0-1-Many split says that when we have many of something, we can reduce it to 0 or 1 ways. To run this split backwards, we find something where we have only one of something, and generalize it to many.

For example, we may be able to save a document in a specific file format. We can look at this as a "one"; and look for a "many." In this case, that might mean supporting a variety of output formats.

Invent Intensifiers

The third approach is to find creative ways to improve a feature or set of features. There's no fixed set of ways to do this, though we can identify some common approaches.

Let's take a story "User finds matching item" to describe a searching process, and look at several ways to make this feature more sophisticated.

Add Control: We can provide options that let the user do a more precise or broader search:

  • Boolean operators
  • Proximity operators ("Agile within 3 words of Testing")
  • "Find more like this"

Add Intelligence: We get the system to automatically do more for us:

  • Automatically search for synonyms
  • Autofill with the most common searches
  • Automatically classify results

Manage History: Searching is rarely a one-time event; we can put the activity in more context by considering what has gone before.

  • Save searches for future use
  • Manage a list of previous searches or previous results

Manage Multiple Items: A user may have multiple searches active at once, and want to coordinate them.

  • Allow multiple search result windows
  • Compare results of two searches
  • Merge results from multiple searches


Intensity is a controllable characteristic of stories.

To lower intensity, standard story-splitting techniques apply.

To increase intensity, there are several approaches:

  • Improve quality attributes
  • Apply story-splitting in reverse
  • Invent intensifiers

By controlling the intensity of stories, we can better respond to the uncertainties of development and use.

Related Articles

Valuable Stories in the INVEST Model

Of all the attributes of the INVEST model, "Valuable" is the easiest one to, well, value. Who is against value?

We'll look at these key aspects:

  • What is value?
  • The importance of external impact
  • Value for whom?

What is Value?

Value depends on what we're trying to achieve. One old formula is IRACIS. (Gane & Sarson mentioned it in 1977 in Structured Systems Analysis, and didn't claim it was original with them.) IRACIS means:

  • Increase Revenue
  • Avoid Costs
  • Improve Service.

Increase Revenue: Add new features (or improve old ones) because somebody will pay more when they're present. 

Avoid Costs: Much software is written to help someone avoid spending money. For example, suppose you're writing software to support a call center: every second you save on a typical transaction means fewer total agents are needed, saving the company money. 

Improve Service: Some work is intended to improve existing capabilities. Consider Skype, the voice network: improving call quality is not a new feature, but it has value. (For example, more customers might stay with the service when call quality is higher.) 

IRACIS covers several types of value, but there are others:

Meet Regulations: The government may demand that we support certain capabilities (whether we want to or not). For example, credit card companies are required to support a "Do Not Call" list for customers who don't want new offers. If the company didn't provide the capability by a certain date, the government would shut down the company.

Build Reputation: Some things are done to increase our visibility in the marketplace. An example might be producing a free demo version of packaged software, to improve its marketing. In effect, these are an indirect way to increase revenue.

Create Options: Some things give us more flexibility in the future. For example, we may invest in database independence today, to give us the ability to quickly change databases in the future. The future is uncertain; options are insurance. 

Generate Information: Sometimes we need better information to help us make a good decision. For example, we might do an A-B test to tell us which color button sells more. XP-style spikes may fit this category as well.

Build Team: Sometimes a feature is chosen because it will help the team successfully bond, or learn important to the future.

Several of these values may apply at the same time. (There's nothing that makes this an exhaustive list, either.) Because multiple types of values are involved, making decisions is not easy: we have to trade across multiple dimensions. 

Valuing External Impact

Software is designed to accomplish something in the real world.

We'll lean on a classic analysis idea: describe the system's behavior as if the system is implemented with a perfect technology. Focus on the effects of the system in the world.

This helps clarify what are "real" stories: they start from outside the system and go in, or start inside and go outside. 

This also helps us avoid two problems:

  • "stories" that are about the solution we're using (the technology)
  • "stories" that are about the creators of the system, or what they want

If we frame stories so their impact is clear, product owners and users can understand what the stories bring, and make good choices about them. 

Value for Whom?

Who gets the benefit of the software we create? (One person can fill several of these roles, and this is not an exhaustive list.)

Users: The word "User" isn't the best, but we really are talking about the people who use the software. Sometimes the user may be indirect: with a call center, the agent is the direct user, and the customer talking to them is indirect. 

Purchasers: Purchasers are responsible for choosing and paying for the software. (Sometimes even these are separate roles.) Purchasers' needs often do not fully align with those of users. For example, the agents using call center software may not want to be monitored, but the purchaser of the system may require that capability.

Development Organizations: In some cases, the development organization has needs that are reflected in things like compliance to standards, use of default languages and architectures, and so on.

Sponsors: Sponsors are the people paying for the software being developed. They want some return on their investment. 

There can be other kinds of people who get value from software we develop. Part of the job of a development team is balancing the needs of various stakeholders.


We looked at what values is: IRACIS (Increase Revenue, Avoid Costs, Improve Service), as well as other things including Meeting Regulations, Generating Information, and Creating Options. 

We briefly explored the idea that good stories usually talk about what happens on the edge of the system: the effects of the software in the world.

Finally, we considered how various stakeholders benefit: users, purchasers, development organizations, and sponsors.

Value is important. It's surprisingly easy to get disconnected from it, so returning to the understanding of "What is value for this project?" is critical.

Related Material

Negotiable Stories in the INVEST Model

In the INVEST model for user stories, N is for Negotiable (and Negotiated). Negotiable hints at several important things about stories:

  • The importance of collaboration
  • Evolutionary design
  • Response to change


Why do firms exist? Why isn't everything done by individuals interacting in a marketplace? Nobel-prize winner Ronald Coase gave this answer: firms reduce the friction of working together. 

Working with individuals has costs: you have to find someone to work with, negotiate a contract, monitor performance carefully–and all these have a higher overhead compared to working with someone in the same firm. In effect, a company creates a zone where people can act in a higher-trust way (which often yields better results at a lower cost). 

The same dynamic, of course, plays out in software teams; teams that can act from trust and goodwill expect better results. Negotiable features take advantage of that trust: people can work together, share ideas, and jointly own the result. 

Evolutionary Design

High-level stories, written from the perspective of the actors that use the system, define capabilities of the system without over-constraining the implementation approach. This reflects a classic goal for requirements: specify what, not how. (Admittedly, the motto is better-loved than the practice.)

Consider an example: an online bookstore. (This is a company that sells stories and information printed onto pieces of paper, in a package known as a "book.") This system may have a requirement "Fulfillment sends book and receipt." At this level, we've specified our need but haven't committed to a  particular approach. Several implementations are possible:

  • A fulfillment clerk gets a note telling which items to send, picks them off the shelf, writes a receipt by hand, packages everything, and takes the accumulated packages to the delivery store every day.
  • The system generates a list of items to package, sorted by (warehouse) aisle and customer. A clerk takes this "pick list" and pushes a cart through the warehouse, picking up the items called for. A different clerk prints labels and receipts, packages the items, and leaves them where a shipper will pick them up. 
  • Items are pre-packaged and stored on smart shelves (related to the routing systems used for baggage at large airports). The shelves send the item to a labeler machine, which sends them to a sorter that crates them by zip code, for the shipper to pick up. 

Each of these approaches fulfills the requirement. (They vary in their non-functional characteristics, cost, etc.)

By keeping the story at a higher level, we leave room to negotiate: to work out a solution that takes everything into account as best we can. We can create a path that lets us evolve our solution, from basic to advanced form. 


Waterfall development is sometimes described as "throw it over the wall": create a "perfect" description of a solution, feed it to one team for design, another for implementation, another for testing, and so on, with no real feedback between teams. But this approach assumes that you can not only correctly identify problems and solutions, but also communicate these in exactly the right way to trigger the right behavior in others. 

Some projects can work with this approach, or at least come close enough. But others are addressing "wicked problems" where any solution affects the perceived requirements in unpredictable ways. Our only hope in these situations is to intervene in some way, get feedback, and go from there.

Some teams can (or try to) create a big static backlog at the start of a project, then measure burndown until those items are all done. But this doesn't work well when feedback is needed.

Negotiable stories help even in ambiguous situations; we can work with high-level descriptions early, and build details as we go. By starting with stories at a high level, expanding details as necessary, and leaving room to adjust as we learn more, we can more easily evolve to a solution that balances all our needs.  

Related Material

The System Metaphor Explored

The System Metaphor is one of the less popular parts of Extreme Programming (XP). Newer descriptions often even omit it. But metaphor is useful – when you have  a good one, it really helps you understand and organize your system.

This post has a couple versions of a tutorial that Steve Wake and I developed and presented at some of the early Agile conferences. It's released under Creative Commons CC-BY-SA.

Versions: PPT, PDF (2-up), PDF with notes

Thee's also a SlideShare version

Independent Stories in the INVEST Model

The INVEST model is a reminder of the important characteristics of user stories, and it starts with I for Independent.

Independent stories each describe different aspects of a system's capabilities. They are easier to work with because each one can be (mostly) understood, tracked, implemented, tested, etc. on its own. 

Agile software approaches are flexible, better able to pursue whatever is most valuable today, not constrained to follow a 6-month old guess about what would be most valuable today. Independent stories help make that true: rather than a "take it or leave it" lump, they let us focus on particular aspects of a system.

We would like a system's description to be consistent and complete. Independent stories help with that too: by avoiding overlap, they reduce places where descriptions contradict each other, and they make it easier to consider whether we've described everything we need.

Three common types of dependency: overlap, order, and containment

What makes stories dependent rather than independent? There are three common types of dependency: overlap (undesirable), order (mostly can be worked around), and containment (sometimes helpful). 

Overlap Dependency

Overlap is the most painful form of dependency. Imagine a set of underlying capabilities:
        {A, B, C, D, E, F}
with stories that cover various subsets:
        {A, B}
        {A, B, F}
        {B, C, D}
        {B, C, F}
        {B, E}
        {E, F}

Quick: what's the smallest set of stories that ensure that capabilities {A, B, C, D, E, F} are present? What about {A, B, C, E}? Can we get those and nothing else?

When stories overlap, it's hard to ensure that everything is covered at least once, and we risk confusion when things are covered more than once. 

Overlapping stories create confusion.

For example, consider an email system with the stories "User sends and receives messages" and "User sends and replies to messages." (Just seeing the word "and" in a story title can make you suspicious, but you really have to consider multiple stories to know if there's overlap.) Both stories mention sending a message. We can partition the stories differently to reduce overlap:

    User sends [new] message
    User receives message
    User replies to message

(Note that we're not concerned about "technical" overlap at this level: sending and replying to messages would presumably share a lot of technical tasks. How we design the system or schedule the work is not our primary concern when we're trying to understand the system's behavior.)

Order Dependency

A second common dependency is order dependency: "this story must be implemented before that one."

Order dependencies complicate a plan,
but we can usually eliminate them.

While there's no approach that guarantees it, order dependency tends to be something that is mostly harmless and can be worked around. There are several reasons for that:

  1. Some order dependencies flow from the nature of the problem. For example, a story "User re-sends a message" naturally follows "User sends message." Even if there is an order dependency we can't eliminate, it doesn't matter since the business will tend to schedule these stories in a way that reflects it. 
  2. Even when a dependency exists, there's only a 50/50 chance we'll want to schedule things in the "wrong" order.
  3. We can find clever ways to remove most of the order dependencies.

For example, a user might need an account before they can send email. That might make us think we need to implement the account management stories first (stories like "Admin creates account"). Instead, we could build in ("hard-code") the initial accounts. (You might look at this as "hard-coding" or you might think of it as "the skinniest possible version of account management"; either way, it's a lot less work.)

Why take that approach? Because we want to explore certain areas first. We consider both value and risk. On the value side, we may focus on the parts paying customers will value most (to attract them with an early delivery). On the risk side, we may find it important to address risks, thinking of them as negative value.  In our example, we may be concerned about poor usability as a risk. A few hard-coded accounts would be enough to let us explore the usability concerns. 

Containment Dependency

Containment dependency comes in when we organize stories hierarchically: "this story contains these others." Teams use different terms for this idea: you might hear talk of "themes, epics, and stories," "features and stories," "stories and sub-stories," etc. A hierarchy is an organizational tool; it can be used formally or informally. 

A good organization for describing a system is rarely the best organization for scheduling its implementation.

The biggest caveat about a hierarchical decomposition is that while it's a helpful strategy for organizing and understanding a large set of stories, it doesn't make a good scheduling strategy. It can encourage you to do a "depth-first" schedule: address this area, and when it's done, go the next area. But really, it's unlikely that the most valuable stories will all be in a single area. Rather, we benefit from first creating a minimal version of the whole system, then a fancier version (with the next most important feature), and so on. 

Bottom Line

Independent stories help both the business and technical sides of a project. From a business perspective, the project gets a simple model focused on the business goals, not over-constrained by technical dependencies. From a technical perspective, independent stories encourage a minimal implementation, and support design approaches that minimize and mange implementation dependencies. 

Related Material

"INVEST in Good Stories, and SMART Tasks" – the original article describing the INVEST model

Composing User Stories – eLearning from Industrial Logic

User Stories Applied, by Mike Cohn

3A – Arrange, Act, Assert

Some unit tests are focused, other are like a run-on sentence. How can we create tests that are focused and communicate well?

What's a good structure for a unit test?

3A: Arrange, Act, Assert

We want to test the behavior of objects. One good approach is to put an object into each "interesting" configuration it has, and try various actions on it. 

Consider the various types of behaviors an object has:

  • Constructors
  • Mutators, also known as modifiers or commands
  • Accessors, also known as queries
  • Iterators

I learned this separation a long time ago but I don't know the source (though my guess would be some Abstract Data Type research). It's embodied in Bertrand Meyer's "command-query separation" principle, and others have independently invented it.

With those distinctions in mind, we can create tests:

Arrange: Set up the object to be tested. We may need to surround the object with collaborators. For testing purposes, those collaborators might be test objects (mocks, fakes, etc.) or the real thing.

Act: Act on the object (through some mutator). You may need to give it parameters (again, possibly test objects).

Assert: Make claims about the object, its collaborators, its parameters, and possibly (rarely!!) global state. 

Where to Begin?

You might think that the Arrange is the natural thing to write first, since it comes first.

When I'm systematically working through an object's behaviors, I may write the Act line first. 

But a useful technique I learned from Jim Newkirk is that writing the Assert first is a great place to start. When you have a new behavior you know you want to test, Assert First lets you start by asking "Suppose it worked; how would I be able to tell?" With the Assert in place, you can do what Industrial Logic calls "Frame First" and lean on the IDE to "fill in the blanks." 


Aren't some things easier to test with a sequence of actions and assertions?

Occasionally a sequence is needed, but the 3A pattern is partly a reaction to large tests that look like this:

  • Arrange
  • Act
  • Assert
  • Act
  • Assert
  • Arrange more
  • Act
  • Assert

To understand a test like that, you have to track state over a series of activities. It's hard to see what object is the focus of the test, and it's hard to see that you've covered each interesting case. Such multi-step unit tests are usually better off being split into several tests.

But I won't say "never do it"; there could be some case where the goal is to track a cumulative state and it's just easier to understand in one series of calls. 

Sometimes we want to make sure of our setup. Is it OK to have an extra assert?

Such a test looks like this:

  • Arrange
  • Assert that the setup is OK
  • Act
  • Assert that the behavior is right

First, consider whether this should be two separate tests, or whether setup is too complicated (if we can't trust objects to be in the initial state we want). Still, if it seems necessary to do this checking, it's worth bending the guideline.

What about the notion of having "one assert per test"?

I don't follow that guideline too closely. I consider it for two things: 

  1. A series of assertions may indicate the object is missing functionality which should be added (and tested). The classical case is equals()It's better to define an equals() method than (possibly create and) repeat a bunch of assertions about held data.
  2. A series of similar assertions might benefit from a helper (assertion) method.

(If an object has many accessors, it may indicate the object is doing too much.)

When a test modifies an object, I typically find it easiest to consider most accessors together. 

For example, consider a list that tracks the number of objects and the maximum entry. One test might look like this:

    List list = new List();
    assertEquals(1, list.size());
    assertEquals(3, list.max());

That is, it considers the case "what all happens when one item is inserted into an empty list?" Then the various assertions each explore a different "dimension" of the object.

What about setup?

Most xUnit frameworks let you define a method that is called before each test. This lets you pull out some common code for the tests, and it is part of the initial Arrange. (Thus you have to look in two places to understand the full Arrange-ment.)

What about teardown?

Most xUnit frameworks let you define a method that is called after each test. For example, if a test opens a file connection, the teardown could close that connection.

If you need teardown, use it, of course. But I'm not adding a fourth A to the pattern: most unit tests don't need teardown. Unit tests (for the bulk of the system) don't talk to external systems, databases, files, etc., and Arrange-Act-Assert is a pattern for unit tests. 


I (Bill Wake) observed and named the pattern in 2001. "Arrange-Act-Assert" has been the full name the whole time, but it's been variously abbreviated as AAA or 3A. Kent Beck mentions this pattern in his book Test-Driven Development: By Example (p. 97). This article was written in 2011. Added a description of Assert First and Frame First due to Brian Marick's comment. [4/26/11] 

Tests from a Hat

How does the order of tests affect the design of software?


  • Write a bunch of plausible unit test descriptions.
  • Slice them into strips and put them in a hat.
  • Repeat until the hat is empty:
    • Pull tests one at a time from a hat.
    • Write the indicated test
    • Write the code to make the last test pass, TDD style.
    • If you absolutely must create a prerequisite test, do so.
    • Refactor as you go.
  • Set aside your implementation, shuffle the tests back into the hat, and repeat once or twice.

Exercise ideas:

  • spreadsheet (domain objects, parsing, representation of storage),
  • auction sniper (from Freeman and Pryce’s Growing Object-Oriented Software),
  • video rental store (from Fowler et al’s Refactoring),
  • currency (from Beck’s Test-Driven Development),

Sample Tests for a Spreadsheet:

  1. New sheet is empty
  2. Inserting into a sheet stores a value
  3. Numeric cells are formatted as numbers
  4. Cells retain literal values (for editing) Ex: 007 is edited as 007 but displays as 7.
  5. Cells starting with = are formulas.
  6. Constant formula Ex. =7
  7. Parentheses in formulas
  8. Multiplication in formulas
  9. Addition in formulas
  10. Precedence in formulas

Reflection Points:

  • Did you encode your tests the same each time?
  • Did the solutions come out basically the same? Why or why not?
  • Did you see alternative solution paths when you went through again?

Bill Wake, 2010. Inspired by "Scenes From a Hat" in improv.

Review – Growing Object-Oriented Software, Guided by Tests

Growing Object-Oriented Software, Guided by Tests, by Steve Freeman and Nat Pryce, ISBN 0-321-50362-7

Freeman and Pryce explain Test-Driven Development through an extended example. (They have a somewhat different perspective than I do, with much heavier use of mock objects. I'm not sure what drives this difference; it may be due to type of application, philosophical reasons, or just something I should learn.) I love the clarity with which they tackle the problem of driving in from all the way outside, and how they don't shy away from dealing with concurrency and persistence. It's high praise for me to say a book deserves further study; this book is one I'll definitely be reading again. 


Movie Retrospective

When I'm teaching about retrospectives, there has always been a challenge: a simulated retrospective wants a shared experience. But what shared experience to use?

  • The one experience I know we share is the session we're in, but using a retrospective on the class sets up an awkward "meta" and recursive dynamic, as we try to do something and think about doing it at the same time.
  • A class often shares another experience (or set of experiences): the projects they're working on. Everybody may not be on the same project, but even if they are, real projects have real issues, and using real issues for an example almost instantly violates safety and takes away the magic circle aspect where it's safe to try new behaviors.


1. Identify a movie as the shared experience. I've been using Star Wars, Episode IV, with the part of the movie from the rescue of Leia until Obi-Wan dies and the protagonists escape. (Sorry if that's a spoiler:)

(I'm sure other well-known movies would work as well but I haven't tried any; perhaps The Wizard of Oz or The Godfather or something more modern?)

It's possible a person or two hasn't seen the movie; I'm willing to take that chance. If I thought the background of the group was so diverse that a substantial part of the group would not have a shared movie, I'd try a different approach.

2. Ask people to imagine they were the protagonists, to recollect for a moment what happened in the relevant part of the movie.
[A couple times I tried to show the movie clip in fast-forward. From a technology standpoint, it was painful. But from the perspective of the simulation, it's a better simulation NOT to show anything. As in real life, people will have different memories of what happened and different perceptions of what's important.]

3. Use the recalled scenes as the basis for a retrospective.
I like Esther Derby and Diana Larsen's approach in Agile Retrospectives, and I use an abbreviated sample exercise addressing each of their sections. For example:

A. Set the stage: Check-In – "In a word or two, what's on your mind?"

B. Gather data: Timeline – "Recall the memorable, meaningful, and/or significant events; write one per sticky note, then put it on the timeline."

C. Generate Insights – Patterns and Shifts – "Look for patterns. What links? What shifts? Which are most important?". Or perhaps do a "Worked Well / Do Differently" analysis.

D. Decide What to Do – Dot Voting – Give everybody 3 dots to vote for what to focus on as a group over the near term. (They can put their dots on 3 different things, or all on the same one if they feel strongly.) Agree on the immediate (concrete) next steps, who will lead them, and how and when progress will be reported.

E. Close the Retrospective – Appreciations – Identify how others have contributed. "Bob, I appreciate you for ___." ("Thank you.")

Even doing this in an abbreviated manner (a few minutes for each) lets you run through a complete retrospective in miniature.

You can then follow it up with some debriefing to bring out any points you need to make.

Bill Wake, 2010. [8/15/10 – Thanks to Diana Larsen for helping me ensure "Decide What to Do" results in action.]

Coach Interview: Declan Whelan

Interview with coach Declan Whelan. Our discussion, held June 1, 2008 at the Agile Coach Camp. 

WW – Take a minute and tell me about yourself and your background, and how you became a coach and what you're up to.

DW – I've been in software for… I realized it's over 20 years and I think, "Oh my gosh, but I have the gray hair to prove it." About four years ago I was doing some consulting work with a company in Toronto. They had decided to go agile across the board and they brought in some excellent coaches such as Jim Shore, Jim Highsmith, Joshua Kerievsky, and Gunjan Doshi. I had heard about XP before that but I hadn't really taken that much interest in it. But then I saw what was going on. It was phenomenal watching the energy level and feeling that there was a deep and radical transformation happening. I got bit by the agile bug from that experience.

I then had an opportunity to work with a company that was really struggling with their software development group. They had been habitually late, habitually buggy. They would plan two or three point releases right after every major release because they knew they'd be patching it up. They were really at a point of failure. Someone said they were looking at firing the whole software team. I was a last resort. Now, the problems were really much wider than the software team but that was the flash point. This was a good opportunity to bring agile in because they had nothing to lose. So we did, somewhat incrementally because the team couldn't turn on a dime. We just did some simple agile things then slowly evolved it so that after 18 months they were ready to launch a full-blown XP project which was quite successful. After that, the team transitioned to use a combination of Scrum and XP.

I continue to consult with this company and have expanded my agile repertoire. I now provide agile coaching, training, and development on a wider scale.

WW – What practices did you start with on the incremental path you had them on?

DW – It was simple PM stuff. I had the business unit work with me and the lead developer to estimate all the open issues and classify them as:

"A": Must have
"B": Should have
"C":  Nice to have

I then talked to the development team and got their buy-in that they would commit to and support a date if I guaranteed that they would have twice as long to do the work as they themselves estimated. They supported that.

Then we gave the business unit a development budget for the "A" issues:

"A" Budget = # of developers * working days / 2

We guaranteed to the business unit that we would deliver all the A issues. We would try to get some of the B's and C's — "If they happen to fall in the same area of the code, you might get some of those." They key was that we committed to a date and that gave the business unit some degree of certainty that  they could plan around. We then met with the business unit on a regular basis to track progress and to reprioritize as any new issues arose — but we held them to their A budget.

And it worked. The team was able to get all the A's and they got a few B's done and they met their commitment. The business unit were impressed: "Oh my gosh, that's the first time we ever had a release delivered on budget and on time." We were actually one week late but that wasn't bad compared to their traditional three months late. After that, the team planned and executed the next four releases like clockwork. So it was really just team building, setting reasonable expectations, and building trust and confidence.  Once the team and I had credibility, we were able to take the next step. "If you like what this is doing for you, we can be an even more effective team if we take the next step."

WW – What do you find the challenging areas for the coaching you do, either personally or from the angle of the hardest group or person to work with?

DW – I find for me, the hardest part on a one-on-one basis is the really skilled software developer. I find it really difficult to go in and be in the position of saying, "We're all in here to learn. Life is a continuing learning experience and perhaps I can bring you something that maybe you haven't seen before." But if they've been doing it for as long as I've been doing it, and especially if it's in their domain and they've been working on this team for ten years, they don't think there's anything they could possibly learn. I find it difficult to get them to switch that bit in their mind, to open up to the possibility that they could learn something new. For me that's been the biggest personal one-on-one challenge.

WW – Do you have any techniques or tricks you try with that?

DW – I've tried to be technically really good. I try to write code frequently, if possible every day. Try to stay current so I can gain some trust that I know what I'm talking about. Pair with them. I still find it a challenge. The really good people will always claim, "Yeah, that worked well in this case, but in the 95% of the cases I deal with…" It seems to be this credibility thing, that I have a hard time bringing people to the stage where they can see for themselves. Do you have any?

WW – I do the same – I think pairing with them and being able to demonstrate that I can do solid things helps me too.

WW – What do you to do keep up with your own learning that you need to do?

DW – Read. I read a lot. I tend to read seven books at once. I don't know if it's a common pattern, it's probably not a good pattern. I also buy a lot of books that I have on the shelf. So if I have a question on planning, I'll go get Cohn's book on planning. I tend to have a large number of books.

There haven't traditionally been a lot of practitioners in my geographical area. I've been trying to build an agile community in the Waterloo area, which is where I work. That's looking good. I'm hoping that next year we'll have a local agile group.

I've had fairly challenging positions. I've been heads-down in the trenches for three of the last four years. It's only been in the last year that I've made an effort to get a website blog, go to conferences. I'm working on that part of it now.

WW – Is there a book you're reading now you particularly recommend?

DW – The one I'm reading now is Agile Software Development, second edition, by Cockburn. I started the appendices first like Alistair recommended. I find it fascinating he draws on relatively old stuff, stuff that was written in the '70s, and it resonates today. I'm an abstract thinker; I like to go from the abstract to the concrete, not the other way around. I think that's the way he writes. He derives concrete from the abstract content, and I like the mental model he likes to write from. I really like the jargon/analogy of a game. I'm a coach of kids in sports, and the strongest metaphor I've seen for agile coaching is coaching children's sport teams.

WW – Thank you.

 DW – You're welcome.


Embracing Commitment

Commitment is a powerful tool. [Originally published at InformIT.]

We often hear and speak of commitment. It's a term many people use, but it's a word with several different meanings. When you're clear about which kind of commitment you're asking for or using, you can connect to emotions, you can look for win-win benefits, and you can create reliable promises that others can build on.

In this article, I'll look at several meanings of the word “commitment,” at different commitment relationships, and at ways people assess or create commitment. I'll start with these aspects of commitment: attitude, motivation, hustle, and promise.

Commitment as Attitude

Commitment can be an attitude: an emotional state of attachment that puts the committed thing above other things; this commitment brings a sense of dedication. If you're committed, you're not working as a mercenary, committed only to the paycheck and not the cause. When you're committed, you care.

The software team was measured on the success of the project, but the project managers were assessed on the quality of their reporting. For the project managers, it was OK if the ship sank, as long as the sinking was properly predicted and the ship's log was up to date when it went down. People talked about teams being dedicated and committed to results, but nobody worried about the commitment of the project managers (to process).

Attitude talks about the emotional aspect, and that's notoriously hard to assess. However, if people don't care, the project has no chance.

Commitment as Motivation

Why do you come to work? What keeps you going on your project? What's your real goal?

Everybody has a different combination of motivations. For example:

  • Produce something someone values
  • Build something beautiful
  • Work with others we like
  • Work in a process we like
  • Look good to the boss
  • Program in Java
  • Build our resumes

As the last few items suggest, our motivation need not align with the best interests of the project or the company.

The team was based in two locations. One sub-team had developed a goal of eating at a different restaurant for lunch every day. They had spiraled out past 45 minutes each way. This was good for the sub-team's morale, but 2.5 hours or more lost out of the middle of the day was interfering with their productivity and their ability to work with the other sub-team.

Individual motivations may differ, but that's fine if they all point to the success of the project. If your motivation doesn't ultimately support the project's goals, you will weaken the project.

Motivation (especially shared motivation or mission) can serve to re-center you to True North, the direction your team is really trying to go.

Commitment as Hustle

What is the behavior of commitment? A sports coach may tell you that some teams have hustle—that extra bit of energy a team or individual puts in. A hustling team takes the extra couple of minutes to get things working and checked in before lunch. If something's due tomorrow, they'll try to get it done today just to be sure.

A team that's hustling may work overtime (a little, occasionally). Some managers treat overtime as the true sign of commitment. Bob Martin talks about a different sense of urgency: the 8-hour burn. This comes when you're working at such an intensity that there's no point in overtime; you're so “fried” you're likely to be more dangerous or useless than helpful.

It's easy to prefer the dramatic whether or not the drama is more effective.

On an early web project, the team had done much work to get ready, but had underestimated how hard the actual deployment would be. The team's manager later admitted that he loved the adrenaline rush of the two final all-nighters. He felt the team showed hustle, and he felt part of the team more than ever. (The team could have spent those hours over the previous months and skipped the drama, but perhaps the drama helped jell the team.)

Commitment as Promise

What is a promise? It's not a simple true-or-false proposition like “My car is yellow.” Is “I promise to give you a nickel” true or false? It depends on what I think, say, and do.

Speech act theory [Searle] [Winograd] is a linguistic tool that can help explain promises. The theory's key insight is that some statements create their own meaning: “I now pronounce you husband and wife” becomes true in the saying, if certain conditions are met.

What does it mean for a speaker to make a promise to a hearer? Here are some key conditions:

  • Both the speaker and the hearer agree on what is being promised.
  • Both sides believe the speaker has the time and resources to meet the agreement (even if not everything goes perfectly); neither is having private doubts.
  • Should problems arise, the speaker will put the commitment above other things, working beyond what had been expected to what is now needed.
  • If the speaker comes to believe the promise can't be kept, the speaker must notify the hearer as soon as possible, re-negotiate, and accept the consequences of failing to deliver.

A web of promise can form, helping a team work together. A series of kept promises builds trust [Solomon], and lets people worry less about whether others' jobs are being done.

Scrum has the notion of a Sprint Goal (though many teams don't use it). The team commits—promises—to meet the goal, rather than promising to complete a particular set of stories. This can open the door to creative solutions that meet the spirit of the sprint even if the exact plan isn't met. (Some teams frame the Sprint Goal as sets of stories: these are the things we promise to get done, these others are the ones we estimate will be done beyond that.)

If the Sprint Goal is in danger, Scrum defines Sprint Cancellation as a safety valve. It's ironic that Sprint Goals and Sprint Cancellation are often not used; the first is seen as too boring (“do the planned stories”) and the second as too dramatic (“launch a witch-hunt”).

Some teams make promises about what they'll deliver. Others make promises about their process (“A full day's work for a full day's pay” or “We'll use Scrum.”) Other teams make estimates, not promises.

Many teams have confusion about what they're doing; are they making an estimate (which can be wrong) or a promise (which needs a buffer)? Clarifying such ambiguities can go a long way to setting proper expectations.

Promises and Relationships

A plain promise is the simplest relationship: a speaker makes a promise. The structure is still simple even if the speaker and hearer participate in a web of promises, as long as there are no loops.

Mutual commitments create loops; most promises have a price. (“You give me $10 and I'll give you lunch.”) Mutual promises put leverage in the relationship. (“I'm not paying until you make me a proper sandwich.”) While explicit promises can be performed better or worse, there are sometimes tacit assumptions that cause problems if they're violated.

The Product Owner came in with a large body of work. The team said, “That's too much, but we can commit to this part (the most important third) in the time you're willing to allow.” The Product Owner agreed to that. The team hustled, and finished not only the promised part but about 50% more. They went in saying, “You're going to love this—we got lots more done than we thought we could.” The Product Owner said, “Yeah, that's great—but you only did half of what I wanted.”

The Product Owner had violated something the team tacitly expected—they not only wanted acknowledgment of the completed part, but “strokes” for the extra bit. They had exceeded their commitment, but were assessed against a promise that they had never made. (Do you think this team will hustle as much next time?)

Power relationships make promises even trickier. Managers are often in a position of both receiving and making promises to people: they receives promises in support of organizational goals, and make (often implicitly) promises about providing a supportive context. The supporting promises (or assumptions) may be things like, “I won't ask you to work excessive hours,” “I'll provide the tools you need,” “If things change radically, I'll take that into account.”

Finally, there's a surrounding promise from a manager that is also a threat: “If I'm not happy with you, I'll punish you or fire you.” The threat may be implicit or explicit; it's part of the structure of many employee relationships. When the threat is too close to the surface, the fear it creates can cause the very problems it's trying to prevent.

Signifiers and Manipulation

How do you know people are committed? You can't see attitudes or motivation; you can only see behavior. What signifiers do you look for? (I'm going to focus on a manager's point of view, as I've seen managers more explicitly concerned about commitment than team members, but anybody can have this concern.)

A manager sometimes tries to judge emotions by how people talk or their facial expressions. These are of course prone to being faked, “talking a good game.” That leads to a quest for observable behaviors. A manager may start looking for hustle.

Hustle can take the form of voluminous output, no coffee or web breaks, overtime, or constant typing. Any of these can be signs of intense working, but they can be faked as well. There certainly are groups whose hours are “just before the boss gets in till just after they leave, with the occasional midnight email.”

Explicit promises can help, but they're subject to manipulation as well. The implementer can provide something of low quality, either full of defects, or of poor design so it will be hard to extend. They can claim to have not understood what was wanted. (“We can do that, but you'll have to split the story this way and reschedule the rest.”)

Conversely, some managers feel that teams perform up to their capacity only when they're pressured: “What else can you fit in?” “That's not enough.” “Of course this story includes that; it was understood.” “Yes, that's what you promised, but I expect more from you.” In Peopleware, DeMarco and Lister warn, “People under time pressure don't work better, they just work faster. In order to work faster, they may have to sacrifice the quality of the product and their own job satisfaction.” Some teams can be pulled (inspired) by the right motivation, but can only be pushed (pressured) to compliance.

You can't see commitment. You can sometimes see behavior that suggests it, for example, promises kept. When there's a problem such as perceived low productivity, it's better to address that directly rather than assume that commitment is the issue.

Creating Commitment

Where does commitment come from? Sometimes the motivations line up: people have their individual motivations, but those are compatible with the overall goal, so they contribute to it.

Creating commitment is tricky—what are you trying to create? An emotional connection? High productivity? A culture of promises? Are you merely after the signifiers that make you feel better watching the team: a culture of appearances over actions, of busyness over productivity, of psychological pressure over trust?

The manager set up the planning meeting as a pep rally. He used sports analogies to describe the challenge as “the big game,” and had everybody sign a big poster with the ship date on it.

It may be that everybody was caught up in the moment. Junior people seemed to accept the challenge, but several senior people walked out muttering, “He's tried to hit these buttons before” or “That's an unrealistic schedule” but they weren't willing to speak up as that would be a CLM (career-limiting move).

A very similar scenario can have a different outcome: people respond to the challenge, they build an emotional connection to the project and the team, and they walk out jazzed up and ready to go.

What distinguishes the cases? There's no magic formula but these things affect it:

  • Does the goal fit higher aspirations? People want to change the world in some way, not just make shareholders richer. (They don't mind something that does both.)
  • Do people see where they can contribute? It's hard to be engaged if your contribution isn't important.
  • Is it the right level of challenge, not too easy and not too hard? If it's too easy, it's not worth the emotional investment. If it's too hard, people don't want to engage as they know they'll fail. (This is like the idea of “flow,” when challenges and skills align. [Csikszentmihalyi]) People often don't mind a little stretch.
  • Is it a free choice (free from undue pressure)? People want to be invited in, not ordered in.

What are the motivations you're encouraging? Extrinsic rewards (whether tangible, people-oriented, or special activities), or intrinsic motivation? The latter is more sustainable and self-reinforcing. [Martens]


Have you been caught in the trap of looking for appearances over results? Are you favoring drama and the appearance of busyness over actual productivity?

What sense of commitment are you after? If one party is providing estimates and the other side is interpreting it as promises, you'll have conflict.

Understand what you're looking for. Each type of commitment has its place. The right kind of commitment at the right time is extraordinarily powerful.


[Csikszentmihalyi] Mihaly Csikszentmihalyi.  Flow: The Psychology of Optimal Experience. Harper Perennial, 1990.

[DeMarco] Tom DeMarco and Timothy Lister. Peopleware: Productive Projects and Teams. Dorset House, 1987.

[Martens] Rainer Martens. Successful Coaching (3/e). Human Kinetics, 1997.

[Searle] John R. Searle. Speech Acts: An Essay in the Philosophy of Language. Cambridge University Press, 1969.

[Solomon] Robert Solomon and Fernando Flores. Building Trust: In Business, Politics, Relationships, and Life. Oxford University Press, 1993.

[Winograd] Terry Winograd and Fernando Flores. Understanding Computers and Cognition: A New Foundation for Design. Addison-Wesley, 1987.


Kevin Bradtke, Tom Kubit, Michele Matthews, and Doug Wake gave me valuable feedback and advice.

[Originally published Aug., 2009 at InformIT; republished here with their permission.]

Coach Interview: Alexey Krivitsky

Interview with Alexey Krivitsky; our discussion held June 1, 2008 at Agile Coach Camp in Ann Arbor, MI

WW (William Wake)- Alexey – To start, just take a minute or so and tell me about your background, how you came to be where you are today?
AK (Alexey Krivitsky) – I started as a developer about 8 years ago in Ukraine. I did some Java, .Net, Visual Basic. I quit that job; I had about half year to reflect on the years of my career. There were some books on agile on my shelf. One of them was Agile Software Development, first edition, by Alistair Cockburn, and some stuff about Scrum and XP. All these famous books… After finishing reading what I had, I thought it should work for me.

I found a job in a small offshoring company. The guys are from Denmark so they decided to set up a small team in Ukraine to maintain their software. They were quite flexible to change their process. By their nature they were a family business so they were willing to change anything and there was a guy who believed that agile can add value there. It was my real first experience with agile.

After that job I went working in Switzerland for a year.

What I'm doing now… I came back to Ukraine from Switzerland to set up an agile coaching business. Before that I had set up an agile community in Ukraine with about 200 people on the list, which is quite a lot, I think. I realized, "Here's an opportunity for me to develop myself in Ukraine," so I came back.

After about half a year, I realized that I was missing the real work. So I came back to my old team as a part-time Java developer. Now  I'm trying to combine being a coach and being a developer, which gives me quite the experience. I have a chance to see the problems from different angles.

It's quite interesting how many things you can change being a developer in a team, not a coach, not a guru, just from the inside of the team. You can affect a lot.

WW – Can you tell about one of the agile projects, either how they became agile or something that happened with them?
AK – When I was hired by these guys in Switzerland they had been running the project for more than half a year. They had people in Ukraine doing development. It was a chaotic project without planning. We just had to deliver something by a given day. I already had some Scrum experience, and I set myself a task to convert development to Scrum

Now I'd do it differently, but you learn from your mistakes.

I was at the client side. So I coached the Product team to define requirements in a more agile way, how to estimate, and all that kind of stuff.

WW – Did they work with monthly iterations, or what?
AK – They worked with 2-week iterations. We tried different durations and we ended up with 2-week iterations.

We didn't have a fully deployable version after each iteration. What we had is a demonstration server as it was quite difficult to do live production. At any time, the stakeholders could just log in and try it. We also had weekly demonstrations in which we presented what we had done so far to different stakeholders. It was our approach to agile which was based on Scrum.

WW – Are there any techniques, tools, or tips you have when you're coaching people?
AK – I would say I was a coach but it is impossible to coach people remotely. If you have somebody off site and you have to email or call, it's impossible to coach those guys. If you want to coach, you've got to stay with them and be involved with them.

WW – I'm interested in things you do, behaviors you have, whether you think of them as coaching or programming.
AK – I was at a position in my life where I stopped being a traditional team lead and turned myself into a ScrumMaster. It's hard to do, because you get used to proposing your ideas and believing that you're smarter than other people. Instead you have to start believing that the team can make up better ideas themselves. You make yourself stop talking and just ask questions. This is a hard thing to achieve.

When I coach teams now, I always ask questions rather than make statements. We also had a session today about skills, techniques, and questions – how to ask questions without any resistance.

So what I'm doing now is trying to help people go the way I think they should be going. It can be achieved by asking the right questions. Each time I have an idea which I believe the team should take, I just turn it into transforming discussion where I also have the chance to give my ideas. After that we just decide which way to go. They may have taken my idea or not, but we found something that should be working for them.

Another thing which I am practicing  is each time you are going to make a statement convert it to "What if you do it this way?" question.

Each time you're about to make a statement that can be taken with resistance, ask a question instead; it might help.

WW – What do you do to learn new things?
AK – We have an agile community – we organize conferences. It's a way for me to meet local experts and talk to them. I used to read blogs but I don't have that much time now. The conferences are the best investment of your time and money to learn something new. I will try to make the events in countries nearby. We'll see how it goes.

WW – Anything else you'd like to tell me about?
AK – I can tell you about the challenges of a coach in offshoring markets.

Developers in most cases are not interested in being agile; they do not see the values.

Neither is the management of the service companies – they do not care about efficiency. They care about the per hour rate.

The only right people are the product people. And they are far away

The outsourcing marketplace is quite huge, but there aren't that many agile people there.

WW – What do you find the biggest challenge when you're working with outsourced teams?
AK – The biggest challenge if you work on-site with the team is to make the client get this or get the customers to change the process. If you're a coach, you coach the team and coach the business people. It's hard to coach someone remotely. It's a challenge to coach teams to be more effective but it's only half the thing. The business people need to know how to manage requirements or releases in an agile way. There's no point in coaching just the development team.

It should be taken from two sides: somebody should be coaching the business side, somebody should be coaching the team.

I am looking for this kind of cooperation between US and European agile coaches.

WW – Thank you very much.
AK – I hope it was useful.
WW – I appreciate it.

User Story Examples

This is a sample set of stories for a time management system.

I've been interested in personal productivity systems for a while, so when Mark Forster introduced a new system called AutoFocus, I decided to create an electronic implementation. The system is a sort of todo list, in a organized as a notebook where each page has a list of tasks to do. There are rules defining the currently active page and task, and how you move your focus as you complete tasks. 

I began by analyzing the system (e.g., building a flowchart and transition diagrams to look at how tasks and focus move). I wrote some basic cards, and a series of screen sketches. For example, a task page will look something like this:

|<   <<   *   >>   >|

Add new task: [_______________]

Active Tasks
[ ] task 1
[*] task 3

Completed Tasks
[x] task 2
[x] task 4

[Dismiss] [Force Focus] [Move Focus]

|<   <<   *   >>   >|

(The characters at the top and bottom of the page represent navigation arrows.)

Basics – Tasks

The first cluster of stories is centered around tasks and assumes all tasks are on the same page.

Show tasks


Add a task


Mark task done

Notice that with just the above stories, the system could be a basic todo list manager.

Mark task progress

Basics – Pages

The system is built around the metaphor of a notebook; we need navigation around the pages. The "current" page can mean two things: either the page you're currently looking at, or the one with a currently active task.

Multiple pages


Navigate – first, last, previous, and next


Navigate to focus page


Move the focus page "forward"  [can wrap]

By the "rules," you're normally supposed to move the focus page forward (wrapping to the beginning) as you complete tasks. But there's a "don't be stupid" clause that says you can work where you need to.

Force the focus page here

Friendly Feedback

I want to push the system to a  point where I can get some friendly feedback.

First, I need to pick up the last major action required by AutoFocus:

Dismiss open tasks on page

Then I need to put the system somewhere others can see it:

Deploy to sandbox


I can't just have one notebook out there for the world to see; I need to introduce the notion of users. I actually started with a card that said "User Management" but I expanded it to these:







Forgot password


Update settings

Getting Real

What would it take for a beta test? I could probably defer "forgot password" and "update settings" but I have other work that would need to be done.

First, I'm asking users to trust the system and load in all their tasks. Paradoxically, I think if I make it less necessary to trust the system, people will trust it more. I'll do this by providing a means for them to export the tasks they've entered; then they know they can easily recover their work if they want to move on to a different system.

Backup/export tasks

Another aspect of trust is the look of the site. I have some OK default icons, but the site will shine better with a new set.

Polish stylesheet and images

It will have to be deployed to a public system:


"Home page" is a bit of a placeholder card. The bare minimum is to provide a login page, but in the long run it will need some explanation of the system and an appeal to register.

Home page

I could start with these on the home page but probably want them somewhere else.

Terms and privacy statement

I haven't decided how to fund the site, and I don't need to know to start a beta test. But eventually I'll need a revenue model fancier than "pray Google offers millions." There might be other ways, but the next two stories are what sprang to mind first.



Charge fees

Here's another story that could be big. I'm starting with a web site, but people may want to use their mobile phone to manage their tasks. This could be as simple as a special stylesheet, or it could become a whole separate application.

Support mobile phones


Sparkling Touches

These next stories are ideas I have that fit in the basic framework. They could be early upgrades.

Delete a task


Edit a task


Revive a task

I don't know what all I mean by page status, but it includes the date and whether this is the focused page.

Page status

Some tasks should just automatically recur once you complete them (e.g., "email inbox to 0"). I could put a flag on the task, or maybe find a more sophisticated approach.


Future Versions

I have a number of stories that aren't so well defined – the fuzzy ones.

People might want to pull out separate lists that aren't managed by the AutoFocus rules. I don't know if this needs to allow multiple user-created lists, or how that will work.


Once people get a lot of tasks, they may want to find a particular one:


A tickler is a reminder system that lets you schedule tasks out in the future. ("43 folders" – one for each month and one for each day number in the month – is a classic paper form.) Some people just put tickler tasks in their calendar, but I think it would be handy to have a tool that automatically brings them in to the task list as appropriate. I want to make sure to include the notion of lead time – I might like to be reminded that today is my sister's birthday, but I really need 2 weeks notice so I can get her a card or gift. (And I want that reminder as a task, not a phone or email reminder.)


Many tasks have a standard set of sub-tasks. I'd like to put them on a checklist and have them brought in on demand. The easy form is a "parallel" list – put all tasks on the list.

Checklist – parallel

The more classical form is to do the steps in order. When one step is completed, the next one should be scheduled.

Checklist – serial

People might like some sort of analysis, or it might be useful in supporting the system.


And I have a last one that's totally open. It's really more of a goal than a concrete story. It might be met by paid advertising, blogs, FAQs, help pages, email reminders, you name it.

Increase usage of the system


I feel good about this set of stories. They capture the bulk of what I want the system to do.

I used a simple "headline" form for the story titles – just a short verb phrase. I know the domain, and it's generally obvious who the story is for and what it's for, so I didn't feel the need to put them in the "As a ____, I want to ____ so that ____" form.

The stories came in three batches – the early task and page stories (with a couple sparklers), user and deployment stories, and the others. I developed them in combination with repeated sketches and analysis.

Another way to look at stories is to look at them versus the INVEST acronym (from my earlier article "INVEST in Good Stories"):

  • I – Independent. The stories mostly stand alone from each other. The dependencies tend to be domain-related rather than technical. (For example, it doesn't make much sense to have a logout story before you have a login.)
  • N – Negotiable. The smaller stories are straightforward and well-defined (though they have some room on the details). Bigger stories have a lot of flexibility. Plus, this is a one-person project so there's not much problem there.
  • V – Valuable. Each story adds a clear bit of functionality to the system. The most technical story ("deploy") still makes sense to a product owner.
  • E – Estimable. I have a good sense of which stories are well defined; even for the fuzzy stories I can make educated guesses about the order of magnitude.
  • S – Small. Stories ready to schedule (closer to the top of the list) are generally hours to a few days work. That's appropriate. Later stories are bigger; that's ok too. When it gets time to implement them, I'll break them down into small stories as well.
  • T – Testable. Ready-to-schedule stories are testable; the fuzzier stories will need more explanation and analysis before we could write a test.

If I look at the list of stories as a release plan, the order is generally good. (There are a few stories that could move down in priority.) But one thing stands out: deployment could be moved much further to the top. It could be the second story: a simple list of active tasks might be useful to somebody (perhaps as a status report or proof of concept). It's easier to deploy when the system is still small. And it's a key to getting feedback.