Flexible team members

Myth: Staff rotation helps teams learn
Variations:

• We choose the team members at the beginning of each Sprint
• Lots of 10-30% team members

Category: Development team myths
Danger: High

The basis of the myth

Some organizations transfer their classic Project organization into Scrum, where "resources" are allocated on the timeline based on presumed need. Others consider outdated HR mechanisms, such as staff rotation, a good way to bring fresh wind into a team.

Why is it a myth?

Scrum does not go well with the idea of "flexible team constellation". For example, the team should collaborate, and in order to collaborate, the team needs to have a good understanding of each other. Whenever a person leaves or a new person joins, the Working Agreements need to be reconsidered. Likewise, every person needs to reconsider their own role to maximize team success. This overhead destroys the delivery capability of the team. When done on a per-Sprint-basis, the predictability of the team goes to Zero: The team becomes ineffective.

Assumption #1: Teamwork does not take time
Probably the worst assumption causing people to decide for inconsistent staffing is ignorance of the cost of team formation. Teams need a few Sprints to stabilize. The faster the shift in staffing, the more likely the team will perform below their potential.

Assumption #2: Resources

You can easily take a monitor to a different desk, and you can just as easily install new software on a server. But people are not resources. People need to get familiar with their environment and people around them. This adjustment has tremendous impact on productivity. The cost of a change in staffing should be carefully considered.

Assumption #3: Expendability

Some managers still falsely assume that everyone is replacible, so they do exactly that: Replace people with others, in order to optimize utilization. Disregarding whether a person can easily be replaced, the problem is that "it costs more to add a person to a team than to remove a person from the team". The replacement affects the entire team.

Assumption #4: Timesharing

When team members are working only a fraction of their time for the team, we see two problems: Either, their work becomes queued while they are unavailable, resulting in partially-done work, or they equally get disrupted and disrupt the team. There's some numbers floating around that as the amount of projects a developer is engaged with exceeds 2, effectiveness quickly goes to Zero: Why have ineffective team members?

Consequences

Low performance

As teams rearrange, their performance takes a hit. Based on experience, the team's performance stabilizes after about 3-5 Sprints. Occasionally, onboarding will obliterate the team's delivery capability and reset it to Zero. Sometimes, this turns into the disease of rotating even faster, until nothing ever gets done any more. This is not the fault of the new team member, but a flaw in the system.

High cost

The reduced team performance directly translates into increased delivery costs. As cost-per-feature increases, the business case turns sour. Flexible teams are probably the easiest way to ruin an otherwise profitable venture.


Morale

Teams working as teams also have "team spirit". Continuously shifting people in and out of the team makes it difficult to build up morale. Potentially both the core team and the fluctuating members will be challenged to remain motivated for the team's vision when there is no constancy of purpose.

Remedies

Get over the ideas of project thinking and resource utilization.
Consider the total cost of the team, not just the cost-per-person. Factor in the long-term cost of change.
Make changes to the team constellation sparingly and consequently.
Communicate clearly why and when team constellations change.
Give the team time to stabilize.
Do not use management intervention to bring skills into the team. Trust them to acquire skills by any means necessary and only act on demand.

Unnecessary functions

Myth: We are agile now. We don't need Testers any more.
Variations:

• Testers = Business Analysts, SysOps, Project Managers ...

Follow-up myths:

• Cross-Functional developers

Category: Development team myths
Danger: High

The basis of the myth

The Scrum Guide clearly states that "Scrum recognizes no titles for Development Team members other than Developer", and some people who don't continue reading fail to understand that this does not mean "We fire everyone who doesn't code."
Without proper consulting when introducing Scrum, some organizations are tempted to do exactly that. Especially the inherent "hate" for project managers in the Scrum community drives even some veteran Scrum coaches/trainers to state that these should be removed as quickly as possible.
In some teams, we run into the problem that -especially testers- are disdained for being of little value.

Why is it a myth?

Continuing with the Scrum guide, it also reads, "Individual Development Team members may have specialized skills and areas of focus, but accountability belongs to the Development Team as a whole."
This pretty much means that the definition of "Developer" is different from how traditional organizations understand "development", i.e. "writing code".
A Scrum developer might be a specialist for test, coordination or analysis. The real issue here is whether they are taking special or team accountability: Scrum knows no individual accountability.


Assumption #1: Development = Coding
The smallest part of development is creating the code. Having the right focus, the right idea, the proper design, high quality and sustainability are all in the book. All these affect the success of development, and in Scrum, the team takes care of all of these. Scrum teams do a lot more than just coding.

Assumption #2: The developers can do it!

It's not like when you utter the words "Scrum", some magic happens and your coders instantaneously get all the skills your other members of the organization specialized in for years. They are still necessary. Do not remove necessary functions from your organization. Otherwise, you're setting up your team up for failure.

Consequences

2-class system

Some companies rush headlong into declassifying anyone who is not a "developer" as non-value-adding resource. Oh, this is so much of a mindset problem. You trained these people, you set up your organization to reward their specialization, and now you make it their problem that they did what used to be right for you: They are still as valuable members of your organization as before, but their role has changed. Again, just because someone does not write code, does not mean they are not a developer in the Scrum sense: How about teams that don't even create software?

Belief in magic

There are usually reasons why you used to have specialists. Having them work against each other, rather than collaborate, does not make sense. But don't believe that Scrum magically makes some people superheroes by stripping others of their hard-acquired skills and transferring it into others' head. Scrum doesn't work like that. The team needs to collaborate and learn how to use the skills of everyone for maximum benefit.

Remedies

When introducing Scrum, it does make sense to look at the list of activities which are needed to succeed in delivering working software. Rather than get everyone out of the coder's way, bring together a team where all those functions are covered.
This may actually mean that only a few people are doing work on the product code itself, and the majority chime in to do the right things right.

When you realize that coders are considered the only "real developers" for some reason, educate what a "developer" in Scrum actually is: Everyone who contributes to product success!

ad-hoc Planning

Myth: The Daily Scrum is when developers pick their tasks for the day

Variations:

• Daily Scrum is where planning happens

Category: Daily Scrum myths
Danger: Low

The basis of the myth

The Scrum guide says, "During the [Daily Scrum] meeting, the Development Team members explain: [...] What will I do today to help the Development Team meet the Sprint Goal?"

In some teams, developers will stand in front of the Story Board, and then spontaneously decide: "... hmm ... and today ... THIS one ...", deriving their behaviour from the Scrum Guide's direction to explain what to do today.

Why is it a myth?

This one is so close to truth that it could be true, but it's deceptively deviant.
Scrum does not say that developers should not have a plan until they come into the Daily, but that they should lay out their plan during the Daily, and adapt it where necessary. This ties right into the big bad dangerous overall myth "Agile people don't plan": Developers should be clear on their plan before discussing it, rather than winging it.

Assumption #1: Big Upfront Plan 
There is little harm done when the team has laid out a Big Upfront Plan of tasks during the Sprint Planning, except that developers cherry-pick tasks based on what they think is best, rather than work in priority order. It only becomes harmful when developers start completing tasks instead of delivering value.

Assumption #2: Scrum is short-sighted

Every developer should already have a clear idea on the next steps even before entering the Daily. The Daily Standup is not a breakpoint erasing history and opening a new page - it's actually intended to ensure everyone is still on the same page.

Assumption #3: Time-boxed planning is enough

Scrum suggests that the team has a clear plan for the day. Ad-hoc planning is OK when little planning is needed. But when necessary discussions get replaced with more or less random choices, the product success is endangered. The intended output of the Daily Scrum is a feasible, aligned plan for the next 24 hours. If more time is needed to create this plan, the unclarities should already have been discussed before the Daily.

Consequences

Lots of WIP

When developers cherry-pick their tasks rather than contributing to getting things Done, the Planning board will soon be cluttered with lots of started, unfinished stories. 

Unforseen impediments

When developers pick tasks without putting enough thought into them, the chance of failing the Daily Plan increases.


Postponing trouble

Developers often have an uncanny eye for spotting trouble, and when they simply pick tasks they think they can do until tomorrow, they tend to pick the ones with lowest risk first. The main risks of the Sprint are postponed.

Idle time

In some rare cases, developers will idle when they completed all of their tasks until the next Daily Scrum. That makes absolutely no sense: There is no reason to not do anything when the Sprint Goal is not met and there's work to do.

Remedies

Everyone on the team should be clear that Planning is not where you pick your tasks, but where you align your task plan with the rest of the team. An easy way to stop ad-hoc planning is to intercept developers before the Daily Standup and ask them what their plan is.

Keep an eye for Work in Progress. Put WIP limits on stories, not just on tasks. When a developer starts tasks on a new story while there are still open tasks for an existing story, scrutinize this decision.

If Daily Plans are considered an iron box (i.e., "I won't do anything I didn't state"), re-emphasize the agile principles of collaboration and technical excellence.

Reporting time!

Myth: The Daily is the team's status reporting meeting.
Variations:

• SM asks progress-related questions to individuals.
• Managers who need status updates can attend the Daily.

Follow-up myths:

• The Daily Scrum eliminates traditional progress reports

Category: Daily Scrum myths
Danger: Moderate

The basis of the myth

The Scrum guide says, "The Daily Scrum is held at the same time and place each day to reduce complexity. During the meeting, the Development Team members explain: * What did I do yesterday that helped the Development Team meet the Sprint Goal?" (and other questions)

Coming from a traditional project management perspective, people immediately equate this with a progress report.

Why is it a myth?

Daily Scrum has nothing to do with progress reporting. Especially not individual status reporting. And it's not the Scrum Master's responsibility to check on people. It's simply synchronization and (re-)planning.

Assumption #1: Activity status matters
Reports only help if an action is taken. The team autonomously decides on actions. Solutions are created by the self-organizing team and escalated when inevitable. "Activity status reports" are not a part of Scrum. They are un-necessary, because results are visible every few weeks.

Assumption #2: Daily Reports help

The team discusses the best course of action to reach the Sprint Goal. The Sprint Backlog is a good indicator of how close the team is to reaching this goal. And the Review is a great indicator of how well the goal was hit.
What reports should result in, is need for change. But this is the result of a Retrospective. So the Daily Scrum contributes nothing of relevance for management intervention.

Assumption #3: Utilization matters

The team should be collaborating. When a team member stays silent, this does not mean they did not do any work. We don't even want "activity statements" in the Daily. We want people to collaborate and discuss results, not how busy they are. There is absolutely no correlation between what a person says in the Daily Scrum and how much they do.

Consequences

Blather

When team members assume that they are being interrogated for performance, they will blather about how busy they are, but will not focus on the Sprint Goal. The entire Daily Scrum becomes a freak show rather than a goal-oriented meeting.

Me vs. Us

In the Daily Scrum, it's all about the Sprint Goal and how we, as a team, can reach it. "I" should not matter all that much. But when people feel that they need to prove what they contributed, "our" goal becomes irrelevant.

When the Daily Scrum is abused as a Reporting ceremony, it becomes pointless.

Remedies

The Scrum Master must clearly educate the team that Daily Scrum is not reporting, and how its character is different from traditional reporting.
The Scrum Master should definitely refrain from interrogating individuals, but rather provide the leeway for team members to speak only about what they feel comfortable with.

If managers eavesdrop on the Daily Scrum to "measure progress", they need to be educated on more valuable progress assessment opportunities, such as Sprint Reviews and Backlog status.

Should line managers abuse the Daily Scrum to check on individuals, the Scrum Master needs to educate them on the destructiveness of this behaviour. If this abuse does not stop, the manager must be invited out to enable a productive Daily Scrum.

Standup!

Myth: It's called "Daily Standup" for a reason!
Variations:

• No sitting or leaning.

Follow-up myths:

• No electronics

Category: Daily Scrum myths
Danger: Low

The basis of the myth

The "Standup meeting" is a classic management tool to keep meetings short, because people don't like to stand for long times. Because the Daily Scrum is supposed to be short, this one has carried over.

Why is it a myth?

The idea of a "Standup" neither originates from Scrum, nor does it belong into Scrum.
The Scrum Guide only states, "The Daily Scrum is a 15-minute time-boxed event for the Development Team to synchronize activities and create a plan for the next 24 hours." The term "Standup" is nowhere mentioned in the Scrum guide.
Scrum is not prescriptive about how this event is conducted - only about intended results, scope and timebox.


Assumption #1: Physical fitness
For a person of normal health, 15 minutes of standing is no issue - it's even good for blood circulation. But what about people with special needs? It's not called "Standup" for the very reason that Scrum does not exclude people who can't stand up.

Assumption #2: Spatial proximity

It's not even necessary for the team to gather in proximity, only to be together. This is a big issue for distributed teams, who can also use Scrum (albeit with the standard issues distribution causes). Remote team members are usually forced to use electronics just to participate.

Consequences

Standups actually can induce psychological pressure and discomfort. If this is what you're looking for, fine - otherwise: Why?

Remedies

When your team can stand up, that's good. It's healthy. If they can't, well - no problem. If they don't want to, look for the root cause rather than fixing the symptom.

When you want to add specific constraints or methods to the Daily Scrum, ask the team.

For example, "Why should we stand up?", "What difference does it make?"

Team Time!

Myth: The Daily Scrum is exclusively for the developers
Variations:

• The Product Owner must not attend
• Outsiders must not attend
• "Chickens" don't speak

Category: Daily Scrum myths
Danger: Moderate

The basis of the myth

The Scrum guide states, "The Scrum Master enforces the rule that only Development Team members participate in the Daily Scrum."
The simple word "participate", which indicates "take an active part" is sometimes confused with "attend".

Why is it a myth?

The myth is that the Daily Scrum is some kind of protected, high confidence environment where nobody except developers are welcome. The idea behind the Daily Scrum is that it's a highly efficient, focused, short meeting.
The rule that "only Development Team members participate" exists because non-developers may not understand what developers do. When others cause distraction that impedes the synchronization and planning, they overstep their welcome. But they are welcome.


Assumption #1: PO can not contribute
It's not necessary, but sometimes, the Product Owner has information that will help the Developers reach their Sprint Goal. Even though the Daily is not the meeting to share this information in detail, the Product Owner needs to inform the team that there is information which may affect their next planning steps.

Assumption #2: "Chickens" don't contribute

Derailing the Daily Standup by asking questions is not welcome, but if an outsider has information that is absolutely relevant for plan currently being created by the developers, at least they should be aware that this plan would deprecate before the meeting ends.

Consequences

Ineffective Planning

When the team makes a plan that is wrong, and someone can help the team move in the right direction, that person should be heard. Purposefully ignoring available information is very un-agile and has nothing to do with Scrum.

Morale effect

When outsiders who have important information are told by the Scrum Master to withhold this information, they will. This may demoralize those who can help the team, weakening overarching collaboration. 

Extra meetings

When outsiders (e.g., members from other teams) are "invited out" for no reason, then extra meetings for synchronizing with these people will be required. Silent attendance should always be welcome.

Remedies

The Daily Scrum should enable synchronization and collaborative planning. Any person who does not distract from these goals may be welcome, because this increases transparency, understanding and trust.

The Scrum Master should not be hasty to hush up or invite others out, but rather spend time educating/coaching them regarding their effect on the meeting. 

At best, the Daily Scrum could be a kind of "fish bowl" meeting where the entire stage belongs to the team, while others draw all the necessary information they can. This can eliminate huge amounts of otherwise needed coordination meetings that would otherwise draw capacities from the team.

Estimate ALL the items!

Myth: All items on the Product Backlog need to be estimated
Variations:

• Upfront estimation
• Estimates are required for the PO to prioritize the backlog based on ROI
• An estimated Product Backlog is required for a Release forecast

Follow-up myths:

• Re-estimate frequently

Category: Backlog myths
Danger: Low

The basis of the myth

The Scrum guide says, "Product Backlog items have the attributes of a description, order, estimate and value."
Traditional project managers creating an upfront Work Breakdown Structure are used to attaching estimates to each piece of work early on in order to produce the Project Plan. So, the entire idea that the Product Backlog should be completely estimated upfront is a mix of project thinking and

Why is it a myth?

Again, read further: "Product Backlog refinement is the act of adding detail, estimates, and order to items in the Product Backlog. This is an ongoing process ..." - it's completely fine to add estimates at a later time. This, of course, means that it's completely fine if there are backlog items without estimate!

Assumption #1: All items will be delivered

Why do we need estimates about items that we will not deliver? Only when we are sure that an item will ever be delivered, it's estimate will be important. In turn, until we know that it will be delivered, the estimate is not important.

Assumption #2: There's value in the estimate
Estimation takes time. To justify investing this time, the estimate needs to have value. So, we assume that the generated estimate will actually be used for something. Estimate that deprecate before being used are waste.

Assumption #3: We need upfront information

A Product Backlog tends to consist of items that will be done in the near future and items that will not be done in the next few Sprints. How does the estimate about items that won't be worked on affect the plan?

Assumption #4: We know what we're up to

As the product develops over time, the basis on which a new feature is built also changes over time. Let's use this image: When you are standing on the beach, it will be difficult to estimate a skyscraper. Once you've built 20 houses of varying size, it will be much easier to estimate that skyscraper. Until we know enough about our product, many estimates are just haphazard guesswork.

Consequences

Tedium

Combined with a huge backlog, upfront estimation turns into a long, tedious meeting. As developers start to feel tired, they'll be very complacent in the estimation, reducing the accompanying discussion and thereby the accuracy of the estimate. After half a day of estimation, you might as well roll dice: Your estimates will be good for nothing.

Guesswork

Based on assumption #4, the accuracy of early estimates will be very low. How does a a probably-just-plain-wrong estimate actually add value? How likely is a plan based on guesswork better than a plan made without details?

Extra effort

When estimates are made way ahead of time, the backlog items will need additional attributes, such as "When was the estimate done, how likely is re-estimation needed" etc., adding extra effort with no value. Again, CRUFT increases, leading to a viscious circle consuming an ever-increasing amount of precious, limited time.

Re-Estimation

When estimates are outdated because of new information, they need to be re-estimated. However, this means that the original estimate had no impact on the final product: The previous estimate is waste. The more often we discover that an estimate becomes outdated, the more wasteful our estimation approach is.

Remedies

Question, "What do we need the estimates for?" and limit effort to the need.

Create awareness in the team and organization that new information invalidates previous estimates, and so the value of future estimates quickly approaches 0.

Keep "Just in Time" in mind for estimation as well. A Release spanning more than 3-4 Sprints is most likely subject to many changes, so do not even feel pressured to estimate every item for the Release. Create a crude approximation for the Release scope, a better approximation for the Sprint - and simply forget about the future until you get there.

Refinement may be used to estimate items that will be coming up in the next 1 or 2 Sprints to create a better Sprint Plan if estimates are needed and still missing.

Until you know whether an item will even be realized, do not waste time estimating it.

Personal status update

Myth: During the Daily Scrum, every developer answers the "Three Questions"

Follow-up myths:

• Daily Scrum exposes developers who don't contribute

Category: Daily Scrum myths
Danger: High

The basis of the myth

The Scrum Guide states, "During the [Daily Scrum] meeting, the Development Team members explain:
What did I do yesterday that helped the Development Team meet the Sprint Goal?
What will I do today to help the Development Team meet the Sprint Goal?
Do I see any impediment that prevents me or the Development Team from meeting the Sprint Goal?"

This is then re-interpreted as "Each developer must individually answer these questions". It also ties nicely with project status reporting, which is very easy to transfer into the Daily Scrum.

Why is it a myth?

As long as you have individuals working on individual items, the Three Questions are very similar to each team member giving an update based on the Three Questions. As soon as collaboration increases, team members already know what others did, and the answer to question 1 becomes redundant. When developers use techniques such as Pair Programming, the repetition of "Yeah, I was working with Joe on ..." also provides a level of redundance.
The Daily Scrum is not the mandatory point when this information should be conveyed, but the latest sensible point for this. Any information that is already available to the team is redundant during the Daily.
Lastly, the purpose of the Daily Scrum is not to answer questions (it's not an interrogation session), but to synchronize and plan the upcoming 24 hours.


Assumption #1: We're not really a team
When we really have teamwork, what is the benefit of them stating what they did during the Daily Scrum? Being part of a team should imply that others already know what each team member was doing, how far they got and where the problems rest.

Assumption #2: We work on many things

When we collaborate on one thing, it's really difficult not to know what is going on. Only when we distribute the work, we need to sync. As long as Daily Scrum helps me find out what my team is doing, we may have issues with scatter or transparency. Daily Scrum does not resolve these impediments, it only reduces the damage they case.

Assumption #3: It ain't obvious

The Daily Scrum nowhere states that the team should state the (freaking bloody) obvious. It only limits running out of sync. When things are not obvious, we should work on transparency, alignment and focus. As these aspects improve, the amount of communication about every individual's work decreases.

Consequences

The biggest problem of the "Three Questions" Daily Scrum meeting is when there are hints that people are working individually, and not as a team. When the "Three Questions" actually seem to reward having individual contribution over collaboration, the Daily Scrum turns from a synchronization meeting into a scattering meeting, a merit report or - even worse, a bashing or pressuring session.

Remedies

The Daily Scrum is good to synchronize, focus and create clarity on the next steps.

The Scrum Master should observe for problematic patterns such as team members "reporting in" or many different topics being discussed.
When people feel the need to "make up" something so that they have something to speak, the reasons for this should be analyzed,
When developers are more concerned about their own Three Sentences than about really synchronizing, the Scrum Master should step in and challenge the benefits obtained from the meeting.

If outsiders attend the Daily Scrum and use the obtained information to evaluate individuals, the Scrum Master should invite them out.

Comprehensive Backlog

Myth: All known future work must be recorded in the Product Backlog
Variations:

• A Product Plan and a Backlog are pretty much the same.
• Upfront backlog creation
• Static Product Backlog
• Before we start development, we need a complete Product Backlog

Follow-up myths:

• Estimate ALL the items!

Category: General Scrum myths
Danger: Moderate

The basis of the myth

This stems from classic project thinking. The idea is that it is possible to know upfront exactly what the final product will look like. Projects and their tenders are typically defined with a fixed scope upfront. This is simply projected into agile development. Project managers turned into product owner or project teams turned Scrum team without clear understanding of the new way of working will simply turn their Project Plan into a Backlog 1:1.

Why is it a myth?

The Scrum guide literally states, "The Product Backlog is an ordered list of everything that might be needed in the product ..." - which is then interpreted as "comprehensive". But, read further. It also states the following: "A Product Backlog is never complete. The earliest development of it only lays out the initially known and best-understood requirements. The Product Backlog evolves as the product and the environment in which it will be used evolves. The Product Backlog is dynamic; it constantly changes to identify what the product needs to be appropriate, competitive, and useful."


Assumption #1: Scope is fixed.
How often is that true? Classic projects always have a "Change Management" process, where changes to original scope are negotiated, usually with an impact to cost or delivery date. Wasteful meetings are introduced to renegotiate these things in order to stay in TQB, leeching capacity without providing any customer value. Feedback learning implies that the Backlog can't be comprehensive.

Assumption #2: We know what is wanted & how it's wanted
There is also a connection to the Sprint Review: The Review is a feedback cycle to inspect+adapt the product development, therefore the Backlog. Any output from the Review is an input into the Backlog and will result in changes to the Backlog. A Review with no output is dysfunctional.

Assumption #3: The world doesn't turn

Comprehensive backlogs assume that new information has no influence on the backlog. Not only learning, but also changes to the world around us will impact existing backlog items. For example, a feature X is no longer relevant, because customers already have another product for that - or we need integration with new product Y on the market to create optimal value for our product. All of these will affect the product.

Assumption #4: Long lists are workable

Having a comprehensive backlog means that the backlog will be very long. However, as the size of a list increases, the amount of coordination effort to keep it updated increases. For example, keeping a list of 10 items in order just requires a few minutes.
When we permit 1 second per decision, a backlog with 500 items would take roughly 10 days to fully arrange just once, much less keep up to date. When would the PO spend time with customers or the team? The backlog will become untidy and lose it's value.

Assumption #5: Devil-may-care
Project thinking typically implies that a shipment goes out on a specific date X, and then our responsibility ends. A comprehensive backlog stems from exactly that kind of thinking: "It's done when everything is finished". When a team has responsibility not only to meet some arbitrary deadline, but to make a product successful, there is no definite end date.
As soon as the customer has something in their hand, they need something else. Updates are required to keep an ongoing cash flow. The amount of updates required to maintain an infinite cash flow are infinite, and this would imply that a "comprehensive backlog" would need to be infinite.

Consequences

Waste

With increasing size of the backlog, CRUFT increases. Basically, CRUFT is a measurement of how much % of a given document is waste. This means that increasing backlog size reduces the value of the Backlog. A comprehensive backlog most likely has extremely high CRUFT, so it induces tremendous waste to the Product Owner and development team.

Mindset

A comprehensive backlog will quickly turn sour when an important customer need is not reflected in a backlog item. The "change request" battle continues, which is in stark contrast to the Agile Principle of Welcome change.

Mood

When the backlog is comprehensive, stakeholders finding their items on the bottom of the backlog will become dissatisfied and may exercise pressure on the team. This, in turn, will dissatisfy the developers and the mood turns sour. 

Lost opportunities

Comprehensive backlogs are not intended to evolve. The accompanying reluctance to change makes it difficult for the teams to maximize customer value, and therefore, business opportunities.

Remedies

Capping
The simplest remedy is a backlog size cap. For example, when a team can deliver 5 PBI's per Sprint, a cap of 50 provides nearly half a year of planning horizon. Any item that won't be done within half a year is probably not important enough to warrant any further consideration. When a newly added item would break the cap, an item that is less important than the new item will be discarded.

Filtering
Backlog items should fall into one of the three categories: "Coming soon" (and be refined to put into one of the next Sprints), "On the horizon" (no further effort invested at this time) and "Scrap" (ain't nobody got no time fo' that). Category 3 should be removed from the backlog.

Mindset change

Both Product Owner and other stakeholders need to be aware that having fewer items in the Product Backlog actually increases the chance that something which is currently not in the Backlog will be delivered in the future.

Team members should understand that the backlog purposefully limits the planning horizon to increase focus on what is and will be worked on. The Scrum master should help the team realize the benefits of this increased focus by spending more time on things that are actually important.

Acceptance Criteria

Myth: The PO must document the Acceptance Criteria(AC) for each Story.
Variations:

• The team can reject taking a Story if the AC are not defined
• The PO is responsible for defining the AC
• ...

Follow-up myths:

• ...

Category: General Scrum myths
Danger: Moderate

The basis of the myth

Acceptance Criteria are derived from the Scrum Guide, without being specifically mentioned. What is mentioned is only this:

Those performing the work and those accepting the work product must share a common definition of “Done”

Explicit Acceptance Criteria increase transparency and align expectations, so they are a good idea for most teams.

Why is it a myth?

The first part of the myth is that AC's are mandatory parts of Scrum, the second is that they somehow are PO domain. But there are a lot of hidden assumptions that hold explosive potential:

Assumption #1: The Requirement Manager
A Product Owner in Scrum is responsible for making sure that the team delivers the most valuable product. In traditional organizations, this is often the responsibility of a "Requirements manager" who not only dictates the "What", but also the "How". This concept simply does not transfer to Scrum. Maintaining it creates a culture where teams don't take ownership of the delivery.

Assumption #2: Single Point of Failure (SPOF)

A Product Owner (should) know what the customer needs, but that doesn't mean the developers don't. The Agile Manifesto encourages continuous dialogue between developers and Customers, so developers should also have a clear understanding of customer needs. Holding the PO personally responsible for providing a comprehensive list of Acceptance Criteria turns the PO into a Single Point of Failure, and a bottleneck.

Assumption #3: Big Upfront Design (BUFD)

Comprehensive lists of Acceptance Criteria assume that before the Sprint starts, significant work has been invested into defining details of the solution. Not only does this assume that analysis happens before the Sprint, it also assumes the PO is Chief Analyst - a concept highly incompatible with their definition in Scrum!

Consequences

Hidden Waterfall

When developers assume that someone other than they has responsibility for ensuring success before they even start working, this hints of a Waterfall mindset and an absolution of responsibility. 

Lost Opportunities

Business value can only be maximized through continuous Inspect+Adapt. By presuming that Acceptance Criteria can be comprehensively defined early in the process, the team is undermining both continuous feedback and adaption.

Capacity Waste

The Product Owner is already struggling to allocate their limited time with maximum value for the Scrum team. Holding the PO responsible for detailed Acceptance Criteria forces the PO to drop other, potentially significantly more important activities, such as acquiring funding or managing stakeholders.

Design constraints

Acceptance Criteria typically require a certain understanding of how the solution will be designed. This might even create technical constraints on a level the PO is unaware of. Predefined Acceptance Criteria might force the team to create suboptimal solutions.

Remedies

Detailed Acceptance Criteria help to provide clarity and align expectations. They solve the problem of Product Owners not being happy with the solutions provided by the team. A better solution is to continuously engage the Product Owner in dialog throughout the Sprint.

At some point, they need to be defined - usually no later than the creation of Acceptance Tests, which are part of sustainable development. Since AT's are development domain, the people with the most skill at defining useful AC's are usually developers, anyways. If they don't know how to do that, they need some training.

Rather than train the PO in providing "better AC's", the team needs to learn to have the right conversations. Take heed of which necessary conversations are not happening and adjust there.

Story Point Estimation!

Myth: In Scrum, we estimate with Story Points only.
Variations:

• If you don't use Story Points, it's not Scrum
• Hour/Day estimates are evil
• We can't tell you how much it costs
• We can't tell you when it's done

Follow-up myths:

• Scrum does not permit budgeting
• Scrum doesn't let us forecast a release date
• Scrum doesn't let us define a release date

Category: General Scrum myths
Danger: High

The basis of the myth

One of the first things we learn in most Scrum trainings is: "We don't want to plan in Man-days, because that doesn't work out anyways." Tools like Planning Poker or Magic Estimation are then introduced to fill the gap, and "Story Points" are offered as an alternative. In some cases, trainers even go into great depths to explain why we use Fibonacci numbers for estimation.

New Scrum practitioners are often left with the impression that the use of "Story Points" is prescriptive in Scrum and that Man-Day or Cost estimates are against Scrum.

Why is it a myth?

As we already discussed, User Stories are not part of Scrum - and neither is "Story Point Estimation", which is clearly related to Stories.
Let's take a look at what the Scrum Guide actually says:

"The Product Backlog lists all features, functions, requirements, enhancements, and fixes that constitute the changes to be made to the product in future releases. Product Backlog items have the attributes of a description, order, estimate and value." - and, in another section: "The work done on them depreciates quickly and must be frequently re-estimated"

From a Scrum perspective, the backlog should be estimated - there are no prescriptions as to how this estimation is done.
The entire argument is a "straw man fallacy" relying on a lot of assumptions that are not related to Scrum.


Assumption #1: No effort estimation
Classic project effort estimation would define upper limits for individual tasks, such as Analysis, Development and Testing (and then suffering from Parkinson's Law). This usually results in unwanted behaviours, such as risk aversion and obfuscation.
Agile estimation tries to capture uncertainty and risk involved in the delivery of backlog items to lay them out early. It purposefully does not provide upper capacity limits. Instead, the key purpose of estimation is to provide a ballpark figure on whether something is feasible and sufficiently valuable to work on.

Assumption #2: The point of estimation is to plan delivery

No, it isn't. The entire purpose of the estimation process in an agile setting is risk management. Part of this risk management is exposing these risks and seeking solutions. The actual, estimated number may be considered merely a side benefit.

Assumption #3: We don't know how long it takes

The classic reason brought up against man-day estimation is that when facing the Unknown, nobody can know how long it will take. However, that's a key point of estimation: To know whether we're going out on a limb, taking a leap of faith, or doing something fairly reliable. We do accept that we can be wrong, and we're not in it for the best estimate. But here are a few statements we should be able to make about backlog items after estimation:

• Will it fit into one Sprint?
• If it does, will it fill the entire Sprint or take only a portion?
• If not: why do we think so?
• Can we extract something that does fit into a Sprint?

So, we do actually know "how long it takes". What we don't know yet, however, is "when it will be priority 1" - and consequently, "when it will be delivered". But if it were our priority 1, we should be able to tell pretty well how long it takes.

And once the team has completed some Sprints, they can even get a gut feeling on whether they can do 1, 5 or 20 items, so these kinds of statements even become more accurate over time.

Assumption #4: No relationship between cost and Story Points

Sometimes, you hear teams stating that due to Story Point Estimation, they have no way of giving you a cost indicator. But it's possible: Just like above, we know approximately how much capacity we'll sink into this. We also know how many people are on the team and how much each person costs us per Sprint. So, we can do some math:

Sprint Cost = (Team Size * Daily Cost per person + Daily Infrastructure Cost) * Days in Sprint 

Item Cost Estimate = (Estimate/Velocity) * Sprint Cost

While we probably can't tell whether it's going to cost $1750 or $1800, we can definitely tell you whether it's more likely to cost $5k or $500k. And low estimates mean we're closer to a lower figure, while a high estimates indicate a cost that's going through the roof.

Consequences

Unnecessary conflict

Especially in existing organizations, people are often used to estimates in hours/days. Some have even become quite adept at them. There is no need to provoke conflict with a functioning process.
"Story Point Estimation" is merely an alternative to deal with some common dysfunctions.

Business uncertainty

Business needs some kind of predictability. Even the most stout defender of Story Point Estimation wants to know how much their lunch costs and whether it'll be delivered before midnight. Business needs some degree of understanding on where the money is going, whether something is actually "worth it" and how to plan stuff such as marketing campaigns.

Anti-Collabortion

Refusal or inability to provide business relevant information will create an impression that developers are being unhelpful, completely against the collaborative spirit of agility. Story Points are not an excuse to not give business what they need.

Wrong mindset

Agile software development is intended as a means of reducing uncertainty fast and effectively. It is not intended as an excuse to avoid solvable problems. When Story Points are used as a "get out of jail free" card in the Scrum team, they are also being abused. Their intention is to provide leeway in face of uncertainty, not to create an uncertainty leeway.

Insistence on "Story Points Only" destroys agility and trust!

Remedies

Story points are not inherently bad. They only become dangerous when they turn into a "cannot" or "must not". If used in that fashion, they will quickly become a tool that will be used to bludgeon the team.

Every estimation technique and unit is acceptable, but any occurring dysfunctions need to be dealt with. When Story Points themselves become dysfunctional, go back to the root of which problems the team has to solve.

Before picking a way of estimation, create awareness of the following:

1. Who needs the estimates?
2. What are they being used for?
3. How can we provide to all who need some estimation, what they need.
4. There is no such thing as a "correct estimate".
5. The main purpose of estimation is to address risk early.
6. The value is in the conversation, not in the number.

Velocity

Myth: Velocity is a measure of a team's performance
Variations:

• Velocity should be constant
• Velocity should increase over time

Follow-up myths:

• Always know your team's velocity
• Velocity-based planning

Category: General Scrum myths
Danger: Moderate

The basis of the myth

Velocity is being propagated by many Scrum trainers and in the Scrum literature, Even scruminc by Jeff Sutherland promotes Velocity as "the Key Metric in Scrum", albeit not being part of the Scrum Guide.
Velocity is considered as the "amount of Story Points a team gets Done in a Sprint". From this, teams often derive things like "Average Velocity" as the average velocity of the last 3-5 Sprints as capacity limit for planning.

Why is it a myth?

Not even a concept remotely resembling Velocity, much less all kinds of artifacts surrounding Velocity (such as Burndown charts) are core Scrum. This doesn't mean they are bad ideas. They just aren't necessary. But in some cases, Velocity can turn sour.


Assumption #1: The team uses Story Points
Before you can even use Velocity as commonly understood, you first need Story Point Estimation. If you're not doing that, Velocity won't make any sense. For example, when the team estimates in ideal hours: Their Velocity will be constant and irrelevant, because a day's a day's a day.

Assumption #2: Velocity means something

That's basically assuming that Story Points mean something. Story Points are merely estimates - and estimates can always be off. When the estimate was wrong, the Velocity is wrong.

Assumption #3: Apples, Oranges and jellyfish
The very point of relative estimation is that estimates are nonlinear. Try replacing "Planning Poker numbers" ... with Apples for small, Orange for medium and jellyfish for large items: If your can eat 5 Oranges plus 2 Apples, then how many jellyfish can you eat? 

Consequences

In itself, Velocity poses no problem. It just becomes problematic when it's being used for other things. Such as:

Plans based on average fail 50% of the time!

 Just because last time, it worked doesn't mean it'll work again. When estimates are just a crude reflection of what the team knows at the time of planning, chances are that next time, the situation is different. And that can go both ways. A Product Owner is well advised not to rely on historic velocity for planning the future.

Performance monitoring

While Velocity tracking can help the team discover dysfunctions, managers often get tempted to use velocity against the team. When teams get punished for not maintaining velocity, then the metric gets gamed to pointlessness.
Even the seemingly positive reward for increasing velocity can induce highly destructive behaviours.

Remedies

Velocity is just a tool to reduce uncertainty and reduce the complexity of planning with little overhead.
Just like it's not worth "producing better estimates", nobody should feel pressured to precisely meet (or exceed) historic velocity. The PO can use Velocity as a crude benchmark for release planning or feature cost, but needs to understand that this ballpark figure is not reliable.

Managers need to be educated to keep their fingers off Velocity for good.

When Velocity figures are abused, the Velocity system should be abandoned by changing the estimation system to apples, oranges and jellyfish, for example.

Scrumfall

Myth: Scrumfall is Scrum
Variations:

• We can just slice a Waterfall project into portions and use Scrum
• We're doing Scrum in the Analysis, Design, Development and/or Test teams
• Developers use Scrum after they get a Detailed Design Document

Follow-up myths:

• Scrum Project Manager
• Scrum Team Lead

Category: General Scrum myths
Danger: High

The basis of the myth

This myth clearly originates from people who might have a superficial understanding of Scrum, but who are still stuck in a Waterfall mindset. It pops up when people have not "read the book" or received proper training and are trying to figure out the least disruptive way to "do Agile".

The statement reveals a lack of awareness that the reason why agility works differently is because ... well, people work differently.

Why is it a myth?

Long story short - the Scrum guide makes no statement about the exact scope of the team.
The Scrum Guide merely states:

The team model in Scrum is designed to optimize flexibility, creativity, and productivity.

Assumption #1: Silo organization is the best
As long as people assume that silo organization is the best way of organizing teams, the idea is that "designed to optimize" requires silo structures. This assumption is simply wrong, because silos result in the wastes of overproduction, handover, miscommunication and local optimization.
The silo organization needs to be broken to put everyone together in one team who can contribute to the solution.

Assumption #2: The Waterfall project organization works

When your waterfall works, that's great! Why would you even want to do things differently, when what you do works?
Unfortunately, in most companies - and with increasing likelihood as project sizes increase - the waterfall does not work! What exactly do you expect to be different when keeping the dysfunctions?

Assumption #3: Scrum brings the benefits

Scrum is mostly concerned with structure: Structuring the work, structuring the team, structuring the delivery. Consequently setting up a new structure is required for proper Scrum. However, as the Scrum guide states that Scrum merely creates an environment where "people can address complex adaptive problems". The benefits start to come when these problems get addressed - and Scrum doesn't do it for you!

Usually, problems are endemic to preserved Waterfall structures and will persist until these are abandoned.

Assumption #4: The only problem is that teams are not doing Scrum
No. It's not. What would make you think that everything is fine, except which meetings team members attend? Scrum will not do anything when it is considered as a way for developers to organize themselves better.
The key success factor of Scrum is relentless impediment removal, and most impediments affect developers - not are caused by them! While you can remove impediments without applying Scrum, Scrum without this form of impediment removal is completely ineffective.

Consequences

Pointless change

As Craig Larman postulates, "any change initiative will be reduced to redefining or overloading the new terminology to mean basically the same as status quo." - when the waterfall is kept and Scrum is introduced, Scrum will be a hollow shell, devoid of it's original intention.

In this setting, people will think they understood Scrum and claim "Scrum does not work". Scrum becomes "burnt soil".

Unsolved problems

The key benefit of Scrum's idea behind cross-functional team is to have people collaborating on problem solving, rather than shoving the problem over the fence. While people continue working with shutters, blame games and fingerpointing continue. Ineffective capacity utilization remains. The problems resulting in slow progress and low quality persist.

No value gain

Agility relies on adaption. Adapt the process where it doesn't work, and adapt the product plan where it doesn't work. This adaption relies on effective, real-time feedback. Waterfall organizations assume that "when the plan didn't work, it was the fault of the plan - next time make a better plan!" Agility abandons this premise, understanding that as the world changes in real time, prediction with certainty is impossible. Waterfall structures insist on working off plans. Scrum's agile foundations rely on reaching realistic goals. The value is gained when the goal is attained, not when an obsolete plan is fulfilled.

Scrumfall is a non-agile shell resulting in superficial change without significant benefits.

Remedies

Start questioning assumptions. For every element of waterfall that you're trying to keep, ask yourself "Why are we doing this?", even to the point where it gets nauseating.
Start asking "What problem are we trying to solve?", seriously question how Scrum is supposed to help with that.
Create clarity on the differences between status quo and "problem solved". Track impediments induced by the Waterfall.
Expose wishful thinking by management ("Developers must do ... to reach ...") and move towards realistic, inclusive planning where everyone gets a say.
Address fingerpointing ("We did this, but they didn't that") or quota-matching (e.g., "Coding done", "Test Complete with Defects") in the organization.

Create awareness with practical examples that nobody can know the future, and that Waterfall's biggest caveat is the assumption that the future can be anticipated!

User Story Template

Myth: User Stories have to be written in the form "As a ... I want ... so that ...!"
Variations:

• Team members need to learn how to evaluate what a "good user story" is and give the PO feedback "how to write better stories".

Follow-up myths:

• Story-Writing workshop

Category: Backlog myths
Danger: Low

The basis of the myth

The Connextra Template was created by a team from the company Connextra in 2001 to get more clarity of purpose, need and audience in their development process. It was simple and effective, so it caught on.

Why is it a myth?

Well ... as User Stories are not part of Scrum, neither is a prescriptive format for them.
But there are a few more misunderstandings behind it:

Misunderstanding #1: Need to identify the customer
The "as a ..." portion is only relevant when the customer is unknown. When we know that Marc, our sysadmin, requested something, why should I write "As a sysadmin I want to ..."? We know Marc, he's in daily communication with us and he knows he wanted this stuff. Especially when it's a stuff like "modify user account", we already know whom it's for. Only when it's vague or unclear, do we need to write who our customer is.

That doesn't mean you shouldn't invest time finding out who the customer is. But don't waste time to state the bleeding obvious.

Misunderstanding #2: Need to identify the request

The "I want ..." portion, too, is only relevant when the need is unknown. When everyone on the team knows we got a freaking memory leak, why should we write "I want a stable memory utilization" or whatever - why not just go with "Fix memory leak"?

Misunderstanding #3: Need to identify the objective What else can you do wrong except also restating the bleeding obvious when the objective is clear to everyone? "Lost emails" should be telling. Why waste time stating "so that I can read the information that was sent to me by mail"?
The Connextra template is a great tool to remove uncertainty by asking systematic questions. It can be really useful during Refinement to bring clarity into the Unknown. But it's quite pointless where transparency exists.

Consequences

Applying the Connextra template brute-force is a good way to train your team in asking the right questions.
The template helps when the team exhibits a tendency of implementing features that nobody uses, either because they don't help anyone or because they don't do what they should.

But after a while, this turns into tiresome routine and the value of doing this is lost in the mist.

Remedies

Relieve your Product Owner from filling in boring templates.

Abolish any kind of "user story template" you might have.

Use the Connextra Template as a Thinking tool. During Refinement, ask developers if they know who wants what, why.

User Stories

Myth: The Product Backlog consists (exclusively) of User Stories
Variations:

• We need to find ways to formulate everything as a user story
• Fake Story Users

Follow-up myths:

• Technical User Story
• Developer Story
• User Personae
• Every item must be written in the Connextra Template
• The PO must learn to write proper User Stories
• It matters how well written a User Story is

Category: Backlog myths
Danger: High

The basis of the myth

It's actually difficult to pinpoint where the myth originated, but it's really wide spread.
Many people, including trainers and coaches, propagate the idea that you need to work with "User Stories".

Why is it a myth?

The Scrum guide doesn't even mention "User Stories". It only talks about "Product Backlog items". (PBI's). Even then, a PBI can be "everything that might be needed in the product". There is no specific hint to "users" or format. According to the Scrum rules, it's completely fine to dump a Detailed Specification Document or a sketch doodle into the Product Backlog.

The only constraint on a PBI is that when the team decides to work with it, it's "ready" - whatever that means in your team!

Assumption #1: Mandatory Format
The problem with any kind of mandatory format is that the formatting process consumes capacity - which may or may not be a valuable investment. Most certainly, it's not a valuable investment when we don't even know yet whether we are even going to build the stuff!


Assumption #2: It's all about users

Scrum nowhere prescribes that we only work on stuff that is relevant for a "user". Let's take, for example, a technical interface refactoring: That thing has no "users" aside from machines and it's a complete waste of time to think how to phrase a mandatory technical change from a user perspective. "As a customer, I want the system to convert the XML data I send to the system into JSON" - No! No, no. This is wrong on so many levels ... While the customer does care that their data gets processed, what's happening here something that the customer couldn't care less about.
Can you imagine Old Aunt Irma sitting in her rocking chair, telling you "Sweetie, I want my XML data processing to be converted to JSON?" - well, if you can't - then you know that this is not a real user story!


Assumption #3: Clarity 
Do "user stories" add clarity? Well - maybe. But only if they're real stories told by real users. And even then, they might actually obfuscate matters. Let's just think of "My computer doesn't work": That's a real user story. Even "Oh, I didn't realize that I didn't turn it on" is part of that story.
Now, you could rewrite this as "As a user, I want to be reminded when my computer is not turned on so that I remember to turn it on." - but is that really the thing you're going to work on?
Wouldn't "Power switch unintuitive", adding the real user's statements as details, be even clearer for developers?
In this case, a "user story format" is actually masking the activity and intended outcome by rewriting this stuff from an end user perspective.

Consequences

Waste

Teams and/or Product Owners investing time to turn stuff that's already clear into so-called "User Storys" is waste of time and effort. The purpose of refinement is to clarify PBI's in a way that will enable good planning, not to brute-force a standard that may or may not be applicable.

Artificial restriction

A "user story" is actually not something created by the Product Owner, but real needs of real people. The reason for "user story" vs. "requirement" is this: We want to move away from prescriptive, inefficient solution proposals created by people with limited understanding of existing capabilities and constraints. Storytelling enables teams to move towards an open solution space, from which technically excellent developers can pick the optimal approach to meet the real user need.

Wrong focus

"User stories only" can result in valuable work being omitted or delayed because no "user" can be found, or simply: Because nobody has an idea how to rephrase the need into something that matters to users. Teams should not exclusively focus on users, but also on creating a sustainable, valuable product. Instead of looking for ways to shoehorn a description for needed change into an unsuitable format, teams should learn to communicate technical activities so that all parties understand why they need to be prioritized.

No discussion

The worst part about "User Storys in the Backlog" is a kind of not-my-job thinking. The Product Owner has to turn requests into workable "user stories" before the team will work on them. The core idea behind a "user story" is a discussion happening between those who have a need (user) and those who can help (the team).
The intention is dialog, the backlog item should merely be a reminder of a discussion that either has happened or still has to happen.


By moving a backlog to a "User Story Backlog", we induce waste and create a wrong mindset. Once the wrong mindset is established, we've managed to simply re-label traditional Requirement Engineering, devoiding agility of it's core benefits.

Remedies

Team members need to understand that the format of backlog items is actually irrelevant as long as they have a clear understanding what is needed why.

The Product Owner needs to understand that "user stories" are good where they help, and useless otherwise. The PO's job is not to make sure everything is written as a user story, but to ensure that the most valuable things are done first.

When talking about User Stories, the Scrum Master needs to emphasize that the point of stories is dialog, not form.

Educate everyone that it's completely acceptable to use whatever kind of label and form for backlog items that are helpful to understanding.

Resist the urge to re-label "feature requests" or "requirements", simply accept that you get these things. Examine why you work with these things rather than with real people having real needs.

Move the developers away from being request executors towards becoming innovators, then the form will become irrelevant.

The Contract Game.

Myth: Product Owner vs. Developers

Variations:

• The PO wants more than the team can do
• The team refuses to do as much as the PO needs

Follow-up myths:

• During Planning, the team haggles the scope with the PO 
• "Scope Commitment"

Category: Planning myths
Danger: High

The basis of the myth

The Scrum guide states the following things about planning:

• The Product Owner discusses the objective that the Sprint should achieve and the Product Backlog items that, if completed in the Sprint, would achieve the Sprint Goal.
• The number of items selected from the Product Backlog for the Sprint is solely up to the Development Team. 

In general, the Scrum guide adds this statement about the Product Owner:

• [The Product Owner is responsible for] Optimizing the value of the work the Development Team performs

This is then misconstrued as: "The Product Owner says how much the team should do, then the development team says how much they can do.", then stretched even further out of proportion: "Planning is a bargaining session where the Product Owner haggles with the team about the amount of work to be done.". In

Why is it a myth?

The myth is created from a misconception about Scrum teams and the Product Owner role.

First, the Scrum team includes the Product Owner as well as the developers. Planning is a collaborative exercise of the Scrum team. In a functional team, people pull in the same direction. The Product Owner should not even consider pulling in the opposite direction.

The second basic misconception is that the Product Owner negotiates work. The developers own the work, while the PO owns the goals. The developers are experts of the "how much", the PO is the expert of "what".

Negotiations can and do take place in a functioning Scrum team, but more along the lines of priorities, that is "Well, if we can't do both A and B, we should get A done first", or "Well, if A, B and C is too much work, maybe we can reduce the scope of A, so that at least we can see something from C"

Assumption #1: Capacity is negotiable

After a while, teams should understand their capacity. Taking more work than capacity results in unsustainable development. Either, people need to make overtime or they will take dangerous shortcuts, such as hidden quality reduction - often a combination of both. Typically the first things disappearing under overload are innovation and continuous improvement.

In the absence of good data about the team's capacity, it is acceptable to experiment with capacity. However, when capacity is known, the Product Owner needs to accept reality.

Capacity is fixed. The team can merely organize how the capacity is being used. Loading more work than capacity onto the team falls into the category of Wishful Thinking, a massive organizational waste.

Assumption #2: Give 100%

Even when less than 100% of the team capacity is utilized for development of new features, there is still a capacity limit.
Planning for 100% capacity utilization is very dangerous, because the slightest deviation from plan will result in failure. The proverb "Plans based on average fail on average" comes to mind.

In general, no more than 80% of capacity should be allocated for the Sprint Goal, because the team will be spending capacity on the following:

• Refining topics for the subsequent sprints
• Innovation
• Technical housekeeping, e.g. Refactoring, data purifications etc.

There are even reasons why teams should plan for lower numbers. For example, unplannable customer requests or "flu season" are very good reasons not to plan for high utilization in terms of Sprint goals.

Depending on the level of legacy technical debt resulting in defects or customer complaints, teams might even be hard pressed to allocate even 50%.

Rather than trying to push the capacity allocated towards the Sprint Goal, the Product Owner should strive to understand what impedes the team from allocating a higher percentage.

Assumption #3: Lazy Developers

"Theory X" thinking suggests that developers need to be pushed to diligence. "Theory Y" thinking, on the other hand, suggests that motivated people do their best. When a Product Owner observes that developers do not care about the product's (and therefore, their own) success, it would be a good time to hold a Retrospective and use the Scrum Master's facilitation skills to discover what demotivates the developers and how to improve their conditions: Why would they not want to do work they can do, if that work is sufficiently meaningful?

Consequences

Us-vs-Them Mentality
Once people start to feel cheated or pressured, trust within the team is broken. Collaboration turns into defensive CYA behaviour. Productivity declines even further, to the point where neither the PO will get any useful results, nor the developers see any meaningful progress in their work. Both will blame the other, when they should act as one party with a shared interest.

Wrong focus
While the focus in planning should be what is the best way to deliver the most value, planning becomes an interrogation session shifting towards how people work. Instead of focusing solutions, impediments are turned into excuses. Developers will think of good reasons for doing less rather than smart ideas how to do more. The Product Owner will look at what people are doing rather than at what the product can do.


"Contract based planning", where the Product Owner tries to maximize capacity load and the team tries to minimize overburden has failed. It might be better not to plan at all than to plan anticollaboratively.

Remedies

The longer the "Contract game" continues, the lower productivity will be. If the "Contract mindset" is not broken, the team may become completely dysfunctional.

As Scrum Master or coach, have a keen eye for questions or remarks hinting at haggling going on.

Actively intervene when discussions turn from solutions to excuses.

Stop the "contract game". Educate everyone that the purpose of planning is to come up with a collaborative plan for the upcoming Sprint, not to discuss how people work.

Direct a Retrospective towards examining capacity utilization. Create transparency why certain things take as long as they do.

Observe team morale and ensure team members are able to do meaningful work that allows them to achieve Drive: Autonomy-Mastery-Purpose.