7.5. Agile Cost Estimation¶

Given that the Agile Manifesto values customer collaboration over contract negotiation, it is unsurprising that it does not follow the plan-and-document approach of making a cost estimate and schedule for a given set of features as part of bid to win a contract, as we shall see in Section 7.9). This section describes the process at Pivotal Labs, which relies upon Agile development (Burkes 2012).

Because Pivotal does Agile, Pivotal never commits to delivering features X, Y, and Z by date D. Pivotal commits to providing a certain amount of resources to work in the most efficient way possible up to date D. Along the way, Pivotal needs the client to work with the project team to define priorities, and let Tracker’s velocity guide the decisions as to which features actually make it into the release on date D.

A potential client first gets in contact with the Agile team. If it looks like a good fit for the Agile team, they first do a 30 to 60 minute phone call telling potential clients what an engagement looks like, how it’s different from other “outsourcing” agencies, what type of time commitment it will require on the customer’s part, and so on. This first call makes clear that the Agile team works on a time and materials basis, not on a fixed bid basis, as is usually the case with plan-and-document processes. The Agile team gets them to describe at a high level what they want developed, what their current development process looks like, what their current staffing is, and so on.

If the clients are comfortable with what they heard, and the Agile team thinks it still sounds like a good fit, the clients visit for what Pivotal calls a “scoping.” A scoping is a roughly 90 minute conversation with a potential client, preferably in person. The Agile team asks the client to bring the person responsible for the product, a lead developer if they have one, a designer if they have one, any existing designs for what they want built, and so on. Basically, the client representatives bring whatever they think can clarify exactly what they want done, and the Agile team brings two engineers to the scoping.

During the scoping, the Agile team asks the client to describe what they want done in detail, and they ask a series of questions designed to identify unknowns, risks, external integrations, and so forth. Essentially, the Agile team wants to identify anything that would add uncertainty to the estimate that the Agile team will deliver. If the Agile team gets a client with a very clear definition of what they want to build, a finished design, no external integrations, and so on, the Agile team can produce a fairly tightly-scoped estimate, such as “20 to 22 weeks.” On the other hand, if they don’t have clear product definition, lots of external integrations, or other uncertainty, the Agile team’s estimate will have a greater range, such as “18 to 26 weeks.” If you use pair programming (see Section 2.2), as Pivotal Labs does, the cost estimates would be in “pair weeks.”

After the client leaves the scoping, the Pivot engineers involved will stay behind for another 15 to 30 minutes, and agree on an estimate in terms of weeks. They deliver their findings, which include the estimate, identification of risks, and so on, to the sales staff, who then turn that into a proposal email to the client.

Because the Agile team does time and materials only, it’s easy to turn estimated weeks into an estimated range of expense.

Self-Check 7.5.1. True or False: As practitioners of Agile Development, Pivotal Labs does not use contracts.

False. Pivotal certainly offers customers a contract that they sign, but it is primarily a promise to pay Pivotal for its best effort to make the customer happy over a limited range of time.

With the already helpful role of user stories for measuring progress behind us, we introduce a tool that lets user stories play yet another important role.