Scope Creep and agility?

"Scope Creep" is every project developer's nightmare. Best case, it only means overtime. Worst case, it means a lot of unpaid overtime, additional meetings, frustrated customers, angry managers and burnout. In any case - not a fun place to be in. But it's a relic from the traditional world of projects - is it?

No. Scope creep can also occur in agile contexts - and it's even more likely than in traditional projects because there are more interactions with stakeholders. But first, let's define "scope creep:"

A developer feeding the Scope Creep in its natural habitat. Image by: AI (picsart.com)

Defining Scope Creep

Let's turn to the Project Management Institute, as they have defined it best:

Scope creep - Adding additional features or functions of a new product, requirements, or work that is not authorized (i.e., beyond the agreed-upon scope)

Project Management Institute (PMI)

Now, what does that mean within an agile context - and how can we deal with it better than in traditional projects?

With every stakeholder interaction, we gain new insights - and so do they. Mutual understanding evolves together with the product. And each time we interact, what we knew yesterday could be invalid today. That's a great opportunity - but also a danger. Especially when we have a tight schedule and/or budget, this evolution can quickly get out of hand and go beyond our limits.

Confining Scope Creep

We have five critical instruments for dealing with scope creep easily and effectively. In combination, they reduce the risks, stress factors, and the negative associations that come with scope creep:

• Visualize anything that's being worked on,
• Agree as a team on what we take into the product, and
• Simplify with the YAGNI principle, i.e., don't build anything that's not needed.
• Limit yourself to a single demand intake channel, creating a controlled, well-managed process that prevents work flowing in from the side.
• Inspect and adapt frequently, validating that we're still in line with what's agreed upon among stakeholders.

Do's and Don'ts

To create the best product with the highest possible value while keeping scope creep at bay:

• DO pursue newly arising opportunities,
• DO capture stakeholder feedback and insights,
• DO address user problems surfacing in our current solution,
• DO consider improvement suggestions that might require rework,
• DON'T let stakeholders haphazardly drop "urgent requests" or "better ideas" onto developer's desks. These options need to be validated and prioritized against other work first,
• DON'T engage in "prioradditization." Anything added must replace or be prioritized against existing work, and there's always an opportunity cost,
• DON'T play favorites. Neither charisma nor positional power mean that an idea is good or valuable,
• DON'T pursue pet projects that may as well be "YAGNI" themselves. Initiatives without significant value don't deserve capacity, and also
• DON'T tolerate "submarines" that avoid agreements, or bypass the demand intake channel. This makes scope creep exactly as bad as we remember from the worst projects.

Closing remarks

Use the five instruments provided. Heed the Do's and Don'ts, but take it easy. "Scope Creep" always means that someone isn't getting what they want, at least not now, so there's going to be a conflict to defuse, and that's where being relaxed, respectful and open-minded come in very handy. With these tips, I hope that you can confine scope creep and avoid the negative consequences associated with it.

Planning with Capacity Buffers

I get asked quite often some questions along the line, "How do we deal with work that's not related to the Sprint Goal?" The typical agile advice is that all work is part of the Product Backlog and treated as such and the work planned for the Sprint is part of the Sprint Goal.

In general, I would not recommend this as a default approach. I often advise the use of Planning Buffers.

Where does the time go?

Teams working in established organizations on legacy systems often find that the amount of work which doesn't advance the product makes up a significant portion of their time. Consequently, when they show up in a Sprint Review, the results tend to go into one of two directions: 

Either, the team will have focused on new development, angering existing users why nobody tackled known problems - or, the team will have focused on improving legacy quality - angering sponsor why the team is making so little progress. Well, there's a middle ground: angering everyone equally. 

In any case, this is not a winning proposition, and it's also bad for decision making.

Create transparency

A core tenet of knowledge work is transparency. That which isn't made explicit, is invisible.

This isn't much of an issue when we're talking about 2-5% of the team member's capacity. Nobody notices, because that's just standard deviation.

It becomes a major issue when it affects major portions of the work, from like a quarter upwards of a team's capacity. 

Eventually, someone will start asking questions about team performance, and the team, despite doing their best, will end up in the defense. That is evitable by being transparent early on.

Avoid: Backlog clutter

Many teams resort to putting placeholders into their backlog, like "Bugfix", "Retest", "Maintenance" and assigning a more or less haphazard number of Story Points to these items.

As the Sprint progresses, they will then either replace these placeholders with real items which represent the actual work being done - or worse: they'll just put everything under that item's umbrella.

Neither of these is a good idea, because arguably, one can ask how the team would trust in a plan containing items they know nothing about. And once the team can't trust it ... why would anyone else?

Avoid: Estimation madness

Another common, yet dangerous, practice, is to estimate these placeholder items, then re-estimate them at the end of the Sprint and use that as a baseline for the next Sprit.  

Not only is such a practice a waste of time - it creates an extremely dangerous illusion of control. Just imagine that you've been estimating your bugfixing effort for the last 5 Sprints after each Sprint, and each estimate looks, in the books, as if it was 100% accurate. 

And then, all of a sudden you encounter a major oomph: you're not meeting up to your Sprint Forecast, and management asks what's going on. Now try to explain why your current Sprint was completely mis-planned. 

So then, if you're neither supposed to add clutter tickets, nor to estimate the Unknowable - then what's the alternative?

Introduce Capacity Buffers

Once you've been working on a product for a while, you know which kinds of activities make up your day. I will just take these as an example: New feature development, Maintenance & Support, fixing bugs reported from UAT - and working on other projects.

I'm not saying that I advocate these are good ways to plan your day, just saying if this is your reality - accept it!

We can then allocate a rough budget of time (and therefore, of our develoment expenses) to each activity.

An example buffer allocation

Thus, we can use these buffers as a baseline for planning:

Buffer Planning

Product Owners can easily allocate capacity limits based on each buffer. 

For example, 10% working on other projects, 25% UAT bugfixing and 25% maintenance work, which leaves 40% for development of new features. 

This activity is extremely simple, and it's a business decision which requires absolutely no knowledge at all about how much work is really required or what that work is.

In our example, this would leave the team to plan their Sprint forecast on new feature development with 40% of their existing capacity.

As a side remark: every single buffer will drain your team's capacity severely, and each additional buffer makes it worse. A team operating on 3 or more buffers is almost incapacitated already.

These things are called "buffer" for a reason: we prefer to not use them, but we plan on having to use them. 

Sprint & PI Planning with Buffers

During the planning session, we entirely ignore the buffers, and all buffered work, because there is nothing we can do about it. We don't estimate our buffers, and we don't put anything into the Sprint Backlog in its place. We only consider the buffer as a "black box" that drains team capacity. So, if under perfect circumstances, we would be able to do 5 Backlog items in a week, our 60% allocated buffer would indicate that we can only manage 2 items.

Since we do, however, know that we have buffer, we can plan further top value, prioritized backlog items that do contribute to our team's goal, but we would plan them in a way that their planned completion would work out even when we need to consume our entire buffer.

So, for example: if our Team Goal would be met after 5 backlog items, we could announce a completion date in 3 Sprints, since our buffers indicate that we're most likely not going to make it in 1 Sprint.

Enabling management decisions

At the same time, management learns that this team isn't going at full speed, and intervention may be required to increase the team's velocity. It also creates transparency how much "bad money" we have to spend, without placing blame on anyone. It's just work that needs to be done, due to the processes and systems we have in place.

If management would like "more bang for the buck", they have some levers to pull: invest into a new technology system that's easier to maintain, drive sustainability, or get rid of parallel work. None of these are team decisions, and all of them require people outside the team to make a call.

Buffer Management

The prime directive of activity buffers is to eliminate them.

First things first, these kinds of buffer allocations make a problem transparent - they're not a solution! As such, the prime directive of activity buffers is to eliminate them. and the first step to that is shrinking them. Unfortunately, this typically requires additional, predictable, work done by the team, which should then find its way into the Product Backlog to be appropriately prioritized.

Buffers and the Constraint

If you're a proponent of the Theory of Constraints, you will realize that the Capacity buffers proposed in this article have little relationship to the Constraint. Technically, we only need to think about capacity buffers in terms of the Constraint. This means that if for example, testing is our Constraint, Application Maintenance doesn't even require a buffer - because the efforts thereof will not affect testing!

This, however, reuires you to understand and actively manage your Constraint, so it's an advanced exercise - not recommended for beginners.

Consuming buffers

As soon as any activity related to the buffer becomes known, we add it to the Sprint Backlog. We do not estimate it. We just work it off, and keep track of how much time we're spending on it. Until we break the buffer limit, there is no problem. We're fine. 

We don't "re-allocate" buffers to other work. For example, we don't shift maintenance into bugfixing or feature delivery into maintenance. Instead, we leave buffer un-consumed and always do the highest priority work, aiming to not consume a buffer at all.

Buffer breach

If a single buffer is breached, we need to have a discussion whether our team's goal is still realistic. While this would usually be the case in case of multiple buffers, there are also cases where buffers are already tight and the first breach is a sufficiently clear warning sign.

Buffer breaches need to be discussed with the entire team, that is, including the Product Owner. If the team's goal is shot, that should be communicated early.

Buffer sizing

As a first measure, we should try to find buffer sizes that are adequate, both from a business and technical perspective. Our buffers should not be so big that we have no capacity left for development, and they shouldn't be so small that we can't live up to our own commitment to quality.

Our first choice of buffers will be guesswork, and we can quickly adjust the sizing based on historic data. A simple question in the Retrospective, "Were buffers too small or big?" would suffice.

Buffer causes

Like mentioned above, buffers make a problem visible, they aren't a solution! And buffers themselves are a problem, because they steal the team's performance!

Both teams and management should align on the total impact of a buffer and discuss whether these buffers are acceptable, sensible or desirable. These discussions could go any direction.

DevOps teams operating highly experimental technology have good reasons to plan large maintenance buffers. 

Large buffers allocated to "other work" indicate an institutional problem, and need to be dealt with on a management level.

Rework buffers, and bugfixing is a kind of rework, indicate technical debt. I have seen teams spend upwards of 70% of their capacity on rework - and that indicates a technology which is probably better to decommission than to pursue.

Buffer elimination

The primary objective of buffer management is to eliminate the buffers, Since buffers tend to be imposed upon the team by their environment, it's imperative to provide transparent feedback to the environment about the root cause and impact of these buffers.

Some buffers can be eliminated with something as simple as a decision, whereas others will take significant investments of time and money to eliminate. For such buffers, it tends to be a good idea to set reduction goals.

For example, reducing "bugfixing" in our case above from 25% to 10% by improving the system's quality would increase the team's delivery capacity from 40% to 55% - we nearly double the team's performance by cutting down on the need for bugfixing - which creates an easy-to-understand, measurable business case!

Now, let me talk some numbers to conclude this article.

The case against buffers

Imagine you have a team whose salary and other expenses are $20000 per Sprint.

A 10% buffer (the minimum at which I'd advise using them) would mean not only that you're spending $2000 on buffers, but also that you're only getting $18000 worth of new product for every $20k spent!

Now, let's take a look at the case of a typical team progressing from a Legacy Project to Agile Development:

Twice the work ...

Your team has 50% buffers. That means, you're spending $10k per Sprint on things that don't increase your company's value - plus it means your team is delivering value at half the rate they could! 

Developers working without buffers, would be spending $20k to build (at least) $20k in equity, while your team would be spending $20k to build $10k in equity. That means, you would have to work twice as hard to deliver as positive business case!

Every percent of buffer you can eliminate reduces the stress on development teams, while increasing shareholder equity proprtionally!

And now let's make that extreme. 

Fatal buffers

Once your buffer is in the area of 75% or higher, you're killing yourself!

Such a team is only able to deliver a quarter of the value they would need to deliver in order to build equity!

 

In such a scenario, tasking one team with 100% buffer work, and setting up another team to de-commission the entire technical garbage you're dealing with is probably better for the business than writing a single additional line of code in the current system.

Please note again: the problem isn't the capacity buffer. The problem is your process and technology! 

High Performance: No Buffers

High Performance teams do not tolerate any capacity buffers to drain their productivity, and they eliminate all routine activity that stops them from pursuing their higher-ordered goal of maximizing business value creation. As such, the optimal Capacity buffer size is Zero.

Use buffers on your journey to high performance, to start the right discussion about "Why" you're seeing the need for buffers, and the be ruthless in bulldozing your way to get rid of them.

The value of idle time

The Product Backlog is a mandatory part of Scrum. Together with the Sprint Backlog, they define both the planned and upcoming work of the team.

There's a common assumption that it's considered good to have a decently sized product backlog, and as many items in the Sprint Backlog as the team has capacity to deliver. Let's examine this assumption by looking at a specific event.

The "no backlog" event

It was Tuesday evening. I had just a busy day behind me.
I was chilling, browsing the Web, when I received a message on LinkedIn. The following conversation ensued:

Mind Lukasz' last statement: "The most impressive customer service ever".
Why was this possible?

Had Lukasz contacted me half an hour earlier, this dialogue would never have happened. Why? Because I would have been busy, doing some other work. Lukasz would have had to wait. His request would have become part of my backlog.

Service Classes

There's a lot of work I am pushing ahead of me on a day-to-day basis.
But I classify my work into three categories:

1. Client related work - I try to cap the amount of client related work, to maintain a sustainable pace.
   It's a pretty stuffed backlog where things fall off the corners every day.
2. Spontaneous stuff - I do this stuff as fast as I see it, because I feel like doing it.
   The hidden constraint is that "as I see it" depends on me not being engaged in the other two types, because these take 100% of my attention.
3. Learning and Improvement - That's what I do most of the time when not doing Project work.
   I consider web content creation an intrinsic part of my own learning journey.

These categories would be called "service classes" in Kanban.
I am quite strict in separating these three classes, and prioritize class 1 work over everything else.

Without knowing, Lukasz hit my service class 2 - and during a time when I was indeed idle.
Since class 1 has no managed backlog, I got around to Lukasz' request right as it popped up, and hence, the epic dialogue ensued.

Service Classes in Scrum

If you think of the average Enterprise Scrum team, class 1 is planned during Sprint Planning, and class 2 activities are undesirable: all the work must be transparent in the Sprint Backlog, and the SBL should not be modified without consent of the team, especially not if this might impact the Sprint Goal.

Many Scrum teams spend 100% of their workload on class 1, going at an unsustainable pace, because the constantly descoped class 3 work warrants future-proofing the work.
Even if they plan for a certain amount of class 3 work, that is usually the first thing thrown overboard when there's pressure to deliver.

The importance of Spontaneity

Few Scrum teams take care of Class 2 work, and Scrum theory would dictate that it should be placed in the Product Backlog. This just so happens to be the reason why Scrum often feels like drudgery and developers are getting uncomfortable with practices like Pair Programming.

"Spontaneous stuff" is a way to relax the mind, it helps sustain motivation and being totally uncommitted on outcomes allows creativity to flourish.

Load versus Idle Time

As mentioned, class 1 is bulk work. As workload increases, the percent amount of class 1 activity quickly approaches 100%. Taking care of class 3 activity means that increasing load quickly diminishes idle time activity to go to Zero.

Since I already mentioned that idle time activity creates magic moments, both for team members and customers, high load with zero idle time destroys the "magic" of a team.

Wait Time Idleness

One source of Idle Time is Process Wait Time.
In a Lean culture, wait is seen as detrimental waste. This is both true and false. It is true when the organization doesn't create value during wait, while incurring costs. It is false when this wait is used to generate "magic moments".

Buffer Time Idleness

Both Scrum and Lean-Kanban approaches encourage eliminating idle time, as would the common "agile Scaling" frameworks. Team members are constantly encouraged to pull the next item. or help others get work in progress done faster.
This efficiency-minded paradigm only makes sense if the team controls the end-to-end performance of the process, otherwise they might just accumulate additional waste. Theory of Constraints comes to mind.

On the other hand, buffer removal in combination with a full backlog disenchants the team - there will be no more "magic moments": Everything is just plan, do, check, act.

Idle Time and Throughput

The flawed assumption that I want to address is that buffer elimination, cross-functionality and responsibility sharing would improve throughput. Maybe these will increase output, but this output will be subject to the full lead time of any other activity.

Backlogs vs. Idle Time

Genuine idle time means that the input backlog currently has a size of Zero and a parallel WIP of Zero as well. There is no queue: neither work-in-progress nor work-to-do.
An idle system doesn't require queue management. When idling, throughput for the next request is exactly equal to work time - the maximum throughput speed we could hope to achieve. This kind of throughput speed can look absolutely mind-boggling in comparison to normal activity cycle times.

The impact on organizational design

A perfect organization takes advantage of idle time points that maximize throughput speed - not efficient utilization avoiding idle time.

Summary

The conversation with Lukasz is an example of the benefits of having idle time in your work.
This kind of idle time allows for "magic moments" from a customer perspective.

Just imagine an organization where "magic moments" are the norm, and not the exception.
This requires you to actively shape demand: when demand is roughly equal to capacity, we can eliminate backlogs.
Demand queues destroy the magic.

Eliminate the queues. Make magic happen.

Classifying value by importance

As Product Owner, your responsibility is to order the Product Backlog by Value.

This may be really difficult when you're dealing with many different stakeholders who all consider their own few backlog items to be of utmost importance.

This simple model can guide your questions:

Three Importance Dimensions

The three dimensions Need, Want and Lack are all gradual - yet, for simplicity purposes, we'll just simplify them as "Strong" (inside the dotted circle), "Relevant" (within the dimension circle, but outside the dotted circle) and "Weak" (outside the dimension's circle). We'll leave it up to common sense how to interpret these terms. 

As a nuance, you can rank-order them by proximity to the center.

How strong is the need?

Based on Maslow's Hierarchy of Needs, some features meet existential needs, others provide comfort or enjoyment. Arguably, you need to be in a pretty comfortable positon to value convenience.

Key questions
Which basic needs gets addressed?
What happens when no solution is provided?
Will there be loss of life, damage, squandered opportunity or merely inconvenience?

The bigger the need, the closer you would move to the center inersection.

How wanted is the feature?

Many features are highly wanted for a really short time, but like a snowflake, the demand melts off as fast as it appeared.

Key questions
Is the request just a spontaneous idea?
Has it been thoroughly pondered?
How much would you be willing to sacrifice to get it?

When customers are unwilling to sacrifice anything, not even a single cent, then it's not wanted - and if they'd sacrifice everything else get it, then it's really wanted.

How big is the lack?

Supply creates its own demand, but scarcity rules price.
As the old joke goes, a great salesman could sell sand in the desert - but that would be an utter waste of sales talent.

Key questions
How is the situation currently addressed?
Is a feasible solution already available?

How much better would that which we could provide be than status quo?

The more plentiful and cheaper available alternatives are, the smaller the lack - and the more costly an alternative is, the bigger the lack.

Ordering the backlog

The position of these items in our diagram can then be used to determine how we would arrange our backlog:

1. Items in the central intersect of the diagram have highest importance and should come first. In this case, the exact order might be determined by other factors, such as WSJF or feasiblity.
2. Items in dual intersects within the dotted circle will end up near the top of the backlog.
3. Items in dual intersects outside the dotted circle will end up somewhere in the middle of the backlog.
4. Items which are only in one circle can be deferred and moved to the bottom of the backlog.
5. Items placed outside all circles warrant no further consideration and can be safely discarded.

Standard relevance

"But ... what about items with relevant need, lack and want, where neither is strong? They fit nowhere in the diagram"

Yes, the model doesn't really allow you to place them properly.
Just ignore the "Want" dimension and put them into a suitable dual intersect. It doesn't matter - because these items won't be on the top of the backlog, and the exact order of backlog items that won't be touched within the next couple of months is fairly irrelevant.

Ticket debt - why ticket systems are bad!

Ticket systems are an easy way to organize your work - yet potentially, the most damaging one as well!

What  could be so dangerous about a ticket system, the quick and easy helper tool which has found its way into almost every organization already?

Creating tickets is easy

The better the ticket system, the less effort is required to create a ticket. Some are actually as easy as "New --> (type some text) --> Save" and there you go, that's your ticket.
And this is actually the biggest problem. Let's explore why.

A ticket is an IOU

Let's look really close what a ticket is. It is a description of some work that needs to be done. It's undone work. By documenting this work in a ticket, we create a future promise that this work will get done at some point down the line.
Let's take a small real world example: "Send product offer to Tim Bobbins". That job might just take two minutes to do, or it might take longer (depending on whether Tim gets a standard document or a custom offer). In any case, by opening a ticket, we force our future self to promise to our current self that Tim will get his offer. In complete disregard what our future self will have to do later on, we sign an IOU for some work.

Tickets are a debt

Now that we realize that a ticket is nothing more than an IOU, we realize that we're actually creating some form of debt with each ticket we open. It's really work debt.
Now, just like in the finance world, there is no problem if we take some debt contract that allows us to move freely now while paying off easy rates in the future.
Unfortunately, this analogy hinges on a dangerous assumption: Inflation and business propagation allow us to earn more money with less effort in the future, so 100k Now-Dollars are a burden equal to maybe 80k Future-Dollars.
The working world behaves differently: The time we have at our disposal to do work does not grow or expand, especially not in the short term!
A 24-hour Now-day is equal to a 24-hour Future-day, so the best amount of interest you can afford to make tickets a good deal is zero.

Tickets have a real interest rate

When we borrow from the bank, we usually pay interest on our loan - we service our debt. This service pays for the bank's expenses and compensates inflation. We are fine with any amount of interest rate where our Future-Dollars are still worth less than our Now-Dollars.
Let's return to the discussion of ticket debt, then. Just like in the bank, tickets have some kind of administrative effort. Starting with the (short) time of creating the ticket, we need to administer it, we need to look at it when we work it off, and at some point we 'll to close it.
Depending on how the ticket looks like, the administration and consideration of its message may happen multiple times. Each of these times, we're not doing work, we're servicing ticket debt!

And depending on how your organization has set up your ticket process, this service can take a whole bunch of time - potentially even more than the real work to be done in the context of the ticket!

Ticket debt kills

Once we realize that there is an interest rate associated to tickets, we can look at the effect of this interest.

Here is an example of deadly ticket debt:

As long as there is still flow and the amount of tickets that get serviced equals or exceeds, there's not much of an issue - but when this trend flips and there's more tickets in need of servicing than those getting serviced, the following happens:

1 - Tickets pile up

When you get a bill from your bank, it's usually not much of a hassle, but when you get hundreds, it actually does become a hassle. And we're not only talking about the work of servicing each one, but also about the amount of work invested into keeping track of what still needs to be done. All of a sudden, extra efforts start to be required into managing the pile: Prioritizing, sorting, stashing, deferring, reorganizing - just to name a few.

2 - Ticket debt reduces ROI

Like financial interest, the amount of service interest has no contribution to actual debt reduction. Once you get into a condition where ticket debt grows faster than you can reduce it, the amount of work sunk into service interest can quickly exceed the amount of work sunk into debt reduction.
The increased service interest, especially when coupled to the limited amount of work available means that the ROI of tickets decreases with each additional ticket in the ticket pile - to the point where you may no longer be creating any value!

3 - Ticket debt reduces Value

Let's quickly return to our initial example: If Tim doesn't get his offer in 2 or 3 days, he may no longer remember the conversation and the great deal he's up for. Worse yet, he might have found another vendor in the meantime. By the time your Future Self is getting around to send Tim an offer, Tim may no longer be interested in buying anything at all. The value of the ticket decreases with each day.
Of course, this also means that when you're creating tickets to be served months down the line, you're considering Now-Value, but get Future-Value.

Summary

Take some time and look at how, where and why you use tickets in your organization. If you suffer from ticket debt, take a good look on how to reduce the amount of tickets you juggle in order to reduce the ticket debt you're servicing.



There's also a chapter on ticket systems in my book, "Extreme Agility".

Permit changes to the Sprint in Scrum?

Sparked by a recent article on LinkedIn, I would like to say a few words about changes to the Sprint. Some people consider the Sprint plan sacrosanct, others want to define a rule set for changes - yet others are very open-minded about changes within the Sprint. What is a good idea, what isn't?

Is the Sprint Plan fixed?

Many teams assume that a Sprint is immutable, and the Scrum Guide advises fixing the Sprint content as well.
This provides safety and a certain level of comfort for the team. Developers know well ahead what to do. The team can reliably forecast how well they will achieve their plan with a high degree of confidence. That's the plus side.

There are a number problems with this, such as:

1. Plans must be made upfront with a high degree of detail - possibly at a time when the best solution is not yet known.
2. Unnecessary features ( = waste) may be delivered if they made it into the Sprint backlog - resulting in additional rework in the future
3. Opportunities that become known during development are not monetized immediately - reducing the possible value delivery of the team

All these points are violations of the Agile Manifesto, so you should be careful with statements that "Scrum supports this". Yes, it does - but only to a certain extent, less your Scrum becomes un-agile.

There are good reasons to keep the Sprint scope fixed regardless, for instance to protect the team against whimsical stakeholders who consider "everything urgent" and who come up with "even more urgent" things on a daily basis.
Keep in mind, however, that this is a different problem from the problem which work developers do and when they fix their plan.

When is changing Sprint content a good idea?

Instead of proposing a huge rule set, there is a simple guideline: "When it makes more sense to change the plan than to pursue it" (ref. Agile Manifesto value #4: "Responding to change over following a plan")

Here are some of the main reasons when it makes sense to change - you may find others:

1. The team decides it is so.
2. The product is dysfunctional until the change is implemented.
3. A stakeholder has a very urgent need and is willing to pay the price.
4. Not making the change would damage the credibility and reputation of the team

How do we change the Sprint?

The Scrum Guide suggests "Sprint termination". A Sprint termination means: "We stop everything we're doing, end with a Retro and restart with a new planning". That may indeed be an option if the change proposal makes the entire remaining Sprint unfeasible. It may not be necessary if the upcoming change is of a lesser nature.

Here is what needs to be done, at a minimum:

1. Estimate the change: How much of the Sprint's remaining capacity will be redirected?
2. Re-Plan Sprint Backlog: Pull enough items out of the Sprint to fit in the change, then add the changed item.
3. Plan the change: The change needs to be subjected to the same kind of item planning as any other item that is already within the Sprint. This may require an extraordinary planning meeting.
4. Inform stakeholders: Some items won't be touched by the team because of the change. They may either return to the Product Backlog or be discarded entirely.

What happens after we changed the Sprint Backlog?

We shouldn't be doing that on a daily basis. It should remain a special event. At the end of the Sprint, the team reflects in a Retrospective why this change occurred.

Here are a few questions the team might want to ask:

1. Why do we see changes to the Sprint Backlog as a problem?
2. Why are we getting these kinds of late-and-urgent changes?
3. Did we do our best to clarify the impact of the change?
4. Did we do our best to minimize the effort and scope of the change?
5. How could we have discovered this information earlier?
6. How can we increase their agility to deal with this type of change easier in the future?

The Retrospective should result in conclusive actions for improvement.

Summary

Changes to the Sprint shouldn't be the end of the world. In a domain with high uncertainty and rapidly changing outward circumstances, change should be a normal thing. When it makes sense to change, you can not hide behind Scrum rules to justify actions that don't make sense.

Apply common sense.

Do you really want high utilization?

Let's end the discussion about whether we should optimize for maximum utilization right here, right now - with a metaphor. Ponder your own answers for the questions.

Your features are the cars. Your teams are the lanes.

Lane 1 is optimized for maximum utilization (80%+).
Lane 2 tries high utilization (50%).
Lane 3 actively minimizes utilization (as close to 0% as possible).

Question: If your goal is to get from A to B as fast as possible - on which lane would you travel?

Question: What happens when a car suddenly needs to brake? (i.e. an impediment occurs)

Question: What happens when a car needs to enter your lane? (i.e. new information becomes available)

Transfer-Question: What is the fastest way to obtain business value in product development?

Concluding Question: Since minimal time-to-market maximizes ROI - which utilization strategy should you pursue?

Denying requests without saying "No"

My recent post about why saying "No" or "But" might be avoided spawned the question: "A Product Owner should better say NO quite frequently". Based on my experience, here are some tips for a Product Owner to deny a request without actually resorting to "No". I've been using these kinds of statements for years, so this is a small collection of keeping your product in shape while staying positive.

How exactly does this idea fit into our long term strategy?

Any request which is not yet in the backlog is not worth considering in the light of the current strategy. The burden of proof to the contrary rests on the stakeholder rquesting something new.

The Product Owner should be very clear about the product strategy. Requests that either conflict with this strategy or are irrelevant to the strategy have tremendous impact. While the PO can explain the current strategy to the requester, it is the responsibility of the requester to convince the PO that this item will actually support reaching significant strategic goals faster. Tools like "Impact Mapping" are great ways of doing this visually.

You just need to convince the other stakeholders. 

"Can you ask the others to approve your request before I do something that conflicts with theirs?"

Especially in corporations, there are often many stakeholders with conflicting interests. As soon as the PO puts an item into the backlog at a certain priority, they need to justify to all of these parties why this item has been placed there - especially since it means that all stakeholder requests of a lower priority will be either deferred or descoped. Why would you want to be in that position? Just let the requester go into the line of fire. Tools like "Buy-a-feature" may be invaluable to do this effectively.

This is probably going to cost you about 10x as much as you'd want it to.

"I just asked the team, this is much bigger and more expensive than you thought".

Random ideas can quickly congest the path on your journey to maximum value. Often, stakeholders have little or no understanding how much work a "small favour" actually causes. Since the PO also doesn't have all of the information, it is very risky to commit anything behind the team's back. I have experienced "just a few days" items become severely impactful on strategic milestones, and that's not something you want. The most effective way to avoid cost/effort/timeline traps is applying the very simple tool "Ask the team".

We have limited WIP.

"Which of your requests should I scrap in order to put this into the backlog?"

People are good at coming up with ideas to keep others busy. Many people are just very bad at understanding that WIP Limits are pretty much essential to keep getting things done and delivering a valuable product. You need to exercise caution to avoid becoming a "request manager" tracking endless lists of things that have no chance of ever getting done. You don't want become responsible for reporting status of items that aren't being worked on - and you also don't want to justify why you're not getting more things done than the team can do. Make it the responsibility of the stakeholder themselves to get gray hairs over figuring out which things they really need.
A very simple tool is to have a Visual Dashboard with strict WIP limits. If that doesn't help enough yet, assign specific WIP limits to each stakeholder - for example, 3: Requests are only accepted once something got done.

Our backlog is a prioritized list.

"Do you have any data that warrants putting it into a position where it has a chance to be done in the next half year?"

Why should you, as Product Owner, waste your precious time to figure out whether something is worth doing when even the person making the request can't be bothered to do that? You are a bottleneck. Delegate as much work as possible. Avoid feeling pressured to put something at Priority 1 just because the Group CEO just had another great idea. Arrange your backlog items so that they make sense from an economic perspective. You can keep items off the list that aren't healthy for the company with the tool "WSJF" (Weighted shortest Job First).

Based on the current state of the backlog, this has no chance be done anytime soon.

"It won't be done within the next half year. I suggest you come back in about 5-6 months, if it's still important."

Why would you even bother to track things so far into the future that it's more likely your product won't fit to the idea any more than seeing these things actually get done? If the idea is good, it will come back later. If it isn't - well, why is it important to keep?
Once a request is not sufficiently valuable to get done anytime soon, it is very likely that this is the actual value of the idea. As our product grows, our ideas should actually get more valuable over time - so ideas that already aren't valuable enough now will probably never be. By keeping a rough idea how much work is currently in your backlog, you get a rough idea when the item at position 20/30/50 will be done. Any item moving to the bottom of the backlog, being beyond a predictable horizon, wastes your capacity as you need to think about it all the time.
You make your life as PO significantly easier by capping the backlog size to contain roughly 1/2 year of work.

We discuss things when they become important.

"We will consider your suggestion at an appropriate time. Thanks."

And 'now' is not that time. This means nothing short of 'This item is wasting my time', it's just phrased a little more polite. 

At any time, the Product Owner should maintain focus on the top few priorities in the backlog. Anything that is not there reduces the odds of success - who would want that? 

Avoid getting dragged into meeting madness for things that may never happen. If others want to discuss these things - fine. Let them. Once they have overwhelming evidence that you should invest time, go ahead. Until then, feel free to assume that your product is doing perfectly fine without adding the request.

Resort to Backlog Weeding. Treat all ideas that aren't worth doing anytime soon as weeds.

Summary

Being a Product Owner and staying positive towards all requests is always a tightrope walk. 

Use the approaches and tools described in this article as stepping stone towards respectful product ownership in challenging environments.

Story slicing 101

A repeating theme in agile transformations is: "Our stories are too large, and we can only deliver all or nothing - we have no idea how to slice them". The consequences? Teams can only do few, but large stories, variation and failure probability is high - predictability and flexibility are low. None of these are desirable from a business perspective - regardless of agility. Story slicing solves this.

Since we will be dealing with fairly abstract concepts, let us create a specific example to make the subject more tangible. Let us start with the "too big" story:

As a user of the platform, I want to have a response time of less than 2 seconds, so that I can spend more time actually making progress.

This is a typical case of nonfunctional requirement, phrased as a user story with clear success condition and clear indication of business value. Unfortunately, for large systems, this pretty much means rewriting the entire code base - there is no way to get this done in a few days!

Step 1 - Start asking questions

The above story leaves plenty of room for interpretation. The first misunderstanding is that "We have to do everything, otherwise it might not work". Teams end up creating seemingly endless to-Do lists for changes that all need to be made. But they don't really ask questions.
A good way is to break up the team in a Refinement session and let them actually build a model around the story to help them discover questions, independently.
Here is what the team might come up with:

Which type of users do we have?
Do admins have the same needs as application users?
Does it really hurt if user creation takes a bit longer?
Which function actually takes the longest?
Is 2.1 seconds a problem?
We could make transactions faster by splitting into multiple minor steps, but that has more clicks - would the users accept that?

Regardless of what questions come up, what you need is that these questions are written down explicitly, not a detailed discussion to answer these questions (yet).

Step 2 - Bring the questions together

Different sub-groups will probably discover different questions. There is no "right" or "wrong" at this time, only different models, resulting in different questions. All questions are good, because they reveal how people think. By having each group bring their questions to the board, we can start to cluster questions. Most likely we will have more than one cluster.
For example:

Users and their needs
Function specific boundaries
Worst-case scenarios

What you need now is not the similarities within the clusters, but the differences between the clusters.

Step 3 - Slice based on clusters

Slicing is best done across differences, but keep real user value in mind. None claim to solve the entire problem, all will contribute a meaningful partial solution. At the moment, let us "forget" about the overall problem we have and specifically focus on partial delivery.
Here are examples for extract user-relevant, deliverable stories from the basic story:

As a new user, I want to create a new account in less than 2 seconds.
As admin, I want to wipe a user account in less than 2 seconds.
As transaction user, I want to complete a transaction in the system in less than 2 seconds.

These stories are still quite different in size, but they are much easier to handle than the entire block. After we are "Done" on the first two stories, there is still a large amount of work to be done - but also a tangible result. Some of these stories might be discarded immediately, because the team realizes that this specific need is already met.

Step 4 - Drill in, Rinse + Repeat

Looking at our example, most of the work will probably be in the third sub-story. We can drill into this sub-story in exactly the same way we drilled into our initial story. Drill-in can be channeled by moderating the team to look for specific aspects.

Here is a small list of aspects to look for:

• Workflow: Steps, user goals, scenarios
• Transactions: activities, operations (CRUD)
• Users: personae (user types), roles, responsibilities
• Technology: configuration, context, data streams (& interfaces)
• Data: content, types, subsets

With this list, you could instruct one group to look for workflow aspects and another group might examine data.

Here is an example of what the "data" group might come up with:

• 60 second timeout when the database is down.
• Stuck in a "Waiting" dialog when the Internet connection is unstable.
• Mass update speed is proportional to amount of updates.

Step 5 - Verify & Engage

Depending on how far you take this, you can slice down any large topic to as many small topics as needed until the team arrives at the following two conclusions:

1. We have discovered relevant areas for change
2. We can resolve a few stories in a fairly short amount of time

Put the most important, workable stories high in your backlog, preferrably starting with the first stories right in the next sprint - and sort the remaining relevant items into the backlog at an appropriate place. If you want to, you can keep the "master story" in the product backlog, but it's priority will be lower than that of the lowest identified story.

After all known stories are closed, the master story will pop up again - at that time, the first question is: "Do we still have a relevant problem?"

Conclusion

World hunger stories are common. The most common problem teams encounter is that they dive into the solution space before working on the story definition. However, since the story with it's Acceptance Criteria defines "success", it is most important to have a realistic goal in mind. Otherwise, there is no way to succeed.
The next time you encounter a backlog item that is "too large to do in a Sprint", try asking tough questions and slicing along the differences between the questions.

Setting up an initial Product Backlog

Companies just start on their Agile journey, starting on a pilot project, typically are stuck with an un-answered question: "How do we obtain our initial Product Backlog?" Of course, first you need a Product Owner. Someone to drive the Product Vision in a desirable direction. But then: What are the steps for creating an initial Backlog?

Step 1: You need a Product Vision.

Some people don't like the term "Vision", because it sounds a bit esoterical. You may refer to it as "Product Purpose". That's about the same and sounds a bit more conservative. In this section, we will stick to the common term "Vision".

A Product Vision is a simple, yet compelling statement of why the product should even exist. It should not be too restrictive, yet sufficiently precise to be meaningful.

How do you get a Product Vision? Ideally, you already have one. Otherwise, you should group people with good ideas together to come up with one. Brainstorming business opportunities is a good way. Typically, someone with some money has a certain need - meeting this need can be the initial vision.

Here is the starting template:

I want to create a product that does [ONE THING]. 

For example, "A new way of communication." would be a decent product vision.

Once you have the Product Vision, it will be your sieve for filtering out stuff that you want to do - and discard everything that will not help in achieving the vision.

Step 2: Drill into the Product Vision.

Just like "Rome wasn't built in one day", neither will your product be. In order to make the Vision a bit more tangible and easier to verify, you need to say who should use your product and how they would be using it in the first place.
At this stage, you know nothing about what the market has to say, so keep it as simple as possible. To simplify the matter, feel free to completely ignore edge cases and negative case scenarios.

Here is the template:

Our primary customers are [ONE target audience].
To reach this goal, first we are going to [do ONE thing] in order to [achieve ONE customer-centric purpose].

Let's take our initial vision. We could specify: "We want to target train commuters who have smartphones to communicate without relying on the presence of mobile telco carrier networks,"

The next thing to do: Verify the viability of your vision quickly and as cheap as possible.

Step 3: Make the vision verifiable.

In order to know whether your product stands a sporting chance on the market, you need to collect evidence that it can do so. Regardless of whether you start with a disposable prototype or an actual MVP, you don't want to waste much time or effort before you know whether to proceed. If your vision doesn't fit the market - stop and reconsider.

When doing checks, please note that you are in the realm of hypothesis testing: You want to prove the idea that your product is viable - you can't assume by default that it is. But it is hard to prove something which does not exist will be viable. Therefore, you need to gather evidence that your product is actually not viable - when you manage to do that, trash the idea. When you can't - you still don't have proof that it is.
The easier the condition of viability can be falsified, the faster you can discard bad ideas. Disposable prototypes might allow you to falsify the viability hypothesis at a miniscule fraction of the cost incurred by an actually viable product - especially when hardware production is involved, so try to see how you want to check the viability condition.

Here is the template:

We know that we're on the right track by [checking ONE condition].

But we also need to be aware of [other conditions].

An example viability check would be: "We built a smartphone with extra long antennae and hand them to commuters, see what they think. If they don't like it, they won't buy our product." Well - you can guess the outcome, but it was just an example.

Step 4: The other stuff.

Your head is probably bursting with ideas of things your product can do. Don't prioritize all of them! There is only ONE priority 1, and that's easy to forget when you have a hundred great ideas. Put all but one of them into the backseat until you know your product actually works.

Again, here is your template:

Once we're on the right track, we will build [more of the same thing] until [a certain condition is reached].

Over time, we might also add [some more things] in order to [achieve other purposes].

Conclusion

You are on the right track with your product vision if you can meaningfully state:

I want to create a product that does [ONE THING].
Our primary customers are [ONE target audience].
To reach this goal, first we are going to [do ONE thing] in order to [achieve ONE customer-centric purpose].
We know that we're on the right track by [checking ONE condition]. But we also need to be aware of [other conditions].
Once we're on the right track, we will build [more of the same thing] until [a certain condition is reached].
Over time, we might also add [some more things] in order to [achieve other purposes].

The bold-faced items are your initial, prioritized Product Backlog in descending order. Congratulations - now it's time for the first Refinement session!

MoSCoW - yes or no?

I was recently confronted with the question: "What is wrong with MoSCoW prioritization method?" - as a rhetorical question. The answer: "It is based on wishful thinking, the idea that when we turn something into 'Must', we somehow will have it." - effectively suggesting not to use MoSCoW. Let me take a different stand here.

As a Product Owner, I am forced to make tough calls. And I admit that I use MoSCoW as a tool.

The criticism of MoSCoW

It is correct to state that "just because someone claims something must be done, it does not mean that it will be done.". Just because my customer says we must deliver that new teleporter by the end of the month, doesn't mean he will get it.
Likewise, simply defining all work as "mandatory" doesn't mean that more will be delivered.
To suggest that people from business don't understand this is merely beating up a strawman.

Maybe they are unaware of the consequence of their action when defining a "must", and the organization is in such a mess that people don't understand the complex intricacies of what "defining as must" means.

Not a prioritization tool

MoSCoW can be very easily misused when used with the wrong question, such as "Is this a 'Must' requirement?". But that's actually just a stupid question, because everyone knows the answer will be "Yes", regardless of how important something really is. 

By using MoSCoW as prioritization tool, you will end up with a backlog consisting pretty much of 100% "Must do" stuff. Next thing you know is that everyone is blaming the team and/or PO for not doing stuff that "must be done". This approach completely destroys trust. 

Take a closer look at the four terms: They are not priorities, they are categories.  

Then, learn to ask the right question:

MoSCoW as a filter

By asking the requester/stakeholder: "What happens if we don't do it?" - the answer pretty much falls into one of the following categories: 

a) We are all dead. ("must do")

b) We will suffer a lot. ("should do")

c) Someone's uncomfortable. ("could do")

d) It doesn't matter. ("won't do")

Like this, MoSCoW can be used as a very easy, quick, reliable and comprehensible way to brush off stakeholder requests that are definitely not going to be delivered: In practice, that's everything from "C" and "W". 

Not a delivery requirement

The first thing to realize is that "Must/should" is not a priority. It also does not mean "We must/should deliver this". It should be understood as: "At this time, we understand that this must/should be added into the backlog." In due order. Weighted against all of the other stuff that is already there. The backlog only consists of "Must" or "Should" items. So, these terms are effectively worthless fill words in the context of a Product Backlog.

Just like all Java programmers know Java, the term "Java" means absolutely nothing to a group of "Java programmers" - so the words "must" or "should" means nothing in a group consisting solely of " 'must or should' items".

Backlog content

"Must", in this context, does not refer to a specific date or scope of delivery. 

It refers to being appropriate for addition to the Product Backlog.

If the PBL is too big already, the PO can suggest: "If this must go into the backlog, you need to take out one thing, because I'm not going to juggle more chainsaws than we can sensibly handle."
Like that, stakeholders can be forced to make tough decisions.

The terms "must/should" are not absolute. They becomes context-sensitive. For example, "Must do" might turn into "Must do instead of [doing something else]" or: "Must do before [doing certain other things]".

You can use a very simple sentence to explain why some "Must" item just got kicked out of the backlog; "When this issue was brought up, we decided we must add this item to the backlog. Given this new information, we decided that now we won't do any work on it."

This is a highly powerful mechanism for limiting both Scope and Work in Progress.

Used appropriately, it's a real-time adaption mechanism for keeping the Product Strategy both focused and flexible.

Summary

MoSCoW is actually a principle and not a tool: We always separate work into stuff we do - and stuff we don't do - and we always call it a day at some point. Assigning a category to "not done work" only makes this explicit. The labelling process is just turning the principle behind separation of concerns into a tool.
Like every other tool, it can be abused when understood as a tool. When used to define inclusion, you will encounter a myriad of problems.  But that doesn't mean we should throw the baby out with the bath wather.

Use MoSCoW to define exclusion. It keeps the backlog short and creates transparency on why certain things are in focus - and others are not.

To estimate or not to estimate - #noestimates by slicing

At the risk of stating something that is already obvious - "#noestimates" does not mean "We don't have any idea what we're building or how much it costs". It means we have simplified the process to a point where risk and reward are in a sound correlation.
There are many ways to reach a state where estimates are no longer relevant. Here, we will discuss Backlog Slicing and its effect on estimation.

One way to remove the need for estimation is to slice deliverables into packages no bigger than 1 single day: At worst, you have lost 1 day and learned that in 1 day.

When you can do this slicing for any given backlog item within a couple minutes, it becomes completely irrelevant whether the slice is actually 1 minute or 8 hours, since the Law of Big Numbers starts to kick in at some point and it becomes fair to say that a deliverable is about 4 hours.

So, even with #noestimates we actually do have an estimate, but we don't bother going through all of the items individually, attaching a "4 hour, could be more or less" label to each and every one of them.

With this information, we can also predict cost and duration:
How many slices do we get out of a "requirement"? 1, 20, 1000? How many of them are really needed?

 Then we optimize: Can we deliver the bulk of the value by doing only a couple of them?

 Lastly, we can quickly observe and act: Do we consistently deliver an about even amount of slices per week? Does the number increase or decrease? Are there any significant outliers that clog the pipeline?
By observing the answer to this question, we imply data without actually measuring it:
As long as the consistent flow of delivery is there and there are no outliers, there is no problem.
On the other hand, when we seem clogged or bogged down, we realize this immediately, because we're not delivering any more.

 This becomes visible and can be fixed within a couple of days, so we can go without a company-wide measuring system that may tell us the obvious by the time the team is already working on a solution - or even worse, waste precious development time by holding the team accountable to solve a problem that we can't influence.


 Summary
#noEstimates is not equal to abolishing good business practice due to negligence or inability.
 Much rather, #noEstimates is a sensible step of evolution for developers who have mastered their technical domain, whose Product Owner is crystal clear on business value and priorities - and for  people with a very rigorous and keen Continuous Improvement mindset.

 A team avoiding Estimates without these three aspects in place may act haphazard.

So, #noEstimates is effectively "Implicit Estimates without explicit estimation overhead".

Stakeholder Management 101

In large enterprises, Product Owners often get bombarded with stakeholder requests of all sorts, which they all need to manage. Soon, the poor PO will find themselves juggling requirements rather than advancing the product in the best interest of the companies. Because all of these requirements are important to the person raising them, the PO will quickly become the victim not only of enormous pressure, but also of constant nagging "Why isn't this done yet?"

Here is a simplified request appraisal process for Product Owners to stay ahead of the game:

DEEP or SEED backlog?

In Scrum training, we learn that a Product Backlog should be DEEP, i.e., "Detailed Appropriately. Estimated. Emergent. Prioritized."

Consider your backlog as SEED!

However, I personally feel that another acronym might fit better: SEED. As in:

Sorted.
Estimated.
Emergent.
Detailed Appropriately.

That's not really a stretch, because when people say "Prioritized", they explain what we acually do: Not prioritizing, but actually sorting so that there is only one #1 in the list.

The real difference: Mindset

Seeing that SEED and DEEP pose the same requirements towards the backlog, one might argue that there is no difference. The difference would be in the mindset of the Product Owner, not in the Backlog itself.

DEEP: "I need to put deep thought into this, make it really deep." - After doing a detailed planning of the product, we concluded that this is the best way to implement it - which is not what you want from the initial backlog!
 SEED: "It's a seed. Let's see what becomes of it." - the kernel of the seed (Backlog items) have a lot of power and potential, but you can't really predict the future state.

Let us take the example of an acorn. The acorn is a specific type of seed and you can pretty much tell that by growing it, you'll end up with an oak. But you don't know yet whether it will grow at all, whether it will have a split trunk or how much fruit it will yield.

We want a Product Backlog that is brimming full of potential, but we have very little understanding of what we will be seeing in a couple of years.
This makes the Product Owner the gardener of their very own tree (the product), definitely in charge of raising it properly - but not doing everything right now: Let your product grow at a natural pace!

Towards the backlog as a Seed, you can ask the following questions:

• Can something meaningful grow from this?
• Do we have the proper conditions to grow this?
• Given the current state of each item, can we actually grow it?
• Will we end up with a tree or a mutant jungle when this grows?

Summary

Keeping not only the individual letter items of the acronym, but also the acronym SEED as a whole in mind when setting up or working on your backlog will help you focus on getting meaningful items in there, while keeping useless waste out.

3 things you won't get from me as a Product Owner

The Product Owner is the "single wringable neck" in Scrum. Their understanding of the product and the vision combined with their ability to decide determines success or failure of a product development team.

So, it's only fair that the Product Owner should be able to provide every information about what's going on? No.

Here are 3 things which you will not get from me when I'm a Product Owner.

Assignments

If you are a team member, do not ask me to give you an assignment.

I don't assign stuff because I couldn't. I could. Easily. But I don't. Here is why:

Even before the Sprint, I determine what matters most to the Product. During Sprint Planning, we mutually agree on the team's priority. Your top priority is visible on the Scrum board. It's the topmost item that is not in the "DONE" column.

If you are uncertain which task to pick, you have team members to help you out. Again, during Sprint Planning, the team has agreed on the necessary work items required to get the Stories or Features properly done. I let you, as the team, break it down because you know your trade. And I expect that when you do that, you know what's most important and what is the next step from where you currently stand.

If you don't understand the context of something you work on, I'll gladly discuss with you. If you don't know if something is necessary in order to deliver the value, I'm also open. But I won't tell you what to do - or how to do it.

If you, as a team member, don't know what to do next, I see a serious impediment in team communication. That's something to discuss with the Scrum Master or cover in the next Retro. But the Product Owner is really the wrong person here.

Gantt Charts and Reports

If you are a manager, don't ask me for a Gantt Chart or a % progress report on your backlog items.

I don't produce these because I couldn't. I could. Easily. But I don't. Here is why:

I decide what gets done and when the team engages. I can't tell you when it's guaranteed to be done. You wouldn't want a trash product - you want quality.
Percent Progress Reports are a distraction. You already know from Windows Installer, "The last 1% may take longer than the first 99%". It takes as long as it takes.

I can tell you how big your chunk is and where it sits in my backlog. I can give you an estimate if we'll tackle it in the next sprint, within this quarter - or not.

If you're not satisfied with my answer, we can re-negotiate priority and scope, thereby getting your stuff through the door faster, but we can't negotiate quality or delivery date. Sorry.

Performance Appraisals

If you are Human Resources, don't ask me for individual performance appraisals of developers.

I don't give you an assessment because I couldn't. I could give you my opinion. Easily. But I don't. Here is why:

First, because it's just my opinion. It's tainted by how much I have interacted with that person. It does not reflect total contribution.

Second, is the team producing significant value or not?
If not, that's my problem. If they do, they are doing a good job and then that's your assessment.

Third, let me ask: Why do you even need individual appraisals? Is it "rationalization"?
Let me be witty here: You don't ask your dentist which of your teeth works best, so that you can pull those out that contribute least. You'll want to keep all of them, unless you want to reduce your diet to pulp and soup.


A team is a team. Teams have very complex mechanics. Teams work as teams. If they don't, ask the Scrum Master what they are doing. If they do, then each person has their part.

If you want any information about the team, ask the team. They know best.

Summary

As Product Owner, I will give you the most valuable product in the shortest possible time. I am not the Team Leader or a Project Manager, despite the fact that I have significant experience in those things.
We will never get anywhere as long as I act as if I were the brightest bulb in the lamp.
I trust the self-organization of highly competent individuals to do what is right.
If that is not happening, that's something to improve upon - not to undermine.

No changes to the Sprint?

A very common question that is echoed by many Scrum teams: "What if we discover during the Sprint that a story will not help the user?"

The problem manifests in different facets, such as: A story was improperly groomed, new information became available which invalidated old information, a hypothesis about the product was disproved, etc.

Let's ignore for a minute the fact that "if we had known better, we would not have accepted this story into the sprint". We didn't and so we did. It's there. Now what?

The easy (and wrong) answer

Following the strict Scrum rules, the question is easy to answer: Continue the Sprint, deliver, use the Retro to elaborate what went wrong and do it better next time.

That's obviously wrong
We're not in business to "do Scrum". We're in business to deliver working, useful software. If we're not doing that, we're losing our reputation, credibility and - consequently, our customers - in turn: our jobs.

The correct answer

Common sense dictates the correct answer: Do what is right. Now, what is right? We deliver working, useful software.

Rather than referring to Scrum, we need to refer to the Agile Manifesto in answering this question:

Let's start with the often-ignored first sentence: "We are uncovering better ways of developing software by doing it and helping others do it." Is it "better" to build something useless? Obviously not. Being agile indicates that we're doing the best we can and from there, we look for even better ways. By simply doing what we're told, we neither do the first, nor the second.

Now, let's screen the Agile Values:

People and Interactions over Processes and Tools - you don't want to follow "the Scrum process" when a face-to-face communication can solve a problem that only exists because of a process.

Customer Collaboration over Contract Negotiation - when your "sprint contract" says to build and deliver X, yet X doesn't make sense to the customer/user, collaborate to find the Y which does.

Responding to Change over Following a Plan - when new information reveals that the Sprint Plan is no longer valid, respond to this change.

Scrum or Agile?

Scrum is an agile framework. The Agile Manifesto is the basis of Scrum. Without it, Scrum is a hollow, lifeless shell that will fail to deliver value. It would merely be a cargo cult, a "scrum-but" of the worst kind.
Scrum thrives by living the Agile Manifesto.

Refer back to the Agile Manifesto before clobbering someone with the Scrum Guide or Scrum Primer.

Summary

When you discover mid-sprint that your initial sprint plan (or, even a part thereof) does not make sense - grab your team, including the Product Owner and find a solution.
Never follow an invalid sprint plan: Change the plan, but do it in an agile fashion!

Done, Done-Done, Done Done-Done?

The "Definition of Done" is a fundamental artifact in Scrum.
It allows the team to decide when they can safely consider their work "Done".

However, many times, team fall into the trap of "Done-Done".
The root cause is usually external dependencies, such as being unable to test software ("Story Done" vs. "Test Done") or a separate Operations team ("Go-Live Done").

At scale, matters quickly worsen: Sprint-Done doesn't mean that there is a Working Release, much less that it has been deployed to Production.

As a first step, the solution is usually to come up with separate definitions of Done.
When describing these, please note that I mean: "First Step" of improvement, not something to be proud of. Having half a dozen of Definitions of Done is a smell, an indicator that something is very, very wrong!

Here are some definitions I have already encountered in the past:

Story Done

The basic activities required to say "We're done with development". Basically, this typically contains fulfilling all Acceptance Criteria, Code Review, Pull Request approved. Ideally, the Acceptance Tests are fully automated as well, although that one is already a compromise in many large organisations.

Sprint Done

The basic activities required to say "We're done with development". Basically, this includes that the Product Owner has accepted all delivered Stories and having merged all Stories into a Green Master.

Test Done

After developers have built "Working Software", it must be deployed and running on an integrated test environment where you can test the interaction with other components and services as well as with real people.
Some parts of the tests that may need to be done include Integration Testing, Performance Testing, Exploratory Testing etc. Just refer to the Test Quadrants to get some ideas of what may be needed.

Deployment Done

After tests are passed, the software must be Up and Running on a Live System. Alternatively, if you are shipping Vendor Software, it means you have a Shippable Product that has gone out to the customer. 

Release Done

 A Release is "Done" when no more activities related to the release are oustanding. Beyond deploying Working Software, it may include automated monitoring and reporting, looking at first figures on the Live Server etc.

The illusion of "Done"

At worst, you end up with a state of Done-Done-Done-Done-Done-"Not Done-Back To Step 1", where faulty stories need to be fixed weeks after they were marked "Done".
As a consequence, old work starts to flow back into current sprints, reducing predictability, velocity and morale.

Oftentimes, companies take this venue because either:

• There is too much pressure to get something "Done" 

If this is the case, management must be educated that they are sacrificing a high amount of sustainability for an insignificant increase of speed.
Listing the "hidden factory" work that must be done by the team outside of "Story Done" and figuring that into the total cost of delivery may help.

• They don't know how to do it differently

 From a strategic level, this is easy to fix. Operatively, it requires a lot of organizational change.

 

Minimize "Definitions of Done"

Team Definition of Done

A "Story" should not be "Done", followed up with additional work to get the "Sprint Done". The first step is to eliminate this gap.
"Story Done" should be attained when there is no more work that the team can do in the sense that from the team's perspective, there is Working Software by the time Story is set to "Done". A story is never "done" unless it is already integrated into the Master and ready to deploy to Production.
Provide a single Definition of Done for the team that includes everything the team can do. Accept no compromise, no intermediary steps.
Other teams can do this, so your team can do it, too!

Organizational Definition of Done

Never take the route of splitting into stuff like "Testing Done", "Release Done", "Deployment Done".
When setting out, catalog all "undone work" which the team does not do that happen before actually bringing the software into production into a single "Organizational DoD" (ODoD).
After creating a catalog, start out by eliminating the obvious waste.
Then comes the tricky part.
Every item on the ODoD should be considered an impediment for story delivery: Anything "urgent" is always blocked by the ODoD.
Depending on your organization, it may take years to move all items from the ODoD towards the team. This should not discourage you from undertaking the journey: Every reduction to the ODoD increases the organization's flexibility and risk of failure in case of emergency.

The Vision of "Done"

There is a single Definition of Done for each team.
The teams act upon this definition and not anything else.

The team can complete all activities necessary to reach Done.
No other party must become active for any item to become Done.

"Done" means "Done".
There is no work left to do when the team moves the card to "Done".

We know it's over.
The risk of failure is already eliminated, so there will be no residual risk of having to undo.

Weeding out the backlog

When companies transition to Scrum, or any other Agile methodology, they usually start with the problem of arranging all the identified "undone work". Where do we start?

In the worst case, huge amounts of "overdue" items are all considered "Priority 1". In this situation, the Product Owner must clearly indicate where the team should start.

Other organizations seem to suffer from a kind of collection addiction, keeping a backlog of hundreds of items that won't ever get done.

Here are some tips for maintaining a nice, tidy, workable backlog.

Intially setting up a backlog

Before even bothering to produce detailed user stories or doing task breakdown, the Product Owner should simply draft out the basic areas of the Product. 

Post-It notes with maybe one or two words will do the trick. Then, draft the matrix below on a board and place the sticky notes:

The backlog item placement matrix

Put your backlog items on this matrix!

Impact

When weeding out based on impact, you must identify your customers and stakeholders. For each item you identified, you must ask "Who will suffer if this is not implemented?" 

If the impact of not implementing the item is low or not even measurable, the item is certainly not important.

Urgency

Next, you weed out based on urgency. A good initial question to ask when chaffing out for initial urgency is: "If we do not deliver within 1 month, will there be significant damage to our business case?" - if the answer is "no", the item has low urgency.

Unclear cases

If you're unsure, feel free to put the item on the dividing line between low/high.

When that region clutters, you can benchmark by using the top item on the dividing line. Ask yourself for each item: "Does this have higher impact / urgency?" to make a decision quickly.

Scrap

Ideally, you will end up with a good number of items in the "Scrap" section. Congratulations, they are off the table! You do not need to waste any further minute with these topics.

Defer

For anything in the section "Defer": put those items on the bottom of your backlog and leave them there. Do not waste time now grooming them, because you will not work with them in the near future.

Why?

For anything in the section "Why?":

If you would invest a lot of effort for little impact, move the item to the "Scrap" section.

When you're just starting a new product, it's probably a bad idea to have anything from this in your backlog, because you want to get your product going - NOW!

When you're working on an existing product, you may want to look for "quick wins" in this section. Anything that will give you a credibility boost at low cost should be considered.

As long as the item still has a positive Return on Investment, you should do it, but only if you can squeeze it into the schedule.

Only groom items which will bring your product ahead with minimal effort. 

Move the others into the backlog until further notice.

Do Now

Should you have significantly more than five items here or dispute over priority, you need to weed out further.

The items remaining in this section are your high level backlog ("Epic items").

These items need to be made workable, such as by using INVEST. Break them down to feature level and start with the Story Breakdown.

Ordered weeding

If you feel uncertain about being too lax with weeding and up with a cluttered "Do Now" section", you should use "Magic Numbering" on the cards twice.

During the first round, simply arrange the cards by impact. After finishing, arrange them into buckets from 1 to 5 with ascending impact and note the impact on the cards. Unless you have less than 6 items, each number should have at least 1 item.

During the second round, arrange the cards by urgency from "low" to "high" in ascending order from left to right.

Then, use the noted numbers of impact to move the cards up (high impact) or down (low impact). Make sure their horizontal position remains unchanged. when arranging them on the vertical axis.

Afterwards, draw the lines - not in the middle, but between the "3" and "4" rows and columns, so purposefully create a bias towards "High".

Wrapping it up

You may flinch when you see that "lots of valuable stuff has gone off the list", but if you did the arrangement correctly,  only "even more valuable stuff will get done".

Your initial backlog should be very small and tidy at this point, easily workable for further breakdown.

Likewise, you can immediately and effectively quench discussion about any other topic with the simple argument "It won't get done now, anyway".

Recursion

You can apply the same process with the story / feature breakdown of each item. When moving into the first sprint of the team, it's actually a good idea to not overload the team with information. Weed the Ready ("groomed, broken down, workable") backlog to no more than five workable items for the first sprint.

Sprint planning

After the sprint, you will learn about the team's capacity. The amount of items you need to have Ready for the next Sprint should be roughly equal to twice the team's velocity. 

Once an Epic ("high level") item is fully groomed and there are not enough Ready items in the backlog, you take the next Epic and break it down. Start with the "Do Now" items and pull from "Defer" or the "Quick Wins", depending on what currently makes more sense.

Iterating

Impact and Urgency are subject to change. For instance, in May, the annual fiscal report is not urgent - in December, that's an entirely different story! Or, you have a customer threatening with a lawsuit - that may make an otherwise insignificant topic very urgent.

Whenever an item is added to / removed from the Epic Backlog, priorities may change. Between each sprint, you should bother taking a couple of minutes to do an iteration of weeding to make sure you are properly set up for the next sprint. 

Consequently, stories that were groomed on a detailed level may move to the "Scrap" section. That is okay. If the current product priorities indicate that this makes sense - so be it!

Don't bother tracking backlog that nobody will work on in the near future.

A good indicator of when you should weed:

You have items in the backlog that were not touched for more than 3 Sprints, and nobody has bothered asking about them.

Use frequent weeding to keep a significant, concise backlog.