Or “Its in the Feature Acceptance Criteria!”

• Product Management
• Business Owners
• Epic Owners

Epics and Features become the new way to specify fixed scope that is required to be completed before it is considered “done”.

Many traditional organizations, has controlled work by specifying in detail plans of work. This is both:

1. A natural result of human nature in that there is a human bias to like what look like concrete plans because we (ie people) don't like ambiguity or unknowns (known as the “ambiguity effect”).
2. The result of traditional managerial thinking where if the plan went wrong, there was something wrong with the plan and the normal reaction is to take more time to plan. This ignores the fact that in today's world no amount of planning would have allowed us to foresee everything. As someone once said “Plans are useful; planning indispensable”.

Agile assumes that in many cases you cannot know everything up front and so it puts in place feedback loops so you can learn as you do the work. If you do not take advantage of these feedback loops you really are just wrapping a fixed scope mindset in an agile wrapper.

A fixed scope mindset results in a number of issues for an organization but they can be summarized as follows:

• The organization is unable to produce better business outcomes by taking advantage of new knowledge as they do the work, or as the business context changes. The result in sub-optimal business outcomes.
• By stressing the scope, there is no incentive to stop work. If we truly believe that value delivery responds to the pareto principle where 20% of the effort delivers 80% of the value, this is a significant waste of capacity - do 80% of the effort to produce the last (and lowest) 20% of the value? Even if it takes 50% of the effort to deliver 80% (because we learn as we go what is valuable) this is significant waste of capacity. This process of evaluating this trade-off is often called "trimming the tail".
• By stressing the scope, you do not encourage your knowledge workers to experiment, take risks, and learn. Since the outcome is pre-specified there is no upside for the individual to try something.

The result that your organization will be the opposite of “a learning organization optimized to deliver highest priority business value fastest.” Given this is often one of the main agile transformation, this does not bode well.

At every review point, demo, etc. (in other words, we have feedback loops in place) we should be asking ourselves whether in makes sense to stop working on something, continue working or change our direction - pivot or persevere. There are two questions that can help drive this discussion:

• “Have we met the intent of the epic / feature?”
• “Is there significant additional value to be obtained by continuing work on this epic / feature, or should we put our efforts somewhere else?”

In general there are a lot of ways this surfaces in an organization:

• Very detailed, almost task oriented epic / feature description and acceptance criteria. Many people use the agile constructs to create new (slightly slimmer) versions of the new scope document.
• Exclusively asking “Does this work meet the acceptance criteria?” or “Does this work meet the description?” Note this is not a bad question to ask but it should not be the only question. But be careful, this question leads to “check-box” type thinking where people don't take advantage of what they have learned and don't do an evaluation based on business priorities.
• Factor analysis questions such as “We targeted a $1M spend for this epic, but only spent $800K - why?”. Or the other way around targeted $800K but spent $1M. The first case makes no sense (we got something for nothing - win!). But the second case also doesn't make sense if we are constantly reevaluating whether we should pivot or persevere. Unless we can learn something, it is a wasted effort to do the analysis. I would argue that will not learn a lot we really only know this overrun is true with the benefit of hindsight (plans are put together when we know the least about the work we are about to do).

• Source: What Kinds of Problems Do you Typically See As The Organization Transforms to Agile / Lean?
• How Does the Agile Approach Allow Us to Deliver Early?