Stay Agile with Discovery, pt 1

Cindy works for AgileSoft as the Product Owner for its clients. AgileSoft contracted with Acme to do product development for its marketing website. Acme sells a variety of products and services, and wants the website to serve all audiences, from casual browsers to long-time customers. Acme’s Marketing, Sales and IT teams are involved, but Acme’s representative on the project is Bob from Marketing.

Bob is on board with an agile approach. He likes the idea of seeing steady progress and being able to make changes along the way. However, Bob’s boss, Martha, is not so sure. She just wants to know, “Will everything get done?”

Bob tried to explain the benefits of agile to Martha — Acme can see the product as AgileSoft develops it. He said, “You and I get to make some changes in the order in which AgileSoft develops it. We might realize we want different things, not just in a different order.”

Martha said, “Look, I need everything. I scoped this project with everyone — Marketing, Sales, and IT. You all agreed about our needs. I don’t care what order Cindy’s team works on the items, but I want everything we scoped.”

Martha is being reasonable in wanting to know the duration and cost of the project. However, any estimate is unreliable. As Yogi Berra said, “It's tough to make predictions, especially about the future.”

When you have a client like this, what can you do?


Do an agile “discovery” phase, which doesn’t obligate you to further work. Do a fixed-price, small-duration contract. Gather requirements, maybe do a spike or two, and develop a prototype. At the end of this short contract, you have a number of stories, a little design, and a prototype.

If the client does not want to work in an agile way, providing you feedback all along the way, you only have to do this one small contract. Then you can both call it quits. Agile will help you uncover and manage the technical risks and the client risks. A discovery project will also gauge the client’s ability to work in an agile manner:

  • Can the client make time to participate in an agile way?
  • Can the client re-plan with you when needed?
  • Does the client have the autonomy to make decisions about the content of the backlog?

If the answer is any of these is “No” then there is a problem. It’s virtually impossible to determine these things without actually working together, and a discovery project allows you to do it in a small, constrained way.

Cindy suggested a discovery project to Bob. He said, “I’m not so sure. We want it all.”

Cindy said, “The discovery project is necessary for us to create a responsible estimate for the rest of the project. In addition, you have something to show Martha and the other stakeholders, and you will better understand what you want after this phase is complete.”

“The discovery project helps us practice working together so you can feel what agile is and I can learn more about your requirements and what they mean for the project. Most of our clients think agile sounds good, but not all of them say if feels good. You need to learn if this approach will work for Acme.”

Cindy proposed — and Bob accepted — a one-month discovery project. During that time, they changed the contents of the backlog, still delivering what Bob wanted, but in a different order. However, they realized that based on one of AgileSoft’s demos, Acme might want to change the requirements.

As part of the discovery project, develop a project vision and release criteria. Now you can discuss why you are doing the project, and what “done” means. In the discovery project, you do enough work to know if there are some significant risks, and not so much that half the project is done.

You will use the learning from the discovery project to create the estimate, ask the client about change requests, and how to know what done means for the project.

Use the project vision and release criteria as a litmus test to determine when to take a client’s suggested change. Add changes that don’t fit in the current project on the roadmap for future projects.


When you provide a three-point estimate, you cover contingencies. For example, you can say, “These are the optimistic, likely, and pessimistic dates (or cost). The optimistic date means we believe we can finish the work and you won’t have any changes. We have yet to encounter a project like this, but we want to be honest with you.”

“With the likely date, we have built in a buffer that allows for some small changes. We can’t change the UI. We can’t change the underlying premises. But we can make some small changes and we think we can meet this date.

“With the pessimistic date, we think we can accommodate even more changes. Our experience with other clients like you, on projects like this, is that even though you think you know everything you want now, you might realize you want more or different things later. If so, we can manage those changes.”

Now, you can have a realistic conversation with your client about what to choose and when. Your job is to make the work for the optimistic date small enough so you can succeed. You might want to create small project with deliverables. Then you can re-estimate for each major deliverable.


Say to the client, “It’s important that during the project we check in to show our progress and discuss what work remains.”

If your client has selected the likely or pessimistic dates, now you can say something like,  “In addition, we’ll naturally learn more about your business and needs along the way. What we learn could impact the project. We can discuss roadmap changes if you want them.”

If your client selected the optimistic date, and you offered small projects with deliverables, you can offer to consider changes to future projects, not this one.

As part of the proposal for the project create a Client Check-In Schedule where you will:

  1. Demonstrate the work the team has accomplished
  2. Discuss what remains to be done
  3. Discuss new things you have learned that could affect the estimate.
  4. Discuss change requests and their impact to the project’s cost and time estimates

Deciding in advance when you will meet and what you will discuss communicates both the client’s role in the project and the inevitable change that will occur during the project. It puts you and the client on the “same side of the table” about changes and unexpected situations, working together to decide how to handle them.

Cindy discussed all of this with Bob. She decided to create a four-week discovery project, followed by three four-week mini-projects. Bob had selected the “likely” date.

After the first mini-project, Bob and Martha participated in the demonstration. Cindy showed them the deliverables. Bob and Martha asked questions. Then Martha asked the million-dollar question, “I would like to add this other feature here. Can we change our next project to do so?”

Cindy replied, “We can add part of it, because it works with the release criteria. This other part does not. AgileSoft can’t do that part unless we change the contract and price. What would you like to do?”

Martha said, “Well, I thought I knew what I wanted when we started. I guess I didn’t quite. Now that I’ve seen what you can do in a month, maybe we can be more — what did you call it, agile? — about this project.

Next: Use a Demo to Build Trust

Leave a Reply

This site uses Akismet to reduce spam. Learn how your comment data is processed.