What are they talking about? What is the difference between acceptance criteria and the definition of done? Every field has its own special vocabulary and agile software development is no exception.
Artwork courtesy of Laura Quattri. Used by Permission
From acceptance criteria to working agreements, the following guide will help you navigate the waters by understanding the terminology.
Acceptance criteria - tests which must be passed for the Product Owner or customer to consider the story accepted. The Team should verify these before submitting a story for final approval. Acceptance tests help ensure external quality. Most product backlog items can be mapped to one or more acceptance criteria. See Definition of Done and Quality, external.
Agile - a movement for finding better ways of developing software. Scrum and Extreme Programming are two leading examples. Others, such as Kanban or Lean Startup do not define themselves in the agile tradition but are based on compatible values and principles.
Agreement - the basis for planning and completing work in Scrum. Examples: the definition of done, the selected product backlog, the sprint contract, and the definition of ready.
Artifact - something that archaeologists find when digging. Often used to describe the documents produced by a project management methodology. Scrum artifacts are all living documents to guide and monitor work. In Personal Agility they are called “tools.”
Backlog Refinement - the process of getting backlog items ready for implementation in the sprint. Typically, this means taking large, poorly defined backlog items, discussing them, and replacing them with several “smaller” backlog items that are individually less complex and easier-to-implement, but still add up to the original whole.
Best practice - some consultant's solution to someone else's problem. Is your context similar enough to the original for the solution to be applicable to you? Questionable. Will you do better by coming up with you own solution? Usually.
Ceremony - a fancy word for a meeting or routine process. In Scrum and Personal Agility these are called “events” to signify that something important happens and you want and need to be there!
Chickens - deprecated term for people interested in the results of a project, but not 100% committed to its success (e.g. due to conflicting priorities). Chickens can be very disruptive to the team. Never call someone a chicken. Spectators is a better metaphor. A professional sports game is played for the spectators, but the spectators are not allowed to interfere with the game.
Commitment - a core value of Scrum which should not be interpreted to mean that the team is expected to burn itself out trying to achieve unrealistic goals sprint after sprint after sprint.
Daily Scrum - a daily opportunity for the team to inspect and adapt on their progress throughout the sprint. Three traditional questions help the Team recognize that they need to talk to each other (preferably right after the daily scrum).
Definition of Done - an agreement on what 'this backlog item is done' actually means. Helps assure internal and external quality for each story. Often expressed as a checklist to be completed before submitting the story to the Product Owner. The definition of done applies to individual backlog items and to each increment, but not to individual tasks or whether the overall release has enough functionality to be delivered to the customer.
Development Team - consists of 3 to 9 people who have all the skills necessary to get from “idea” to “done” (not from spec to ready-to-test). Often referred to simply as “the Team.” The Team (and only the Team) creates the solution. It is responsible for “How?”. The Team is protected from noise but not isolated from the organization.
Done (for a feature) - a binary state. Either a backlog item is completed according to the definition of done, or not.
Done (for a product) - a judgement call by the Product Owner. At the end of a sprint, if the Product Owner believes that it's worthwhile to release, the product should be releasable. If it's not, there is undone work which should be addressed at the level of the definition of done in future sprints.
Estimate - the team's best guess at the size, complexity or time involved to convert a PBI into a piece of finished functionality. An estimate is not a commitment. More time on backlog refinement is usually more helpful to performance than more time on estimation.
Extreme programming (XP) - an agile approach to software development, often applied in conjunction with Scrum. XP defines the engineering practices needed to produce quality software in an iterative environment.
Evil - something which is difficult or impossible to get rid of but avoiding it is generally good for you. Weeds in the garden is one example. Treating multitasking, bugs, dependencies and spillover as evil is usually good for team performance.
Forecast - the Team's best guess at how much finished functionality it can deliver by the end of a sprint. The Team is normally expected to respect all the terms of the sprint contract, i.e. quality, time and cost, which are more important than scope.
How-to-demo - a short workflow for demonstrating to the Product Owner that the functionality has been implemented correctly. Also, useful to limit scope creep while implementing a product backlog item (“story”).
Impediment - anything which slows the Team down or prevents someone from working. Although the Scrum Master is charged with removing impediments and all Scrum events provide regular opportunities to recognize them, impediments can be identified and eliminated at any time by anyone.
Increment - an additional slice of customer visible value delivered at least once per sprint. The latest increment must integrate with the previous delivered increments to form a working whole.
Multitasking - pretending you can do more than one thing concurrently. In theory, if there is unused capacity available, multitasking can improve performance. However, multitasking has a cost, and if there is no free capacity it lowers performance by introducing wait times and creating dependencies between otherwise independent processes. Usually focusing on getting one thing done at a time is better for performance.
Must - absolutely required, or else! The Product Owner must attend sprint planning 1, otherwise the meeting cannot be held.
PBI - Product Backlog Item.
Pigs - deprecated term for those people 100% committed to the project at hand. Always refers to Scrum Master and Development Team. If it does not also refer to the Product Owner, this is a sign of dysfunction. While it might be okay to call yourself a pig, “players on the field in a professional sports match” is a better metaphor. Yes, the game is played for the spectators, and the spectators can have a surprising influence on the result, but the players must be able to play without undue interference. See also Chickens.
Priority, sequence - which item comes first, second, third, etc. The term priority is deprecated in Scrum because a) it contains emotional overtones and b) two items could have the same priority but in Scrum they must have a unique place in line, that is, in the product backlog.
Product Backlog - the single source of requirements for the product under development. It consists of functional and non-functional requirements. It is not used to plan work or define intermediate artifacts, like a specification, which have no value for the customer or user.
Product Backlog Item (PBI) - an entry in the product backlog consisting of a description (often a user story), a sequence position, and an estimate. Often enriched with acceptance criteria and other useful information. A PBI is not a specification, but rather a reminder to hold a conversation shortly before implementation.
Product Owner - a servant leader who guides the Development Team to produce customer visible value. Sometimes called the voice of the customer (or user) or the organization’s ambassador into the Scrum Team, the role represents all interests outside the Development Team to the team.
Quality, external - Did you build the right thing? Does it perform the way the customer or user wants and expects? Acceptance tests strive to ensure external quality.
Quality, internal - Did you build it right? Does the product behave the way its creators intended? Unit tests ensure that a program continues to behave correctly, even after modifications have been made.
Quality, overall - Are there enough features present to justify delivery? Also known as 'fitness for use.' A state achieved incrementally in Scrum. The Product Owner decides when this has occurred by calling for a release.
Release burn-down chart - a tool for visualizing the progress of the team toward a medium-term release goal. The x-axis represents time, measured in sprints. The y-axis is the sum of the estimates in the product backlog. When a PBI is done, its estimate can be deducted from the burn-down chart. It is the primary tool for ensuring that wishes and probable reality stay reasonably aligned.
Release burn-up chart - serves the same purpose as a release burn-down chart with a different visual representation. The y-axis represents the cumulative sum of the estimates of the features that have been included in the product increment. When a feature is completed, it’s estimate is added to the burn-up chart.
Release Planning Meeting - the Scrum Team comes together to refine the product backlog to focus on creating a release. Although time-boxed, there is no decision to be taken at the end of the meeting, so it is often a useful preparation for sprint planning. This term is deprecated, replaced by backlog refinement, which leaves more space for creative thinking.
Retrospective - the Development Team (and anybody they invite) reflects on how they worked to identify improvements for the next sprint. Usually the Scrum Master is invited to facilitate.
Ritual - fancy word for a meeting or routine process. Kind of implies that you won't miss anything if you don't go. Call it an event or an activity instead.
Scrum - a simple, team-based approach to solving complex problems. A mindset based on a culture of transparency and regular cycles of inspection and adaption. A popular approach for developing software.
Scrum Master - a servant leader who helps Product Owner and Development Team perform better. Helps the rest of the organization recognize which interactions with the Scrum Team are helpful and which are not. Encourages doing more of what’s helpful and less of what isn’t. Coaches and facilitates. Removes impediments. Sometimes called a change agent, the Team’s ambassador to the organization, or voice of common sense.
Scrum Team - all three roles together make up the Scrum Team. Sometimes called the whole team.
Selected Product Backlog - deprecated term for the subset of (by definition top priority) product backlog items that the Team reasonably believes it can complete during the sprint (often mistakenly called the sprint backlog). Today this is called the forecast.
Sequence - a unique ordering. First, second, third... The product backlog is sequenced.
Should - highly recommended. The Scrum Master should be present at the daily scrum. This is much stronger than optional. However, no activity in Scrum is cancelled due to the absence of the Scrum Master. See also Must.
Spillover - work that has been started but not completed by the end of the sprint. Contrary to popular belief, spillover does not automatically carry over into the next sprint. Excessive spillover is typically a symptom of over-commitment in sprint planning and/or multitasking in the team. Technical debt is a subtle form of spillover.
Sprint - a time-boxed period for completing work. A sprint consists of planning, doing and review, both of the results and of how the team worked. Maximum time-box is 30 days. 2 weeks is common. All forecast work should be done by the end of the sprint.
Sprint Backlog - the selected product backlog, enriched with a technical concept and a task planning. The Sprint backlog represents the team's concept for achieving the goal set during the first half of sprint planning. The plan is updated daily by the Team.
Sprint Contract - the agreement between Product Owner and Team at the beginning of a sprint: time (sprint duration), cost (team composition), quality (definition of done) and scope (selected product backlog). If the team should fail to deliver on any aspect, it should fail on scope.
Sprint Planning - addresses two questions: what and how. The meeting is divided in two halves, sometimes referred to as sprint planning 1 and sprint planning 2 for addressing these questions. While the Scrum Guide considers this to be one activity, many practitioners consider each half to be a separate event with its own time-box.
Sprint Planning 1 (SP1) - the Product Owner and the Development Team agree on what will be developed during this sprint. The Product Owner defines priorities, the Team estimates how much is doable. Both parties influence the final agreement: the forecast and the sprint goal.
Sprint Planning 2 (SP2) - the Development Team decides how to solve the problem accepted in SP1. The result is a technical concept and a task planning, often in the form of a task board.
Sprint Review - the Scrum Team meets with users and stakeholders to inspect and adapt the product, based on done functionality. They will review what has and has not been completed and reflect on how to change the product backlog before the next sprint planning. This event is for getting feedback about the product from the stakeholders, not for evaluating the team’s performance or whether individual backlog items are done.
Stoos - a movement for finding better ways of managing organizations, named for the gathering that took place in Stoos, Switzerland in 2012. Inspired by the agile movement, Stoos seeks to catalyze a lasting change in how businesses do business.
Story - term often used to refer to a product backlog item, even if not formulated as a user story. Can also refer to a medium sized backlog item (on the scale of epic >> story >> grain of sand).
Story Point (SP) - a widely used, though not universally used unit to gauge the size of a PBI relative to other PBIs, estimate the size of a project and monitor progress. Something like a kilometer for code, so you can use the math of distance, rate and time to monitor progress and estimate completion.
Task - the Team uses tasks to plan the work in the sprint. When all tasks associated with a story are completed, the story should be done. Typically, a task represents a goal for the day, or something smaller. Most coaches no longer recommend estimating tasks in hours.
Task Board - a visual representation of the work to be completed in the sprint. Typically, 4 columns, organized in swim lanes, per story: story, tasks waiting, tasks in progress, tasks done. Often supplemented with burn-down charts, impediments and other useful information. The task board belongs to the Development Team, not the Scrum Master, Product Owner or outside managers.
TDD Test Driven Development - also known as red-green-refactor. 1) write a failing unit test (red) 2) code a first draft to turn the test green, keeping all other tests green) 3) "refactor" to create an improved and final draft. TDD improves productivity by reducing misunderstood requirements, rework, and escaped errors.
Team - an older term for the Development Team. Because effective collaboration between Product Owner and Development Team is associated with high performance, Product Owner, Scrum Master and Development Team are now referred to as the "Scrum Team".
Technical debt - a consequence of poor engineering practices which make a program difficult to modify. Like financial debt, technical debt must be paid off or technical bankruptcy follows: throw the program away and write a new one.
Time-box - a constraint to prevent a complex situation from degenerating into chaos. All events in Scrum are time-boxed.
Undone work - can you release the product at the end of the sprint? If not, there is undone work. Typical examples include regression testing, usability testing, customer acceptance tests. The less undone work you have, the more predictable your release dates. See Spillover.
Unit tests - automated tests written by the Development Team to assure internal quality. Unit tests enable refactoring and provide an essential safety net, so that changes and fixes do not introduce new errors.
User story - a people-centered approach to defining requirements with a standardized form: as <some role or persona> i want <some value> so that I can achieve <some goal or purpose>. The word 'user' should never appear in a user story.
Velocity - a unit to gauge the speed of development and estimate the completion date of large projects. Usually expressed as story points per sprint.
WAP - widely adopted practice, often used together with Scrum, but not part of Scrum—you may do it or not if you feel it applies to you. Examples include story points, user stories, definition of ready.
Whole team - an XP term for the Scrum Team.
Work in progress, WIP - work that has started but has not yet been completed. Lots of WIP is associated with poor performance and inability to get things done. See Spillover.
Working agreement - an agreement among interested parties to enable more effective work. Working agreements are the basis for improvement in Scrum.
A contract manages some risks but not all of them. More importantly, the contract defines the playing rules, which in turn drive people's behavior. What would you like to have in a contract? Conditions that encourage behaviors that lead to project success.
The following thoughts are based on my own experience working both as a supplier and as a customer of external development services.
Artwork courtesy of Laura Quattri. Used by Permission
Good Product Ownership is EssentialAn effective Product Owner can dramatically reduce the risk of a project and increase your chances of success with your new product. A Product Owner is a decision-maker, so this almost always means the Product Owner has to work for the customer, not the supplier.
If you are contracting with an external supplier for software development, Scrum is a good choice for managing the process, if – and this is a big if – the customer supplies an effective Product Owner who engages and collaborates with the rest of the Scrum Team.
Learn to be a good Product Owner. Product Owner classes teach you how to manage the backlog, how to formulate and refine requirements, how to define and refine acceptance criteria, how to reduce the risk of the project, how to work with the team in the before, during and after each sprint. In short, it gives you the skills you need to lead a development project. Each Development Team's First Milestone
The first goal is to deliver reliably every sprint. If the Team can produce something that works and could be shipped every sprint, most risks go away. It is not about how much they deliver. It is about delivering in production quality something that could be shipped. It might take the Team a few sprints to be able to do this reliably, because it is not easy. This objective might be something you want to define in the contract.
Fixed-Price is easy to achieve, if...
I have worked quite happily for years with a phased development contract. The original contract was a fixed scope contract with cost ceiling, but as we worked together and built up the level of trust, the surrounding text just withered away. Trust, a bit of boilerplate, the sprint contract and a quarterly sign-off from top management worked quite nicely.
If the team can deliver reliably every sprint, and given that the cost per sprint is fixed, then you can predict both your release dates and the total cost months in advance. The scope is defined on route, so you don't know "exactly" what you are going to get. Too much pressure to deliver in a short time frame is usually counterproductive. How to get the right scope quickly“Money for nothing, changes for free” contracts can turn the advantages of the Scrum and Agile development processes into a competitive advantage.
By prioritizing and delivering business value incrementally, the chances of an outright failure are dramatically reduced. This advantage is passed on to the customer.
Furthermore, it’s a cooperative model, so it offers incentives to both parties to keep the costs down. The early cancellation clause rewards the higher productivity achieved with Scrum teams. On the down side, this clause feels a bit like a 'golden parachute' which may not be politically acceptable.
This contract might work with a cost ceiling although I would be wary of losing the cooperative relationship.
The contract form lays the important groundwork for a successful project. And the Agile Manifesto got it right: working with the customer is more important than the contract. Whatever you do, keep the customer relationship positive! Should you condition payment on the results of individual sprints?Should you pay the supplier more if the Team delivers more? And less if they deliver less? In general, I don't recommend it.
This approach encourages valuing quantity over quality. It encourages the Team to settle at a ,performance level that they can comfortably achieve. And if the Team does have a sprint that doesn’t produce any working functionality as a result, they may not be able to withstand the economic hardship it produces, especially if the loss is passed on to the individual members. Suggestions for a Scrum ContractScrum is modeled on successful patterns of product development. Based on my experience working on both sides of the agreement, I would suggest addressing the following points to ensure that Scrum works as intended: ScopeDefine the purpose and goals of the project, leave the details to the “sprint contract.”
Respect for the Sprint Contract: Unless the Product Owner exercises their authority to cancel a sprint, no changes to the goal or team composition during the sprint without agreement among all members of the Scrum Team. Roles
Product Owner, Scrum Master, and Development Team (collectively the “Scrum Team”) as defined by the Scrum Guide. Define who will serve in each role.
Product Owner: Provided by the customer. Having the supplier provide the Product Owner (“because no one on the customer side has the time or knowledge”) is extremely dysfunctional. Only the customer has decision-making authority.
Ensure the Product Owner’s authority as a decision maker in the project, including having the final say whether something is done and accepted; confirm that they have enough capacity to support the team; and are able to perform regular, extended visits to the supplier’s site. Extensive face to face collaboration between the Product Owner and the offshore Development Team is a success pattern.
Development Team Members: Provided by the supplier. The Development Team needs all the skills necessary to create a finished increment (a “feature team”) and does not take instructions from anybody but the Product Owner through the sprint planning process.
Scrum Master: Provided by the supplier. Having the customer provide the Scrum Master (“to maintain control”) is extremely dysfunctional. Who would protect the Development Team from an overzealous Product Owner or ensure that the Customer fulfills their responsibilities?
Chief Impediment Removal Officer: This role, which is not a role that Scrum defines, represents an independent communication channel between the Scrum Master and the customer. This person takes responsibility for resolving impediments that cannot be addressed by the Product Owner or the Scrum Master alone.
This is not about escalation. This is about ensuring that impediments get addressed and to prevent actual escalations. EventsSprint Reviews: Occur once per sprint and are attended by the Scrum Team and the stakeholders. It may be desirable to name key stakeholders who must also be present.
Deliverables: At least once per sprint, a potentially shippable product increment must be produced by the Team and made available to the customer. Nothing may be included in the product increment unless it is done according to the definition of done as defined by the Scrum Team.
Spending authorization: How much money may be spent over what period of time?
Termination: What to do if the team achieves a viable product before the budget is exhausted. What to do if the customer wishes to cancel or prolong the project. How much notice is required to cancel the development work?
Contracts are often about one party establishing control over the other party. What if two equal partners are collaborating on something together?
Photo Courtesy of AFGE – CC-BY-2.0
Desired BenefitJoin forces to achieve a goal that neither party could achieve alone without defining a hierarchy between the partners. StructureTwo partners invest in a product of joint interest. Money is unlikely to flow directly between the partners in the development phase, but each party must have a ROI, which may come from revenue sharing or just benefits from using the software. ScopeDefined to suit the needs of the partnership. RisksTwo of everything. Decision chains can get long. Rivalries can develop between the teams. Different models for extracting value from the product can lead to different priorities and differing willingness to invest. What happens if one of the partners doesn’t contribute as expected? TipsTreat the joint venture as a separate entity: One team, co-located, with development and product marketing/product owner role. Think realistically about friendly and not so friendly separation scenarios.
“Money for Nothing, Changes for Free” encourages both customers and suppliers to focus on value.
A key advantage of Scrum projects is that at least once per sprint you have something that could be shipped and no work in progress. You can change direction every sprint, and you can reevaluate whether the project is a good investment or if your money could be better spent elsewhere. Abrupt cancellation is risky for the supplier.
While the concept of an early-exit penalty is not new, Jeff Sutherland gave it a unique allure with his allusion to the Dire Straits hit. Desired BenefitIncentivize both customers and suppliers to focus on functionality that provides genuine value. StructureThis works with Agile software projects because there is little or no work in progress. After each Sprint, functionality is either complete or not started. Work is basically on a Time and Materials basis with a cost target, often with the intention that the project should not use up the entire project budget.
After a certain amount of functionality has been delivered, the customer may realize that enough business value has been realized and that further development is not necessary. At this time they can, thereforet cancel the project, in which case a cancellation fee equal to the remaining profit is due (“Money for nothing”). Or the customer can apply the resources to something else that will bring them more value (“Changes for free”). ScopeCan be changed. Planned but unimplemented features can be replaced with other backlog items of the same size. Additional features cost extra. Decision-MakingEncouraged within the Scrum team. Emphasizes the Product Owner’s focus on maximizing Return on Investment, i.e. not wasting money on features that bring little value. RiskShared. Both parties have an interest in completing the project early. The customer has lower costs; the supplier has a higher margin. This only works if the supplier really can deliver working functionality every sprint. TipIf the budget is exceeded, the rules of T&M, Fixed Profit or Cost Ceiling contracts can be applied. The Fixed Profit approach is more consistent with the goal of fostering a cooperative relationship.
Bonus and Penalty Clauses look good on paper but work better with things you can build out of concrete.
If you are building to a critical deadline, delays might not option. This approach assumes that extrinsic motivations work. If you incentivize people to deliver faster or penalize them to if they deliver late, then they will deliver faster, or so the theory goes.
Desired BenefitIncentivize the supplier to deliver faster. StructureThe supplier receives a bonus if the project completes early and pays a penalty if it arrives late. The amount of bonus or penalty is a function of the delay. Scope ChangesDifficult to accept because changes potentially impact the delivery date, which is surely not allowed. Risk
Does the customer have an incentive for early completion? The ROI arguments must be compelling and transparent. Otherwise, the customer could use a delaying strategy to lower the cost and exploit the penalty clauses to their advantage.
Is it more important to figure out the right thing or to build according to specifications? Get the wrong answer and you risk delivering a product that no one wants to use or buy. RelationshipCould be cooperative but might degenerate into indifferent if the customer does not truly need the result by the date agreed. TipThis works best if genuine economic factors encourage the customer to achieve the deadline as well. While this approach might be appropriate for projects like runways, where scope changes are not an issue, it does not work well in contexts that require creative thinking, like product development. See Daniel Pink’s work on motivation for an explanation of why.
An alternative approach to ensuring you have a product at the deadline is to have a potentially releasable product one month before the deadline, and another a month before that, and another a month before that, et cetera, all the way to the first sprint in the project.
The Scrum Team eliminates “delivery risk” by creating an integrated potentially shippable increment at least once per sprint. Even if it is not possible or desirable to actually deliver every sprint, creating the shippable increment ensures that you can deliver when you need to.
A Phased Development contract is similar to how venture capitalists work with start-ups. It keeps stakeholders in the loop while delegating most decisions to the product team.
Phased development is essentially a longer-term perspective on Time and Materials with Variable Scope and Cost Ceiling, especially if each phase is kept relatively short, e.g. three months or so.
Desired BenefitEnable decision-making within the project while maintaining control at the governance level over the costs. StructureFund quarterly releases and approve additional funds after each successful release. Scope ChangesNot explicitly defined by the model. Releases are in effect time-boxed. The knowledge that there will be another release next quarter makes it easier to accept postponing a feature to achieve the time box. RiskCustomer’s risk is limited to one quarter’s worth of development costs. RelationshipCooperative. Both the customer and the supplier have an incentive that each release be successful, so that additional funding will be approved. TipsVenture capitalists often work on this basis. A Release Train in SAFe could be handled this way. Phased Development represents a long-term view of Time and Materials with Variable Scope and Cost Ceiling. The budget is set and reviews on a quarterly basis. The Product Owner requests new budget from the governance level on a rolling basis, as the project goals are achieved.
I have worked quite happily under this model. We simply specified the Release goal, hourly rate and cost ceiling in the commercial contract. The customer provided the Product Owner. Everything else was determined in the sprint contracts.
This can be risky for the supplier, if the continuation doesn’t get approved, how much notice or compensation do you get? See Section 7.9, Money for Nothing, Changes for Free for a scenario with a softer landing.
For customers that aren't used to working with Scrum, this might feel like a leap of faith, because they don't know exactly what they will get in advance. But I believe this is a fairly pragmatic approach. Enabling the Team and Product Owner to make decisions about the product increases the likelihood of building the right product.
Desired Benefit: Enable decision making within the project while maintaining control over the costs.
Structure: Same as Time and Materials except a cost ceiling limits the financial risk of the customer.
Scope: Same as a Fixed Price, Fixed Scope project.
Decision-Making: Much more likely to be in the Scrum team, because decisions are made during the project about what functionality shall be included.
Risks: The budget will expire without achieving the necessary business value for the customer. Customer won’t get everything they asks for.
Relationship: Cooperative. The combination of limited budget and variable scope focuses both customer and vendor on achieving the desired business value within the available budget.
Tip: From experience, I would say this contract form mixes well with Scrum. The customer has control over each individual sprint. A constructive relationship means that even if problems develop on the way, the emotions are right to come to a mutually agreeable solution.
Sometimes I call this, “heads I win, tails you lose.” Any outcome that does exactly use all the budget results in less profit for the supplier.
Desired Benefit: Cap the risk of the customer, offer the possibility of cost savings (though not providing much incentive to either party to do so).
Structure: Same as Fixed price, Fixed scope, except if the vendor gets finished early the project costs less, because only actual effort is invoiced.
Scope and Decision-Making: Same as Fixed Price, Fixed Scope.
Risks: This appears to represent the ‘best of both worlds’ from the customer’s point of view. If it requires less effort than expected, it costs less. But once the cost ceiling has been achieved, it behaves like a fixed price project.
Relationship: Dependent. From the supplier’s point of view, the goal is to hit the cost ceiling exactly. There is no incentive for the supplier to deliver below the maximum budgeted cost. The customer has probably treated the project internally as a fixed price project, and so has little or no incentive to renounce scope to save money.
Sometimes I think this is the “holy grail” for consultants: Permission to work forever, predictable profits and all the risk carried by the customer. It also seems to be popular with large government contractors. Good work, if you can get it.
Desired Benefit: Achieve a goal when the problem is highly complex, not easily specifiable. Create a relationship to work together rather than merely deliver a particular result.
Structure: Work for a month, then send the customer an invoice. Suppliers like it, because the customer carries the risk of changing his mind.
Scope: Not a-priori fixed. Sooner or later, the customer doesn't want to pay any more, so the project comes to an end.
Risks: The financial and delivery risks are carried 100% by the client. Supplier has little incentive to keep costs down. Effort to ensure that only legitimate effort and expenses are invoiced can be substantial. Innovation in this context can be challenging, because competitive innovations are likely to be disruptive and may lead to the end of the relationship.
Relationship: Indifferent. The supplier is happy when more work comes, because more work means more money.
Tip: Recommended for projects where the customer can better manage the risk than the supplier. This is often combined with a cost ceiling. How well it works can depend on how the scope is handled.
This question has challenged the Agile community since the beginning: How do you do a fixed-price, fixed-scope project? Especially the big customers think they know exactly what they want, so their suppliers should be able to tell them exactly how long it will take and how much it will cost. In practice, neither of these beliefs are true.
Revenue is constant, regardless of the effort applied or actual delivery date.
Desired Benefit: Clarify all the questions so the purchasing decision can be made on price. Move the risk for time and budget overruns to the supplier.
Structure: Agree on the deliverables, deliver it. Send a bill. Customers like fixed price projects because it gives them security (or at least they think so).
Decision-Making: Generally, the customer's governance level decides on changes and on whether things are done. This approach works better for runways than for smartphones, because feedback cycles are usually relatively slow.
Scope changes: The name says it all, doesn't it? The change request game (correction: change request process) is intended to limit scope changes. This process is costly, and the changes are usually not preventable.
Risks: Obvious risk is on the side of the supplier. If the estimates are wrong, the project will lose money. A less obvious risk is the change request game, through which the supplier negotiates additional revenue through scope changes. If the supplier has badly underestimated the effort or risk, or quoted an unrealistically low price, the losses can even threaten the existence of the supplier, which also presents a problem to the customer.
Since the customer almost by definition wants more scope, ending the project can be difficult. The supplier wants the customer to be happy, so the supplier usually yields. The words ‘et cetera’ are very dangerous in the specification of a fixed price requirement.
If the supplier is not good at the change request game, the customer can milk the supplier until the supplier says, 'No more!'. This can risk the relationship with the customer.
The biggest risk is the impact of contracting for a runway when you are actually building a smartphone. Decision-making is slow and often far removed from the project team. The chances of arriving late with the wrong product are high, and this can have catastrophic consequences.
Relationship: Competitive to indifferent. Customers generally want to have more, and suppliers generally want to do less. The supplier wants the customer to be happy, so usually the supplier yields.
Tip: Specify the functional requirements with a user story or complete sentences that use active verbs, for example: “As a job hunter, I want to search for a job by location, so I can find a job close to where I live.” This makes it clear whether the backlog item has been achieved. You can do it, or you can’t. But it leaves negotiable how to achieve it. This gives you both important wiggle room to simplify the implementation and makes it easier to declare a new request to be out of scope.
Mike Cohn’s classic, Agile Planning and Estimating offers strategies for estimating and pricing these kinds of projects.