Agile and Scrum Videos

Watch Mountain Goat Software videos on agile, Scrum, product ownership, estimation, planning, and teamwork.

Backlogs

Learn how to shape, prioritize, refine, and size product and sprint backlogs so teams can focus on valuable work that is ready at the right time.

Agile Backlog Iceberg: Why Scrum Teams Use This Visual

Transcript

A product backlog is shaped like an iceberg because it reflects the varying levels of detail and size of product-backlog items according to their priority
and when they're expected to be worked on.
At the top of the iceberg, above the waterline, are the small, well-defined items that are ready to work on in the next sprint or two.
These items are detailed enough for the team to understand and implement without needing much additional clarification.
They're small enough for the team to complete multiple items per sprint, typically about one and a half to two items, per person.
This provides the Team with a clear and actionable plan for their immediate future.
As you move deeper into the backlog, items become larger and less detailed.
These medium-sized items are likely to be worked on in the coming months, but are not ready for immediate development.
They act as placeholders for upcoming work, and they'll be refined and broken down into smaller items as they approach the top of the backlog.
This gradual refinement process prevents the team from spending time prematurely breaking down items that may change or might never be implemented.
At the very bottom of the backlog, below the waterline, are the largest items.
Big ideas or high-level features that remain mostly conceptual.
These items require minimal documentation, often just a few words, because they're not expected to be addressed for a long time,
if ever.
For example, for many years, the travel website Orbitz would allow users to book airline tickets, rental cars, or hotel reservations.
Users could not reserve a cabin on a cruise ship.
When Orbitz finally added cruise ships, it wasn't because someone had just thought of it.
I have a great idea.
Why don't we add cruise ship to the site?
I'm sure the cruise-ship backlog item had been thought up years earlier.
And for items, either it languished at the bottom of the product backlog or was so low priority no one even wrote it down.
This approach avoids unnecessary effort and allows the Product Owner to focus on the most immediate needs.
The iceberg metaphor effectively illustrates the dynamic nature of a product backlog.
As the team completes items at the top, the backlog floats up, bringing larger items from below the waterline closer to the surface.
These larger items are then split into smaller, more detailed stories to maintain the iceberg shape, with small items at the top,
medium-sized items in the middle, and large, undefined items on the bottom.
This structure ensures the team always has a manageable, prioritized set of work ready while minimizing wasted effort on distant future items.
It also embodies the principle of just-in-time refinement, where the level of detail increases only as the work becomes more imminent.
If you'd like your team to go deeper on this, learning how to refine split stories and keeping your backlog healthy, check out our Working on a Scrum Team course.
It's designed for whole teams to practice these skills together and can be taken privately or as a public class.
You'll find links about this class in the description or drop me a comment to find out more.

5 Key Factors for Effective Product Backlog Prioritization

Transcript

Not only do you need to build the right features, you have to build them in the right order. I want to share five key factors you should consider when prioritizing a product backlog. Let's start with a biggie: value. And while it's a given to consider how valuable a feature will be, value is a nebulous term. Most work a team will pursue will be valuable to users, but other work may be valuable just to the team. Still other work may be valuable to both users and team members. For example, consider refactoring: improving the structure but not the behavior of code. Because this makes code more maintainable or easier to change, refactoring is valuable to developers. Still, the cost of refactoring is usually justified by the way it benefits users too. If code is more maintainable, users should experience fewer bugs. Similarly, improved code means that users should receive new features in that area of the product a bit more quickly. The second factor to consider when prioritizing is the cost. The largest cost is usually the team's effort to develop a feature. Most teams estimate the effort product backlog items take in story points, but some estimate in person-days, ideal time, or other similar units. In some cases, there may be additional costs that should be considered. A current common consideration: the ongoing cost of delivering features that rely on various artificial intelligence products. These products often include small per-use fees, but those fees can certainly add up at scale. Regardless of the unit in which a team estimates their product backlog items, that cost to develop and support a feature should factor into an item's priority. For example, an item that a team estimates as five should be prioritized higher than a feature estimated at 20 if all else is equal. This is true whether these are story points, person-days, person-hours, ideal time, or any other unit. A third factor to consider when prioritizing is this: the amount of learning that will occur when the team develops the product backlog item. If you'll learn something important by developing a backlog item, develop that item early so that you have time to act on whatever you've learned. Learn something too late, and you won't have time to benefit from the new knowledge. Learning can take two forms. It can be about the product or the project. Learning about the product occurs when the team develops a feature and receives feedback on it. If users love the feature, do more of it and more things like it. If users don't love it, consider removing the feature or lowering the priority of related features. Learning about the project refers to knowledge team members gain about how to develop the product or solution. For example, suppose a team intends to build part of a product using a technology that team members have never used before. When team members develop the first product backlog item using that new technology, they will learn things about it, such as: Does the technology work as promised? Should estimates for using the new tech be revised? And can the technology be used in other parts of the product or project? The fourth factor to consider when prioritizing is the risk inherent in developing the product backlog item. If something is risky and you need to do it, do it early. You want to know whether that risk is going to materialize. On the other hand, if a feature is risky and you may not need to develop it, delay working on it until it becomes clear you need to do it. The final factor you should consider when prioritizing is dependencies between product backlog items. Some items may not be high priority on their own, but they're necessary for delivering other items. When that's the case, the enabling but lower-priority item needs to be moved higher on the backlog in order to be done before the item dependent on it. As an example, consider a summer camp I helped use Scrum. Among their product backlog items was repainting all the canoes. That was high priority because they wanted to show photos of the shiny, newly painted canoes in their marketing. But painting the canoes was dependent on another backlog item: sand and repair any canoes that needed it. Technically, repairing the canoes didn't need to be done until a day or two before the summer camp opened, but that item was prioritized higher in the product backlog because the marketing photos of the canoes needed to be taken long before that. While all five factors are important, I don't recommend combining them through some fancy formula. The value of a feature and its cost, our first and second factors, are the most important. I recommend continuing to prioritize based on these, but then using the other three factors to adjust priorities. For example, suppose a product owner or product manager has prioritized an item such that it won't be done for another three or four iterations based on its value and cost. At that point, consider learning, risk, and dependencies. Move the item up an iteration or two if any of those factors is significant. Additionally, there are many ways to prioritize product backlogs, including formal prioritization frameworks such as Kano analysis, RICE scoring, and relative weighting. Even with those formal methods, keep the five factors I've mentioned here in mind, even when they're not explicitly part of those frameworks.

Agile Epic, User Story, and Feature: Do Names Matter?

Transcript

User stories, epics, themes, features, backlog items, initiatives, sagas.
It gets so confusing and it doesn't need to be.
In this video, I'm going to explain these terms and then I'll explain why I don't use a complicated user story hierarchy and why you probably shouldn't either.
Hi, Mike Cohn and I am the author of three best-selling books on Agile and Scrum.
I help teams succeed with Agil and want to help you too.
Most agile teams have what they call a product backlog, using a term introduced by Scrum.
At its simplest, a Product Backlog is a list of things to add to or improve in a products.
A Product backlog comprises product-backlog items.
That is, each thing on a project backlog is product backlog item.
Since that's a mouthful to say or a lot of characters to type, you'll see it often abbreviated as PBI.
The Agile process extreme programming introduced the idea of user stories.
These are short, simple statements told from the perspective of a user.
Imagine team members talking to users and saying, so tell me a story about how you use this new system we're building for you.
I'm using software to control my camera right now.
If I am asked to tell a story about how I'll use that software, I might say that I want to be able to easily zoom my cameras in and back out.
That's a user story.
Here's the first problem.
User stories have become so common in Agile that a lot of people will use user stories and product backlog items interchangeably.
I get it.
If, let's say, 80% of your product backlog items are user stories, you just fall into the habit of calling them all user stores.
We're not going to do that today, though, as I want to be very precise in using these terms.
User stories were invented by a team at Chrysler.
When you invent something, you should be allowed to define the vocabulary.
And they did, defining the terms epic and theme.
Epic was used to mean big user story.
Think about watching some awesome superhero movie in a movie theater.
As you leave the theater, You turn to a buddy and say, dude, that movie was epic.
It was big.
There was lots happening on the screen.
It's the same thing with an epic user story.
it's big!
The other term they defined was theme, which meant a group of related user stories.
Suppose you're working on a system that has 10 stories about account management, and maybe there are 15 user-stories, each describing a report that users need.
These are themes, groups ofrelated items.
If I've confused you with Epic and Theme, it's likely because some of the tool vendors use the terms differently.
Jira, I'm looking at you.
These tools will use Epic to mean a group of related items.
I don't know if this was a deliberate vendor lock-in strategy, or if a programmer made a mistake on Tuesday, released the software on Wednesday,
and by Thursday it was too late to rename the feature.
In any event, it's created confusion in the Agile world about Epic and Theme.
I've kind of given up and I'll often refer to them as big ones or group.
No one can redefine those terms out from under me.
You'll want to use Epic & Theme the way your tool does.
But be aware that if you read articles or books, you might encounter the original and what I consider the actual definitions.
So we've got a product backlog, on it are product-backlog items.
Some of those product backlogs items, perhaps most for some teams, are user stories.
some user-stories are big, and we call those epics.
And user story can be grouped into themes.
Next up is the term feature.
Most commonly, this means a product backlog item that is big enough it can be released to users.
If you're building software to control the color of smart home lights, you probably wouldn't release a backlog that let users set only the red value of
the light.
but letting users control the full color spectrum by setting red, green, and blue values is big enough to release.
So that would be a feature.
Feature is similar to Epic, at least how Epic was originally defined.
Epic just tells us that a story is Big, but Features tells it's big ENOUGH to be releasable.
Some organizations or tool vendors add even bigger items on top of this.
Sometimes saga is used to mean something bigger than an epic, and initiative is use to means something taking perhaps a year to do.
Something this big shouldn't be on your product backlog, so I'm not sure why we need a name for it.
I recommend you think of these terms as labels or tags that can be applied rather than as a strict hierarchy.
This is because some features are bigger than some epics or themes.
There's not a magic size when an epic becomes a feature or the other way around.
Think of tagging movies in your movie library software.
I want to tag some movies as action movies, some as comedies, and perhaps some romantic comedys.
Is there a strict definition of these?
If there are 32 jokes per hour, does that make it a comedy?
If there are 20 jokes plus a kiss, is it a romantic comedy?
It doesn't work that way.
Action movie, comedy, romantic-comedy are just labels we can apply, and we do it for our convenience.
The same should be true of terms like user story, theme, epic, feature, saga, or initiative.
They're just labels.
Use them if they're convenient, or I guess if someone in your organization is requiring them.
I think of everything on my product backlog as a product-backlog item.
Some are big enough that they contain smaller backlog items within them, and some of those small items contain tiny items.
To me, it's quite simple with a recursive relationship.
i don't need a bunch of terms that can create confusion.
And when I do want to indicate that a backlog item is big, releasable, or related to other items, I can tag those items.
No complicated hierarchy needed.
Is your team using a complicated product backlog item hierarchy?
What benefits do you see to that?
Any challenges?
Do you use terms other than the ones I've described?
Let me know in the comments.
I read and appreciate every comment.
If this video has been helpful, click the Like button.
And if you're new to this channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching, and I'll see you next time.

Treat Features, Epics, & Themes as Labels

Transcript

There's not a magic size when an epic becomes a feature or the other way around.
I recommend you think of these terms as labels or tags that can be applied rather than as a strict hierarchy.
Hi, I'm Mike Cohn and I am the author of three best-selling books on Agile and Scrum.
Think of tagging movies in your movie library software.
I want to tag some movies as action movies, some as comedies, and perhaps some romantic comedys.
Is there a strict definition of these?
If there are 32 jokes per hour, does that make it a comedy?
If there are 20 jokes plus a kiss, is it a romantic comedy?
It doesn't work that way.
Action movie, comedy, romantic-comedy are just labels we can apply, and we do it for our convenience.
The same should be true of terms like user story, theme, epic, feature, saga, or initiative.
They're just labels.
Use them if they're convenient, or I guess if someone in your organization is requiring them.
Is your team using a complicated product backlog item hierarchy?
What benefits do you see to that?
Any challenges?
Do you use terms other than the ones I've described?
Let me know in the comments.
I read and appreciate every comment.
If this video has been helpful, click the Like button.
And if you're new to this channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching, and I'll see you next time.

Backlog Refinement: When Is a Story Ready for a Sprint?

Transcript

Product backlog refinement is one of the most misunderstood activities in Scrum.
Many teams struggle with how much detail is enough before bringing a backlog item into a sprint.
Some teams barely refine at all.
Others over-refine and waste time eliminating uncertainty that doesn't matter.
The goal of product backlog refinement is not to eliminate uncertainty.
It's to build enough confidence to make a responsible commitment.
Refinement is about developing enough shared understanding that the team can reasonably believe a backlog item can be completed within a sprint.
That's the goal.
Here's the question I use.
Do we know enough to believe this item can probably be completed within a sprint?
I don't use, have we answered every possible question?
Or have finalized every design decision?
Just, do we have enough understanding to commit responsibly?
If the answer is yes, stop refining.
If answer's no, identify the biggest unknowns and resolve them before bringing the item into the sprint.
I think of refinement in three zones.
On one end, you have items that are too vague.
There are major unanswered questions.
The team can't responsibly bring them into the sprint because the scope could explode once work begins.
When teams pull items from this zone, they're uneasy.
You can see it.
People hedge.
They add buffers.
they commit without confidence.
On the other end, you have items that are over-refined.
The team is trying to eliminate every uncertainty.
They're refining work sprints ahead of time.
There are debating design details that may change once work starts.
In this zone, the team solving problems that never matter.
In the middle is the refinement zone.
That's where you want your items.
Enough clarity to fit in a sprint.
Major risks addressed.
Minor unknowns still present, but manageable.
There are still questions, But no one feels anxious about committing.
The goal is not to push items as far right as possible.
the goal Is to move them into that refignment zone and then stop.
Let me give you an example.
I worked with a team building a bioinformatics application with some fairly intense 3D visualizations.
One backlog item depended on how much data the system needed to support.
If the data size was under a certain threshold, the team could use an existing commercial visualization package.
if it was above that threshold the, team would need to develop their own.
That would make the story much larger.
During refinement, the product owner could not clarify the data size requirement.
That uncertainty mattered.
It could dramatically change the scope.
So the team chose not to bring the item into the sprint.
If that was the right call, they identified a sprint-threatening unknown and resolved it before later committing.
that's refignment working the way it should.
Now consider another common mistake.
Many teams think backlog refinement means making the entire backlog detailed and ready.
A healthy backlog doesn't work that way.
It should have a gradient of clarity.
items near the top, the ones you're likely to work on soon, should be clear and reasonably detailed.
items further down should less detailed, they might be nothing more than a sentence or two.
Leaving lower priority items vague is often the disciplined choice.
If you fully refine backlog items far ahead of when you'll work on them, you're investing effort in work that may change,
move, or disappear.
Focus your refinement effort where it matters most, at the top of the backlog.
There's also a simple way to diagnose whether refinement is working.
Look at what happens during sprint planning.
If during that meeting, team members are still unclear on what a story means or if they frequently need to split stories or they decide there are major unknowns,
that suggests refignment wasn't done well.
Poor refinement leads to longer sprint planning, which leads frustration and disengagement.
And over time, trust between the product owner and the team erodes.
Refinement isn't just about efficiency.
It's about predictability and trust.
I often say I don't want a team hitting its sprint goal 100% of the time.
A team that achieves its spring goal every sprint is probably playing it safe, picking easy goals.
But I also don' t want the team to miss the goal most of time If a team achieves its sprint goal around 60% to 80% of the time,
that tells me they're stretching but being realistic.
Well-refined backlog items make that possible.
One final caution.
Don't let refinement turn into a design meeting.
Design discussions are necessary, but refinement has a specific job.
It's about clarifying boundaries.
What's included, what's not included?
What assumptions are we making?
what could dramatically increase scope?
If the team can answer those questions and reasonably believe the item will fit within a sprint, refignment is done.
Design can continue during the sprint.
So if refinement feels heavy, try this.
Refine less.
Stop refining when the team knows the item will fit in a sprint.
Refinement is about smoothing the road so the teams can move quickly without avoidable surprises.
You don't need certainty.
you just need enough confidence to commit.
If you'd like a practical tool to help your team to decide when an item is refined enough, I've created a checklist and written a full guide.
You'll find links in the description.
And I'm curious, what does refinement look like on your Team right now?
Does it feel rushed, overdone, just right?
Let me know in comments.

How to Run Effective Backlog Refinement Meetings in Far Less Time

Transcript

Product backlog refinement meetings are filled with opportunities for improvement.
I see more time wasted in refignment meetings than in all other meetings combined.
Understanding the purpose of backlog confinement is essential to comprehending why.
The purpose of refinement is to ensure that the items near the top of a product backlog can likely be completed in the upcoming iteration.
This means that items need to be small and sufficiently understood.
Small is straightforward.
A team cannot bring a large product-backlog item into an iteration and expect to finish it.
Most teams have a maximum size they allow into the iteration, I suggest no more than half of the team's velocity.
For instance, a team with a velocity of 20 could bring in an 8-point item into the iteration, but not a 13- point item.
I certainly prefer items smaller than a half a teams velocity, But half works as an occasional upper limit.
Sufficiently understood means that enough is known about an item to bring it into next iteration.
It does not mean that everything is understood about that item!
The goal in refinement meetings is not to eliminate all uncertainty, but to reduce it to a level where the team feels comfortable starting work on the items,
even if some issues remain unresolved.
Teams are encouraged to address some of those open issues during the iteration, as overlapping work and decision making are key aspects of being agile.
The team should resolve enough open issues so that they think an item can probably be completed within the iteration.
I want a team to feel like they probably know enough to complete the item without putting in so much work ahead of time that their sure of it.
They should finish refinement of an items thinking they've addressed all or most of the significant open issue and enough of small ones to feeling good
about the likelihood of completing it during the sprint.
There's a trade-off between spending more time answering questions before bringing the item into an iteration and just bringing it in and using the iteration
to identify open issues and resolve them.
It's often faster to bring the items in, and get started on it.
When a team attempts to resolve all open issues during refinement, the meeting lasts considerably longer.
Additionally, time is wasted as the entire team discusses each item, even when only three or four different people are required for each.
Being compelled to attend a meeting where much of the discussion is irrelevant to you certainly frustrates team members.
Let's look at three things you can do to keep backlog refinement meetings shorter, more productive, and less frustrating.
First, position the product backlog-refinement meeting as a pre-planning checkpoint.
Don't necessarily rename the meeting, but emphasize its function as preplan check.
The team reviews the top items to ensure they are ready for the iteration.
If items are not ready, they can be made smaller or have details added to them.
Second, emphasize that not all open issues need to be resolved in advance.
Backlog items need be sufficiently understood, not perfectly understood.
I like to do this by frequently asking, do we know enough about this item that we can probably finish it during the iteration?
This reinforces that a team should know ENOUGH, but not everything.
Third, consider having only a subset of the team participate in refinement meetings.
Generally, I'm in favor of full team involvement in activities.
But backlog refignment can be almost as effective with significantly less time spent when only subset team members are involved.
If the whole team participates, a certain number of questions will be asked to clarify what needs to be done for each backlog item.
Conducting the meeting with about two-thirds of the team usually generates nearly all of these same questions.
The participants can vary from iteration to iteration depending on who's available.
If someone consistently cannot attend, this should be addressed in a retrospective.
While refinement meetings are collaborative, flexibility in attendance ensures the team balances refignment with ongoing iteration commitments.

Stop Turning Backlog Refinement into a Design Meeting

Transcript

Backlog refinement is supposed to make sprint planning easier, but for many teams, refignment itself becomes the most exhausting meeting of the sprint.
The reason is simple.
Refinement quietly turns into a design session.
You schedule an hour to clarify upcoming work.
40 minutes later, you're debating architecture, comparing frameworks, sketching diagrams, and optimizing solutions.
And you still haven't answered the only question refinement exists to answer.
Can this fit in a sprint?
Design work is not the problem.
Good teams design thoughtfully.
The problem is timing.
Refinement has a specific job.
It clarifies scope.
What's included, what's not included?
What assumptions are we making?
what unknowns could dramatically increase scope?
Refignment is about reducing sprint-threatening uncertainty, not eliminating all uncertainty.
If the team can reasonably believe an item will fit in a sprint, refinement of that item is done.
You do not need a finalized design to start work.
Teams drift into design for predictable reasons.
Uncertainty is uncomfortable, and designing feels productive.
It feels like progress.
Many engineers have been rewarded their entire careers for solving problems early and thoroughly.
So refinement feels the right time to do that.
And sometimes meetings drift simply because no one has clearly defined what refignment is for.
If you don't define the purpose of a meeting, it will expand to fill the space.
Here's a simple test.
During refinement, ask whether the conversation is clarifying scope or optimizing a solution.
If you're debating frameworks, refactoring strategies, or architectural trade-offs, you may already be past the level refignment requires.
That doesn't mean those discussions are wrong.
It means they should happen at the right time.
Come back to the threshold question.
Do we know enough to believe this item can probably be completed in the sprint?
If yes, stop.
If no, identify the biggest unknown and resolve that.
That question requires enough clarity to commit responsibly, not a perfect design.
There's another subtle issue.
Some teams assume involving everyone in refinement means discussing everything in front of everyone.
I don't think that's necessary.
Refinement is about surfacing the majority of important questions, not exhausting every possible one.
On many teams, you can involve most but not all of the team in a session and still surface the vast majority issues.
You should rotate participation so everyone stays engaged over time without turning every refinement meeting into an exhaustive design review.
The goal is not maximal participation.
It's sufficient clarity.
Over refinement also happens when teams work too far in advance.
They debate design decisions for items several sprints away.
By the time the sprinter arrives, priorities have shifted or assumptions have changed, and the team has to revisit the discussion.
That's wasted effort.
Refinement creates the most value when it focuses on the next sprint or two where clarity directly improves commitment and predictability.
Here's a practical guideline.
During refinement, stay at the level of scope and risk.
Clarify what the story includes and what it does not include.
Identify assumptions, surface dependencies.
Highlight any unknown that could dramatically increase the size of the work.
If resolving an unknown requires a short investigation, that may be appropriate.
if resolving it requires designing an entire subsystem, you're probably going too far.
Over-refinement has real costs.
It consumes time, it drains energy, and creates the illusion of certainty.
And it reduces adaptability because once a team feels it has thoroughly designed something, It becomes harder to change direction.
Lightweight refinement preserves flexibility.
The purpose of refinement is not to design the solution.
It's to make the work achievable within a sprint.
Design continues during the sprint when the team has real context and real feedback.
So if your refinement sessions regularly feel too long, technical, and exhausting, tighten the focus.
Ask what must be true for this item to fit in a sprint.
Enter that and then stop.
You don't need certainty.
you need enough confidence to commit responsibly.
If you'd like a practical checklist to use during backlog refinement, along with a full guide that walks through these ideas in more detail,
you'll find links in the description.
And I'm curious, on your team, does refignment tend to drift into design, or does it stay focused on scope and readiness?

What Is the Definition of Ready in Agile and Why Is It Dangerous?

Transcript

Your Agile team probably has a definition of done, and that's a good thing.
On the other hand, a definitions of ready is dangerous and something most teams should avoid.
Hi, I'm Mike Cohn, the author of three best-selling books on Agiles and Scrum.
I help teams succeed with Agil.
And right now I can help you be more successful by convincing you not to use a definitive ready.
A definition of ready acts as entry criteria for the sprint.
Nothing is allowed into the Sprint unless it meets that definition.
To see how this works, let's look at a typical definition for ready.
It might include things like all acceptance criteria have been fully defined.
The product backlog item has been estimated and is five points or smaller, and the user interface has be designed and approved.
Nothing would be allowed into a sprint unless each of those statements is true.
A definition of ready such as this can absolutely help a team avoid problems.
If, for example, a theme has struggled because of bringing big items into its sprints, our rule governing the maximum allowable size of an item is great.
That rule will solve the problem.
But there's a downside, which is that a definition of ready can prevent a team from overlapping work.
Overlapping or concurrent work is a vital component of most Agile approaches.
Testing, for example, should overlap coding.
An Agil team doesn't delay testing until all coding is finished.
To differing degrees, the same could be said of all aspects of software development.
Analysis, design, testing, and coding all overlap.
A definition of ready can hamper a team's agility.
Think about the example I mentioned, which said an item is ready for a sprint only if all its acceptance criteria have been fully defined.
That may sound fine, but it is going to prevent the overlap of work.
The definition of ready is requiring that all acceptance criteria be figured out in advance.
So you can't have some people build the feature at the same time as other people define the acceptance.
Not only is knowing the criteria in advanced sometimes impossible, it's usually unnecessary.
Some acceptance are quite reasonably determined while the team is working on the item.
As another example, recall that the sample definition of ready I shared included that user interface has been designed and approved.
Again, including this in a definition ready will prevent work from overlapping.
This instructs team members that a user-interface design must be done before any other work can begin.
Think of any definition Ready as a gate into the sprint through which work must pass.
Only certain types of work pass through this readiness gate.
It makes sense to picture your definition of ready as a gate, because the whole idea really is nothing more than a step back toward a waterfall or stage
gate process.
So is a definition ready always a bad idea?
No, it's not.
You may want to consider a definitions of Ready to call out dependencies on other teams, especially if those teams frequently fail to deliver to you when
they say they will.
Suppose your team is dependent on something my team's building.
We promised to give it to you by Tuesday.
But Tuesday comes and goes, and my teams gives you nothing.
Wednesday comes, Thursday, Friday, a week goes by.
My team finally gives what we promised, but way too late for you to use it and finish whatever you committed to in the current sprint.
If my team does this too often, you may want to have a definition ready that says you won't bring anything into your sprint that is still waiting on something
from my Team.
If My Team owes you something to do your work, You want it in hand before the sprint starts because of how often MyTeam has jammed you up.
Note that this is absolutely an example of how a definition of ready prevents overlapping work.
It's less agile than if we could overlap work, but in this example, my team has let you down so often, you'll put in place a definitions of Ready to stop
it from happening again.
While we'll be less agile because of this, I think this is a good use of a definition of ready.
After all, your team has stakeholders you need to keep happy.
And when your promises to them about what you'll deliver are destroyed by my team not delivering to you, it's very reasonable for your teams to stop overlapping
work with my teams.
If you absolutely feel you need the definition of ready, I recommend structuring it as a set of guidelines rather than rules.
Consider a definition ready that says before anything can be started, any new or changed screens must be designed and the designs approved.
This rule will prevent overlapping work.
A better variation would be to say something like rough mock-ups of any new screens have been started and are just far enough along that the team can resolve
remaining open issues during the sprint.
This is a guideline.
It will still allow work to overlap.
The mockups need to be far-enough along, that team members think they can solve issues, during this sprint In some cases,
that could mean no more than a mock-up on a whiteboard.
In others, it could be an elaborate, nearly complete mockup.
Does your team use the definition already?
What's included in it?
And have you been able to continue overlapping work even with a definition of ready?
I'd love to read about your experiences.
So please share them in the comments.
And please do me a favor.
If this video has been useful, click the Like button.
and if you're new to the channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching, and I'll see you next time.

What Is the Right Size for Sprint Backlog Items: I Have the Answer

Transcript

There is a magic maximum size for the items an agile team brings into its sprints.
If a team bring an item bigger than this into a sprint, team members will struggle to finish the work of the sprint.
This will create problems with the team's velocity, which will in turn make it harder to plan in the future.
In this video, I'll share this magic max size with you.
Hi, I'm Mike Kona, the author of three bestselling books on Agile and Scrum.
I help teams succeed with Agil.
My recommendation is that a team should not bring into an iteration any item that is more than half of its velocity.
In general, i'd like items much smaller than that, but half the average velocity works as a good upper limit.
As an example, consider a team with a velocity of 30. This team can bring an item up to 15 into its sprint.
Or if they're estimating product backlog items with the Fibonacci sequence, as teams commonly do, a 13-point item would be the largest they would bring
into a sprint To understand why large items create problems, consider a recent experience I had at a hotel.
My room was on the 15th floor.
That floor also had a handful of meeting rooms, each of which looked to hold around 20 people.
One afternoon, I left my room and went to the bank of elevators.
Unfortunately, this was seconds after all those meeting room's disgorged their attendees.
I found myself waiting for the elevator with perhaps 70 other people, Those elevators, each with a capacity of around 10 people,
were not designed for a sudden need to transport 70 people.
They were designed instead to transfer individuals or groups of 2, 3, 4, or 5. Your sprints are like that elevator.
It's very effective when you load your sprint up with set of small items.
Put something large into a sprint, though, and work can back up, just like passengers waiting for an elevator!
If you are ever considering bringing something equal to half the team's velocity into the iteration, my first recommendation is to attempt to split the
item into smaller items.
Now, if you can't split it, bring the large item in the sprint, but balance its largeness by bringing in some much smaller item.
Doing so will smooth the flow of work from one skill to another, such as from programmers to testers.
While an item up to half the team's velocity is okay on rare occasions, on those occasions adding a second item that's equivalent to a third or fourth
of velocity would be a red flag.
Danger.
Keeping things smaller will smooth the flow of work through the iteration.
What's the biggest size of item you allow into your iterations?
Have large items caused you any problems?
Please share your experience in the comments.
I read every comment, and I may make a new video about some of the problems you mentioned.
If this video has been useful, click the like button.
And if you're new to the channel, subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching, I'll see you next time.

How to Target the Ideal Number of Sprint Backlog Items per Sprint

Transcript

My team averages finishing three items per sprint.
Does that sound about right?
I was asked this question in a class, and before I could answer, another participant yelled out, only three item?
My Team does 80. He wasn't bragging, he was just shocked at the discrepancy.
Well, which is better?
Three items or 80 per Sprint?
Hi, I'm Mike Cohn, and I am the author of three best-selling books on Agile and Scrum.
I help teams succeed with Agil.
And success comes a lot easier if you target doing the right number of items in a sprint.
Fortunately, teams aren't restricted to doing only three or 80 items.
Somewhere in the big gap between those will be a better answer.
In this video, i'll give you a very specific number items your team should target.
But let's start with a couple of reasons why doing three product backlog items per sprint is too few.
First, if you follow a no partial credit rule for velocity, as I recommend, a team doing so few items will have a highly variable velocity.
If the team narrowly misses finishing one of three items, velocity will be a lot lower.
The impact of missing one-of-three items is a whole lot greater than missing 1 out of 80 items.
And in the next sprint, if the teams gets a little lucky, they may finish their usual three-items and the little bit of work left remaining on that unfinished
item from the prior sprint.
Velocity then in that sprint will then be much higher.
Targeting very few items per sprint tends to make velocity highly variable.
A second problem is that large product backlog items lead to large handoffs between team members.
If a programmer is coding something huge, it may legitimately be a couple of days before that programmer feels ready to hand a preliminary version over
for partial testing.
Contrast that with a team doing 80 much smaller items.
Programmers on that team will be consistently passing things along to be tested, even if they wait until they finish coding each of those very small items
These drawbacks don't mean you should swing to the extreme of doing a huge number of items per sprint instead.
A team doing an excessive number of items in a sprint, like that team that averaged 80, will spend an unnecessary amount of time updating the status of
those items and their backlog tracking software.
Team members will also have to spend extra time coordinating work and managing dependencies on that many items.
Think about how many dependencies could exist among 80 product backlog items.
Contrast that with the number of possible dependencies among only three items, so if three is wrong and 80 is run, what's the right number items to bring
into a sprint?
A while back, I decided I wanted to know an answer to this that wasn't based merely on my opinion, So I surveyed teams I thought were doing well.
I asked them how many items they finished per sprint, how people were on the team, and how long their sprints were.
To avoid the data being skewed by teams that did 80 or 3 items, I looked at median values.
I learned that successful teams were targeting around 2 items per person per Sprint.
I need to be clear that this doesn't mean each team member grabbed two product backlog items and worked on those in isolation so that you have your two
and I have my two.
Now, it just means that the number of items a team delivers in a sprint is a function of team size, which is what we'd expect.
For example, a five-person team would target around 10 items in its sprint, and an eight- person team target 16. An interesting finding was that doing
about two items per person was roughly consistent for all sprint lengths from one to four weeks.
In other words, teams running longer sprints brought in bigger backlog items rather than doing more items.
So how many items should your team target?
First, if you're successfully finishing most work in most sprints, don't change anything.
If not, though, you should consider targeting two to three items per person each sprint.
I'm saying two or three, because I'd rather err on the side of you doing slightly smaller items.
And if aim for three you'll likely still hit the right target range when the team misses an item or two in a sprint How many items per person does your
team complete each sprint and how long are your sprints?
Please share your answers in the comments.
If this video has been useful click the like button and if you're new to this channel click subscribe so you don't miss out on future tips to help you
succeed with agile.
Thank you for watching and I'll see you next time.

Working with Non Functional Requirements & Product Backlogs

Transcript

When we talk about non-functional requirements, we're not talking about features in the menu or user-facing functionality.
We're talking attributes and characteristics, how the system exists in-the-world.
Things like it runs on Android and iOS.
It loads within half a second.
Works in Chrome, Edge, Safari, and maybe Firefox.
It handles 100,000 concurrent users.
And it follows brand standards.
These aren't functionality.
They're constraints.
There are qualities.
The often make or break a user's experience, but they're not always obvious.
Here's the problem.
Non-functional requirements apply across multiple stories or even an entire system.
That makes them harder to define, harder prioritize, and harder test, especially if they are vague.
Be fast means nothing.
Respond within half a second with 100,000 concurrent users, that's actionable.
And because NFRs are not attached to any one story, they often get ignored until they blow up, slow performance, cause security issues,
fail to support a browser, you name it.
Here's a better way to handle them.
Start by creating a user story to come into compliance.
then once you've got it working, add that requirement to your definition of done so you stay in compliance.
Let's say you support Chrome Edge and Safari.
Eventually, you want to add Firefox.
To ensure you don't forget to do that, write a story.
When I visit the site in Firefox, it works.
when that story bubbles up in priority, do the work to implement it.
Then update your Definition of Done.
Supports Chrome, Edge, Safari, and Firefox Another example, maybe you support English, German, and Spanish.
You want to add French.
you begin with a story, as a French speaking user, I want it to interact with the site in my preferred language.
Again, As it becomes a priority, it's worked on and finished.
Then you update your definition of done again, supports English German Spanish and French This approach works because it enables adding support for new
non-functional requirements to a product, but also helps a team remember ones they need to continue supporting.
So remember, nonfunction requirements are about how your system exists in the world.
Start by writing them as user stories.
Then as each becomes a priority, do the work to come into compliance with that story.
Finally, add each to your definition of done.
If this was helpful, hit like, subscribe, or drop a comment with how your team handles non-functional requirements.
See you next time.
So remember, nonfunction requirements are about how you system exists in the world.
Start by writing them as user stories.
Then as each becomes a priority, do the work to come into compliance with that story.
Finally, add each to your definition of done.
If you'd like more help working with user stories, download my 200 User Story Examples PDF.
It showcases the good, bad, and ugly user story from one of my early Agile projects with comments from me now on how I'd improve some of those user's stories
if I were writing them today.
You'll find the link in the description.
See you next time.

How User Story Maps Become Product Backlog Items

Transcript

A story map shows a sequence of steps users perform and alternative ways users can perform each step.
Cards on a storymap can become product backlog items in three different ways.
First, any one card on the map can turn directly into a product-backlog item.
If we're building an app or site that collects payments, for example, we may have a card that says, Pay with American Express Card.
That's a Product Backlog Item.
Second, because a column of cards represents different ways of doing something, the entire column can become one product backlog item.
If our map has a Column of different Ways to Pay, that Column can Become one big Product backlog Item.
Finally, a Sequence of Colums can Become one Big backlog Item.
On an e-commerce site, users can search, save items to a wishlist, check out more.
Wishlists will span multiple rows and columns.
it could become one large product backlog item.
This is a good idea if you won't develop that feature for a while.

Estimating

Build practical agile estimating skills with story points, planning poker, triangulation, velocity, and techniques for making useful forecasts without chasing false precision.

Agile Estimating Explained — Story Points and Planning Poker

Transcript

OK, let's go ahead and get started.
We're going to talk about agile estimating this afternoon.
Actually, that's a little bit of a mistake.
I'm going talk agile-estimating.
You're gonna do it, OK?
So we're have a lot of exercises interspersed in this one.
And I know we have full day like this.
It's really hard with these one-hour sessions to do much actual hands-on or activity type of things.
But we are going do some of those in the session in particular.
So I want to get you to make sure you have some practice estimating.
So here's our agenda.
Here are the four topics we're going to talk about.
Start out with kind of what is agile estimate and planning?
What are we after here when we call an estimator planning approach agile?
Second thing we'll talk is something called story points.
We'll talk about something called ideal time.
These are the two units that agile teams use for estimating.
They'll use one or the other, story points or ideal-time.
Then we'll get a chance to practice some estimations with a technique called planning poker.
So I'm going to want you to get the chance practice this.
We've got three exercises, I believe, interspersed through these four activities.
Let's see what agile planning is all about.
Agile planning is about separating the planning process on projects into two layers.
We're gonna have one layer of planning, estimating planning at a high level, where we plan something like a release or a three month time horizon,
a six month horizon.
Even pretty successfully up to about a year out into the future.
So we're going to have approach that we use for that longer term planning and then we'll have a second approach that we use when we're planning what Scrum
teams call a sprint, what other Agile teams might call an iteration.
So two different types of estimating and planning going on.
We're going to plan our projects at two levels.
What we'll start out talking about is this product backlog thing over here.
A product back log on an Agil project is meant to be the high level features.
So if we decide to compete with Excel, we're going to write a spreadsheet product.
We're gonna have high-level features like add pie charts, add spell checker, or add mathematical formulas, right?
Add text string-oriented formulas.
Things like that.
Be able to format cells for currencies.
So those will be the type of things that we would have as features, big items on a product backlog.
Some of you will know those might be called user stories on an agile project.
So that's what we're going to be talking about right now is how to estimate those type items.
What I'd like to do to start with is to have you get a little bit of practice estimating something.
what I would like you to is estimate two things.
I like have to you estimate how long it would take to drive from right here to downtown Paris.
Let's go to the Eiffel Tower.
Might as well go somewhere scenic.
So let's to go the the eiffle tower.
I'd like you to estimate driving from here to there.I'd also like to you estimate how long it would take to read the last Harry Potter book.
Now don't cheat and look it up on Google Maps or Amazon or something.
Because there's no test coming here.
I don't care about your answer.
What I care is that you learn something about real-world estimating.
Learn something real world estimatting here, so we're going to use these as a couple of real word activities.
OK?
I think the best way to do this is going be to this in small groups.
So I'll let you kind of turn backwards and forwards and stuff and form up into just some little discussion groups and think about it.
And I'm not going insist that come up with an exact mandated answer, consensus answer for your little group of five or six people.
but we're gonna do a couple exercises later where groups are gonna be necessary.
Wouldn't really need to do this in a group, but it'd be a good way to start out as some groups, okay?
So I'm gonna ask you to estimate these in groups.
While you're doing that, I wanna pass around a sheet of paper that we'll use for exercise later today, later this afternoon.
So go ahead, estimate those two things.
Driving to Paris, Harry Potter book.
I'll pass her on some sheets of papers for the next exercise.
Okay, so give that a try.
You don't need to do the sheet of paper now, that's just for later.
So just estimate these two things for now.
Okay.
Give you a lot of time to talk about that, but enough to just get started here, perhaps.
Somebody shout out an estimate for Paris for me.
Help me out.
How long do you think it's going to take to get to Paris?
Two days, 20 hours?
A week?
I haven't thought about it.
Maybe that's the scenic route.
Plenty of places to stop.
I guess it depends how we get down to Copenhagen or something.
Take the ferry.
All right.
Somebody give me an estimate on that.
Ten points, okay?
So we got somebody who knows where we're headed with the points here.
And that's actually an interesting point to raise here right now.
Telling a boss or customer, I'll be done in ten points doesn't help, right?
Tell me, oh I will be reading the Harry Potter book in 650 pages.
Doesn't help, right?
So that may be an intermediate step.
That's part of what we're gonna build up to here.
We're going to use this as an immediate step, perhaps thinking about how many points something is.
And I'll explain what a point is, I know we don't all know right now.
Let me get another couple estimates on the Harry Potter book.
Anybody over here Harry Potter?
15 hours.
20 hours?
Let's get one more from over there.
A year.
I can beat that.
I've been reading the fourth book for about four years.
The way you might have come up with one of these estimates is you thought about having done something similar.
And I remember when I read the fifth.
That was when it was on holiday.
I was here and it's about a week.
Probably read two hours a day, I'm going to say 14 hours.
So you might estimate by analogy, by comparison to something else.
I've never driven from here to Paris, but I remember the one time when I drove from Trondheim down to Rome.
That's longer, so let me subtract a certain amount on each end.
Estimation by analogy, it's a good practice.
Another thing you might have done is you thought about the size of the work.
I'm just gonna pick some easy math here.
You might have said the book is 600 pages, looks like about 600 to me.
I bet I read 40 pages per hour, 600 divided by 40, I am done in 15 hours.
All right, so you might've done some math like that.
In doing that, what we'd be doing is something like this.
Estimating the size of the work as a single step, deriving the duration as separate step.
I teach a full day class on estimating.
When I do, I tell that class there's five words I want them to memorize.
I'm going to give you right now for free four of the words.
They're on the top of this screen right.
Now I don't know if the fifth word will come up today.
Maybe you got to take the class just to learn that fifth.
But four other words, 80% of whole class that I am teaching when I teaching estimator class for a day, the benefit is to get people to realize estimate
size derived duration.
Do these as separate steps.
The Harry Potter book is 600 pages.
That's an estimate of size.
Driving down to Paris is, I don't know, 2,000 kilometers.
This takes some 3,00 kilometers, right?
I take some guess at how big that is.
And then as a separate step, i will derive the duration.
I might derive duration by reading Harry potter for one hour.
Okay, in one our I read 40 pages, do the math, and I'm done.
Right?
Those of you who know Agile will know we call that something called velocity.
I might start out the drive to Paris.
First hour's not going to tell me much, because I'm going be sitting in my car on a boat.
But the second or third hour, I may start to get enough data that I could figure out, OK, here's how long it's going take.
So we're going estimate the step.
We're to drive the duration.
Now, we want to talk about two units.
I had them up there earlier, Story Points and Ideal Days.
I don't want to introduce either one yet, so I'm just going to toss up an example this way.
We might think about the number of kilograms a project is.
Now, this is totally silly, right?
Weigh the spec, and it's 300 kilograms.
It would be a very big spec.
We find at the end of the first sprint, the iteration, we've done 20 kg.
We could divide that out and say we'll be done in 15 iterations.
That's the concept.
I know it's silly with kilograms.
Now this idea of estimating size-deriving duration is not new to Agile.
I wish we agile people had made this up.
If it wasn't me, I'd wish it was one of my other agile friends, Esther Derby who was in here earlier, Bob Martin who's giving great talks at NDC this week.
But it's been around since the traditional days.
In the tradition days, we've had alternative approaches to estimating size, though.
We've thought about things like lines of code and function points.
Now, we can all make fun of lines of code as a measurement.
We know it is a bad measurement, but it's literally true.
IBM, I think it was in the 70s, actually offered a bonus to the programmer who wrote the most lines a code.
This sounds silly today.
So lines are code, not a good measurement of size, But it a start.
If, for example, I asked you to rewrite a program for me and I said, you could rewrite one of two programs.
One program is 100 lines of code, the other program's a million lines a code.
And we all know we choose the 100 line program, right?
So lines of code, not a good measure, but I mean, it's something.
With a gross margin of error, that's a start.
So it was there.
It was OK.
Function points, something that we tried in traditional software development.
function points were meant to be a measure of the number of inputs and outputs and data tables accessed, things like that.
Well, the more inputs now outputs to a program the bigger the program is.
These are measures of size.
They didn't work out too well.
In Agile, we do it a different way.
We have these units, story points and ideal days.
I had two different units.
So I want to start out with storypoints.
Let's see what storypoint are all about.
Storypoints are a relative measure of size.
They are absolutely an estimate of how long something will take.
Some people try to make story point harder than they should be by renaming them.
They'll call them complexity points.
Maybe story point sounds too silly.
Sounds like something you do when you're eight or something like that.
So it's got to sound fancier.
Let's call it complexity point.
And this is a mistake.
This is mistake, I don't want you to do this.
Story points are still about how long something will take.
Complexity is factor, but it is not the only factor.
Now let me give an example.
Suppose we go outside.
It's a beautiful day out there.
I took a chance during lunch to walk out and just enjoy the day for a few minutes.
So we got outside, and there is a building over here on my right.
And I point to that building and say, that build will take us one unit of time to walked to.
Don't mean one minute or one hour, just one of unit time.
That building, over there, is about twice as far, it's going to take twice long.
The building will takes two units of times to get to, We're estimating time.
Now one of the things that's nice about story points is that that relationship is true.
One unit of time, two units of times to get to that building.
For you, you're going to walk there.
You're able-bodied, and you are going walk over there, I'm on crutches.
I have to hobble over on my crutches.
Well, even on my crutches, that building will take twice as long as that.
So one of the advantages here to story points is they let people or teams with different skill sets put the same relative numbers on things.
I like to run.
But I'm a horrible runner.
Suppose one of you is a good runner.
I'm a horrible runner, you and I go out to the start of a trail.
And I say, that trail's 10 minutes long.
You, a much better runner say you're crazy.
It's a five minute trail, and so we argue.
Five, 10, five, ten.
There's nothing you can do to convince me it's five minutes.
Oh, I can't run it that fast.
Maybe I could convince you to take 10 minute, but that's not a real good answer, right?
Maybe we agree on seven and a half.
That's probably the worst possible thing.
Now we got an estimate that's no good for either of us.
So we keep arguing, 510,510. We keep going, and you eventually say to me, Mike, it's a five-minute trail.
It's one kilometer long.
I say, you're right.
Its one-kilometer long, going to take me 10 minutes.
Soon as we put a size on it, we could agree.
And then we look at some other trail, And I'm looking at that trail thinking, wow, that one's going take twice as long!
That trail's gonna take 20 minutes!
And you're looking at it thinking, wow, that trail's twice as long.
It's going to take me 10 minutes.
Well, we can both agree to call that trial a two.
If the first trail is a one, the trail a is two, right?
So story points are still about relative size, not about complexity.
But I said earlier, complexity is factor.
Let me show you what I mean by complexity's a factor, remember our two buildings.
That building's one unit away, and that building is 2 units away.
Behind me is another building.
It's the same distance as the two-unit building.
The same number of steps, same physical distance, but there's train tracks.
And I've got to wait for the train sometimes.
I walk back to that, I go to the building, and every now and then there are train track and the trains going by.
and I'm stuck standing there waiting for a train to go by I don't want to call that one a two then, because sometimes when I got there it takes longer.
Sometimes it's a lot longer, so I'll call it a three.
It's the same physical distance as that building, but sometimes it takes longer, so I'm gonna call it a three.
That's not really an example of complexity, it's an examples of risk or uncertainty being a factor in our estimate.
Complexity, risk, uncertainty, things like that will influence our estimates, they're not what we estimate directly.
I had a class, give me a great example one time, a few years ago.
They said you have a two person team, doctor, brain surgeon, and a little kid.
I don't know why they're on the same team, but they are.
Brain surgeon and a little kid are on a team.
We have a two-item product backlog.
Perform simple brain surgery.
Snip, and you're done.
And lick 1,000 stamps.
Those two items, perform simple surgery, lick a thousand stamps, are chosen to take about the amount of time.
If you disagree, add or remove stamps and make it more stamps if you want.
Those two things should get the same number of story points.
If they're going to take the amount of time, they should the get same the number story point.
Because we make the simplifying but realistic assumption, the right person for the job will do the jobs.
We're not going wait for a little kid to finish school, finish university, finished med school.
Then do their brain surgery, right?
We'll be dead.
So the person right for job, will the do job.
In that case, those two thing get to same numbers storypoints.
Complexity is a factor, but it's not the only thing we're estimating.
Now with StoryPoints, I want the basic math properties to hold.
That always sounds complex.
It's like, oh my gosh, you're talking about math property in the afternoon.
All I mean is stuff like 5 plus 5 equals 10. I what the product owner or key stakeholder on a project to be able to look at it and go,
OK, my team tells me there's room for 10, what do I?
Oh, no, this one 10 point story.
No, I don't.
I want these 5 2s.
No.
no, no.
i want this 1 5 and these five 1s, right?
Anything that adds up to 10 should be about the same size.
That's all I mean by basic math property you should hold.
5 plus 5 equals 10. Either of those should take the amount of time, OK?
These are weird.
Story points are very, admittedly, weird I'd like to have you leave here thinking they're not so bad, though.
So what I want to do is if story points or weird, I wanted to you do something even weirder.
We're going to estimate in zoo points.
What I'd like to have you do is, in the brutal groups you were in before, maybe adjusted by new people who have come in,
or left, what I would like you to do, is estimate in zoo points.
Where a zoo point is a combination of how much of the mass and the volume of an animal.
How much animal there is.
Now a giraffe is pretty tall, but they're kind of skinny things, compared to something like a rhino.
So how many of animals there are.
Mass and volume somehow combined together to make up a total zoo-point.
So talk about this in your group.
Here's eight zoo animals for you.
See what you can come up with in terms of zoo points for those eight animals.
May not have given you enough time to do the whole thing there, but good enough to at least kind of start to get a feel for this.
Did any group get far enough along that we can start use your numbers just as an example here?
Yeah, thank you.
What did you put on our first guy, our lion?
Okay, so lion a one, everybody okay with that?
No?
Woo.
Yeah it's hard to be wrong on the first one.
That's actually a key point, right?
You can only be wrong here in comparison, when he says Lion's a one and Hippo's half.
OK, now we got an issue, but you can't be on the first one.
So let's go with Lion.
We got Lion as a 1. What about a kangaroo then?
OK.
so we're saying here, Lion and Kangaroo about the same overall mass and volume.
Seems OK to me.
You never see them together at the zoo.
I guess if they were together, one would be eating the other.
That's why you never seen them.
What about rhinoceros?
OK, so rhinosceros of five.
Rhinocerous about the same as five lions.
Picture five lion together.
Maybe a little bigger, I don't know.
Seems close.
Bear.
So a bear is a little bit smaller than a rhino.
I was thinking about those Australian guys.
Koala bears.
You're probably thinking of a big ice bear or something, a four.
All right, so here's one of the key things here.
Did everybody know there's multiple sizes of bears, right?
Everybody knew there were multiple size of bear, all right.
So I know koalas aren't really bears.
They're marsupials, whatever a marsubial is.
But I don't know.
I just know they are one.
One of the key things to do here is, if you have something like this, what I gave you was a vague requirement.
I give you a big requirement, one of best things do with the vague requirements, ask your product owner for clarification.
Nobody asked me, and I know it's kind of hard in a group like, this nobody asked, hey what type of bear?
Another thing to, do and here's actually I will give, you the fifth word that I teach in my one day class, use a range.
Range would be that fifth, word.
Anybody remember the first four words?
Something to do with size and duration, right?
Estimate size-derived duration.
What I'm talking about there is estimate how long it's going to take to read Harry Potter by estimating the page count, then deriving the duration by actually
reading for an hour.
Estimating size, derived duration in separate steps.
Fifth keyword of advice, use a range.
So it might have been better off with a bear here saying something like, oh, there's those koala bears.
Let's go with one to four.
Now I won't go through the rest of the numbers here, but I want to mention I forgot to add one animal up here.
And I don't know if he's really a zoo animal.
But I did want put one more up there and forgot type him onto the slide.
Blue whale.
Anybody have an idea what you want?
One gazillion.
There's always a good estimating technique to use a meaningless unit.
And hope your product owner doesn't know.
So I got to share with you an old joke then.
This is a joke you probably haven't heard, because this is joke that was popular in the US about six, seven years ago.
I remember we had President Bush six or seven year ago, and there was a job that he was getting briefed in The War Room that that his secretary of state
was debriefing him on some activity and said, well, you know, overnight we had some conflicts and we have three Libyans died and a Brazilian died.
And President Bush is really sad about these people dying and he goes, remind me again, how many isn't a Brazillian?
Right?
So use meaningless units as one estimating technique.
So this is what a story point is about.
A story is only meaningful in a relative manner.
Five is twice as big as two and a half.
5 is half of a 10. Story points are relative.
I made the point here about the blue whale to point out one key thing about being good at estimations.
No matter what unit you leave here with liking, I want you to be good estimators.
A key step in being a good estimate is to stay within about one order of magnitude.
We could have argued about this, and we could argue about is a tiger bigger or smaller than a lion, things like that.
But there's nothing we can do to put a number on Blue Whale.
It's just too out of the realm here.
All right, we're good in about 1 to 10, one-order of magnitudes.
If we get out one of order magnitude, We are no longer good estimates.
Plenty of studies that show this.
So you want to have the bulk of your product backlog, the book of requirements, whatever you're estimating, be in about one order of magnitude.
You get outside of there, start to get nervous.
Key tip in getting good at estimations.
Now this was probably hard to start with.
It's really hard to start with.
What do we call the first one?
How do get going here?
It doesn't bother me if this technique is hard start because it's easy to continue with, it is easy continue.
Suppose we had our numbers up here, actually let's go with it, what did you have on Tiger?
You had one on Hawaiian, Tiger is probably the same?
Two, so Tiger bigger than Hawaiian.
Okay, fine with me.
what would you put on cheetah?
Or how would you estimate cheetah, right?
You'd look at your other big cats, and you'd make an adjustment from there.
You might say, oh, yeah.
Cheetah's a little bit smaller than a lion.
Let's call it 3 fourths or something.
So we can estimate relatively gets easier over time.
The more items on your backlog, the easier it is.
Because you're not going back to first principles questions.
Your just looking for something similar.
I got cheetah estimated.
Now jaguar comes along.
OK, how big is a jaguars?
Oh, it's about the same size as a cheeta.
Whatever number I put on there, I'll put it on this.
So estimating relatively gets easier over time.
The other unit favored by agile teams is something called ideal time, Ideal time is the amount of time something will take if three things are true.
It's all that you work on, nobody bothers you, and everything you need is on your desk when you get started.
This is clearly why we call it ideal time, right?
This stuff never happens, all right.
But the point with calling it ideal time is to think about how long it would take if everything went well.
Isolate yourself from distractions, interruptions, everything else.
OK, if this is all I did, I could be done with this in three days.
If I drove from here to Paris, could I be there by tomorrow night?
Well, I'm not going to get there by tomorrow night.
I have to stop some bio breaks, some meal breaks.
So let me make it this long.
How long would something take if that's all we did?
The best example I can give for ideal time is to think about something like American football.
Now, I know everybody here has not seen that, so I won't use that one.
But if you have ever seen an American Football, start to kind of mentally switch this example to an America Football game,
and you'll see why it's such a great example.
I'm going to actually use my favorite sport, which most of you, for sure, have seen, basketball.
I love basketball.
So if we think about a basketball game, if I were to go to a baseball game and I tell my wife, I'm going to the game.
International basketball games is four 10-minute quarters.
I'd tell wife I am going the basketball, game I will be back in 40 minutes.
She's going to be a little mad when I come home two, two and a half hours later.
So that game is not going be 40 minutes long.
Clock stops, all sorts of things like that.
Now, football, this isn't the best example because the clock kind of keeps running.
But American football.
Those of you who have ever seen a game know the clocks stops all the time.
The American Football game has 60 minutes of actually playing time, players are running around for 60 minute, but the game takes three and half hour.
At a basketball game, they're running for 40 minute but they game take two hours.
So we can say the ideal time of a basketball game is 40 minutes, but the elapsed time is longer.
The elapse time, it's more like two hours.
So, we have a difference here between elapes and ideal times.
I might look at it and say my Monday work day has eight hours, my work week has 37 and a half or 40 hours but that's not what I'm going to get.
I'm going to come in to work, and I have to answer email, do all sorts of other things, meetings.
So there's a relationship, a ratio here between elapsed and ideal time.
They're not going be the same thing on a project.
Now when we estimate in time, this actually creates some problems, because sometimes your boss walks in and says, when will you be done?
Or I say, how long to read the Harry Potter book?
And you say 20 hours.
Wow, 20 hour?
You're going have your hands on the book for 20 No, no, I meant I'll be done 20 hours from now, because I also got to sleep tonight and things like that.
So we've got be careful with time as an estimating unit, Because sometimes the boss or client is asking for an elapsed time estimate,
and we're giving back an ideal time estimates.
There's a little bit of room for confusion there.
We've gotta make sure we are using the same unit.
This is back to that point about estimations, size, driving, duration.
Sometimes we were being asked for estimate of size and give back and estimate duration, so it causes confusion.
I like story points.
Most Agile teams use storypoints.
A couple of key reasons why I liked story point.
Story points are additive.
Time is not.
This is back to the example of you and I going out for a run.
And I say it's 10 minutes, you say its five minutes.
If we put your estimate on some things and my estimate other things, we can't add those up.
You're estimating in your time.
I'm estimatin' in Mike's time, they're not the same.
Story points are additive.
They let people with different skill sets use a common unit.
We can both agree that running that trail's one point, running out of their trail is two points.
Another advantage with story points is they help avoid a problem with what I call unit confusion.
Let me show an example of what mean by unit conclusion.
Suppose we have this.
I had this picture up here earlier.
We had a product backlog, and we had an iteration or sprint backlog.
If we look at that product back log on the left, we've got the 30, the 50, to 50. And then we run a sprint or iteration.
The team turns the work into the working iteration, And they estimate the hours they run the sprint iteration on their right.
When we get to the end of that first iteration and somebody says, When will we be done?
When we'll we done.
Well, let's do the math.
Let's figure out when we're going to be.
Done we figure.
Out how many hours are left on the project we add up the numbers on.
The left 50 50 20 and 20 that 30 is done so we just add.
Up the other four we said we got 140 hours left.
On the.
Project okay well how long does it take us to 140. Hours we.
Add up.
the Numbers on their right 12 plus 8 plus 4 plus 6 plus 5 we had that up it equals 35. I've obviously contrived the numbers here to make the math easy.
I divide 140 by 35, and I say we'll be done in four sprints or four iterations.
No.
It's wrong.
What we're doing there is bad math.
We're literally dividing apples by oranges.
All right, we are doing bad maths.
Those numbers on the left, let's not call those hours.
Let's call them hours we pulled out of the air.
Because a team, on average, is going to spend two or three minutes estimating those.
In a couple minutes, I'll show you how.
A team is gonna spend 2 or 3 minutes estimated those anybody who's ever done a Scrum or Agile project knows sprint and iteration planning,
long and painful.
So let's not call the hours on the right hours.
Let's call those hours we thought a lot about.
Those are painful We cannot divide hours, we pulled out of the air by hours We thought about, it's different numbers.
If you're experienced with adjunct, you might have noticed the little trick or the problem that's occurring here.
I have to be consistent in the units that I use.
If I say we have 140 hours left, that a true statement.
On the left it's 140. But I need to divide that by something.
And I don't divide it by the 35 that get by summing up the things on the right.
Anybody know what number I should divide by?
The 30 on left.
The 30 on the left turned into 35 hours.
But before I got into that work, I thought it was only 30 hours, right?
Well, before i get into the 140 hours of work I think it's 140. I bet it is going to expand too when we go to do it.
So we have to use consistent units.
Now when use story points here instead of hours or days, when you story point here, we change those to points, We're not likely to do bad math.
Somebody's gonna add this up, and they're gonna say, okay, when are we done?
Okay, let's add up the numbers on the left.
We got 14 left, how fast do we go?
Well, we can go 35 hours.
14 points divided by 35 is, whoa, I can't do that.
How about 14 point by three points?
Oh, it will be done in five sprints.
I maybe seem like I'm making an esoteric point here.
It's actually a key point, because when I see this, They're almost always one to two sprints late in delivering their project,
because work expands when looked at in detail.
That 30 later turns into 35. So I want to get a chance to practice estimating here with a technique called planning poker.
Planning poker is a consensus-based approach to estimatin, very loosely based on wideband Delphi approach, which came out of the Rand Corporation in the 1940s.
The idea here is our product owner walks into the room, reads a user story or product backlog item to the team.
Team members talk about it.
Each team member is holding a set of cards.
We'll pass out a bunch of card so you have some to do this.
Each teamwork is a holding bunch a cards with the estimates on there that we have pre-agreed to use.
Remember we're outside.
That building is one unit away, that building's two units away.
I point to another building off in the distance and I say, That buildings is 17 units way.
And you tell me, no it's not.
It's 18 units a way What a crazy debate.
17, 18, 17 18. Who cares?
We're not going to be right.
We can't distinguish those numbers.
They're too close to one another.
So we're going not to use both of those number.
If we pick one, we wouldn't use the both.
All right?
So the way planning poker works, each person has a deck of cards.
Each person listens to the product owner or key stakeholder.
The pick a number indicating their estimate.
all at once, the estimators turn their cards over.
if every estimator has the same number, write that number down.
we are done.
If we don't, the outliers talk about it.
They argue.
Here's why it's big.
No, here's it small.
Let's say we get them in the room, and they start estimating.
And we'd get, in this case, two fives and eight and a 20. I would ask the outliers, I'd ask Johannes, why a twenty?
Oh, this is going to be huge, i'm going have to do such and such, it's going be hard because of this.
and I ask Anna Ertrond, Why a five?
What's gonna make this easy?
And they'll tell us why it is gonna be easy.
The next round.
People change their opinions.
We get, in this case, three 8s and a 13. I'd ask Johannes again, come on, you're the high number.
Why?
Convert us.
Give us a reason to convert.
All right?
I was with a team recently in Atlanta in the US.
They had all 8's 113. The guy with the 13 gave the reasons.
In the next round, everybody switched.
So notice it's not a vote.
we don't, this in case say the 8 win.
You repeat until we come to consensus.
OK?
The consensus may be a little false.
A couple more rounds after this, Johannes may say something like, You want an eight?
Here's your blankety-blank eight.
He'll probably add something like, but remember this day.
Some of you have worked with him.
Reserving the right to remind us when he turns out to be right.
So I don't need him to go to his grave defending an 8. I do need to fold eventually and go, OK, you guys have heard me, I still think it's bigger,
But I'll go with an eighth on this.
We've got to get to team consensus.
Yeah, so the question is do I go to an average?
This is always a tough one for me.
I'm okay with you doing that, okay?
I totally am.
Here's the problem.
Each team has to figure out a way to come to agreement, right?
i don't want to be the one to say, hey, everybody in the world, here's how you should do it.
Some teams choose after three rounds, they pick the high.
Other teams after two rounds or three runs, the pick low.
other teams will pick average.
I do want to caution you a little bit with going with the average, because I think a big part of the benefit here is the fierce debate and the arguing
and trying to convince each other.
And some teams find it just too easy to just, OK, we'll just go with average and they miss out on a lot of debate.
It's not that the debate is that great, it's that debate what brings out all the hidden assumptions.
I think it's big because we have to do this.
Oh, I hadn't thought of that.
You're right.
It is bigger.
And so I don't want to cut that debate short.
So if you feel like your team is still having good debate, this is a quicker way to end.
I'm fine with it.
Right?
So I want to give this a practice try here.
Here's my recommendation, two tips.
One tip and one recommendation.
Think of the numbers as buckets of water.
OK?
I'm going to you cards here, you can see the number I am going give you up here?
For example, an 8 and a 13. Maybe even better, buckets a beer, right?
If I give an eight and 13, and you've got a backlog item, if you want call a 10, The 10's got to go in the 13, right?
Imagine you have an 8-liter bucket and a 13- liter bucket.
You've got 10 liters of water.
It's gotta go into 13 liter buckets.
So we're gonna have a slight rounding up, a slightly pessimistic bias, we would call this in estimating world.
Slight pessimist bias here.
Now here's my recommendation on how to get started.
With the zoo animals, I didn't care.
There was not very many of them, it didn' t matter.
Here's recommendation in real world, look for a 2, Look for 5. Right?
Remember, we're only good about 1 to 10. I'm going to consider 13 to be close enough to honorary member of order of magnitude.
But we are only going across about one to 13. So look for a 2. Look for 5. Don't necessarily play planning poker on those.
Just somebody on the team says, that one's a two.
Okay, or you're crazy, this other one's a two.
Once you find your two, look for a five, something about twice as big.
Then kick in with planning poker.
So I want to give us a chance to try this.
We don't have a lot of time, we'll do this for about 10 minutes, so we will just wrap up for just a minute at the end.
I'm going to pass out a bunch of planning cards, I've got big boxes of them.
Everybody take two boxes, that way when you go back to your team, they'll have enough for eight people, plus we'll add extras up here.
But everybody take to boxes as we get these passed around quickly.
I've got your back log on the next slide, it's also what I passed it around, so you have it on a handout, because you might need to write some of the numbers down,
unless you got a good memory to remember them all, okay?
So, form back into your groups, look for a two and your five, while you're doing that, I'll pass around a bunch of cards,
everybody takes two decks out of, two box out here, OK, let's come back together just for one minute to wrap things up.
Apologize for taking it right up to our one hour limit.
Hopefully that went OK.
Planning poker is really tough the first 20 minutes or so.
So this probably didn't start to feel real good yet.
But I do encourage you to check this out as a technique back in the office.
I think this is a great way to do this.
Two last things here.
My got tired of not having a good answer for distributed teams a while ago, so I programmed up and got one of my My programmers,
to help me, we build a website for distributed teams.
You'll log in here, you get a private URL, and you can share it out with your team.
All the cards flip over at the same time, so nobody can cheat.
Makes it nice.
So check that out if you've got a distributed team!
I'm back here every three months or so doing training sessions for Programming Up to Clean.
If you're interested in Scrum or Agile stuff, I'll be back every few months.
Thank you all very much!

Planning Poker Explained: How Agile Teams Estimate Story Points

Transcript

So let's talk about how to pull all these ideas together into an estimating approach that works.
The technique is called Planning Poker, and it's loosely based on the Delphi and Wideband Delphin approaches that date back to the Rand Corporation in
the 1940s.
In Planning poker, each estimator, which should be everybody on a team, is holding a set of cards that contain the numbers the team has agreed to use as
their estimates.
Normally this will be the modified Fibonacci sequence, but that's really up to team.
The product owner reads a product backlog item, usually a user story to the team.
The team and the productowner discuss the item.
Team members ask questions.
the Product Owner clarifies expectations.
This can be as short as a few seconds, but it can take as long as needed.
Once each team member has decided upon an estimate, they pull that card out of their hand, holding it so no one else can see it.
When everyone has picked an Estimate, the cards are revealed all at the same time.
If everyone is holding up the same number, we're done.
Write that number down as the estimate and move on.
But if the numbers are different, We discuss it and then estimate again.
Let's see an example.
During the first round, our estimators hold up a 3, 8, a 2, and a 5. At this point, I really want to hear from the outliers.
Why an 8? Why a two?
Anybody can talk, but in this case I would really like to know from Vadim and Anne.
Vadim might say, well, I'm the tester on this project and this is going to be really hard to test.
I need to build a new test framework, and so on.
Anne says, Well, Vadem is right.
My 2 is too low, so I am going up.
But I've programmed this type of thing before and it's not that hard.
So I m coming up, but not all the way to an 8. Anyone can talk at this point, but I especially want to hear from the outliers.
After anyone who wants to has had a chance to talk, each team member again picks a number from their cards in their hands,
and then all at once, the cards are revealed.
This time, let's say we get three fives and an eight.
At this time point I'd ask Chris with his eight to give us an impassioned plea for why eight is the right estimate.
I was with a team a little while ago that had all eights except for one 13. I asked the guy with the 13 why.
Boom, boom, Boom.
He gave three good reasons why he thought it was a 13 and on the next round, everyone switched to agree with him.
So notice this isn't a vote.
We don't say that the majority rules and pick a five.
We keep going until we get to a consensus.
The consensus may be a little false, but that's okay.
Suppose we go another two or three rounds, with Chris holding up an eight while the rest of us have fives.
At that point, I'd probably ask Chris if he thinks we've heard his arguments but we just disagree.
If he does think we heard him, he will eventually fold and hold up a five.
I'm okay with Chris folding.
After all, the difference between 8 and 5 isn't that great, and we're pretty far up the effort accuracy curve we saw a few minutes ago.
Now, if Chris had been holding up a 100 instead of an 8, I wouldn't want him to fold.
If we are that far apart, we probably are facing one of two problems.
One, product uncertainty, which is the product owner saying something like, good question, better run that by some users,
it could go either way.
Or two, technical uncertainty.
which is when the team thinks that doing the user story will be easy if they use one particular technical approach, but hard if take another approach.
So whether it's product uncertainty or technical uncertainty, if the estimates are hopelessly far apart, put the story aside,
do the research, and then estimate the users story next week or whenever you get together again.
Or consider using a range if reducing the uncertainty will take more effort than you want to or can invest.
If team members ask the product owner what type of bear, koala bear or grizzly bear and the Product Owner can't say, your best option is to write down 5
to 100. One challenge with relative estimating is how to get started.
My recommendation is for team members to look at the product backlog and find something they want to call a two.
Don't play planning poker quite yet.
Just find a 2. Something small, but not the smallest.
I don't want you to waste time doing a bubble sort on your product back log, looking for the small item.
Instead, someone on the team points to one user story and says, that one's a Two.
Team members can argue if they disagree, but they keep at it until the team finds one user story that everyone can agree is a two.
Then, look for a five.
Remember, we're only really good across one order of magnitude, so finding a 2 and a 5 establishes us a good baseline across most of that order or magnitude.
I don't really care if you find a two and a five.
Maybe find one and five, or a 2 and an 8. Any of those is fine.
The idea is just to get a pair of numbers that everyone agrees on and then start playing planning poker.
I want to mention briefly that if your looking for planning cards, we do sell the cards at our cost on our website at store.mountaingoatsoftware.com Also,
we have a free website you can use for playing planning poker with a distributed team.
In the next video, We will look at some of the reasons why planning Poker works.

7 Agile Estimation Techniques Every Scrum Team Should Know

Transcript

I hear from a lot of teams that they struggle to estimate well.
Often these teams will attempt to improve by trying harder.
They don't identify problems in their approach and systematically fix those problems, they just try harder I'm a mediocre chess player,
I am not going to win more games by just trying hard.
To win games I need to identify where I was weak and then work to get better in those areas.
A team trying harder to estimate well won't change much.
And eventually, the futility of trying to get better by only trying hard becomes demotivating.
At that point, some teams throw their hands up and take an attitude that estimating is impossible, so they won' t try.
Estimating isn't impossible but it is challenging.
Instead of giving up, try things that will help your team estimate better.
In this video, I'm going to share seven tips for getting the best estimates of story size.
If you know me, you probably know I'm a big fan of estimating in story points, which are an abstract relative measure of effort.
I've definitely got storypoints in mind for these tips, but the tips can be applied just as well if you estimate in more traditional units,
such as person days.
Our first tip is to make sure everyone agrees on the type of estimate being provided.
If you are giving a really conservative, safe estimate, but I'm giving the best-case estimate we're almost certain to disagree.
This tip fundamental.
if your team doesn't talk about what type estimate you're making, the only way team members will agree on estimates is by luck.
There are five general types of estimates a team can provide.
Let's take a look at each.
This chart shows the likelihood of being done at various times.
The general shape of the curve indicates that there are not a lot of things you can do to finish something much earlier.
But the long tail indicates there ARE a LOT of thing that could go wrong to really make something take longer.
The highest point shows the single most likely estimate.
This is one of the five types of estimate a team could provide.
To the left of most-likely estimate is the ideal case.
That represents something like a 10% chance of being right.
Pretty much everything has to go perfectly for a teams to finish in this amount of time.
Next is median estimate, the 50-50 estimate – the team is just as likely to be finished early as they are to finished late.
Finally, we've got a risk-averse estimate out to the right.
This is the reverse of the ideal estimate, but the team has a 90% chance of beating the risk averse.
And way out there is a worst-case scenario.
Team members probably won't estimate this conservatively, because that represents everything going wrong while working on an item.
Where on this chart should team members estimate?
I think the median is best.
I thinks it's easy for estimators to conceptualize.
It's the point where something is equally likely to take more or less effort.
But the most important thing is to have that conversation with team member, so they're in agreement about which type of estimate the team wants to use.
Gaining this agreement gets rid of a lot of frustration team numbers feel when they have what seem like futile disagreements over an estimate.
Our second tip is to estimate relatively by analogy.
If you're ever in an estimating meeting with me, you will never hear me ask, how long will this take?
Instead, I ask questions like, what other backlog item is this like?
Or will take more or less time than this other item?
Estimating relatively can be done more quickly, especially once a team has built up a large base of items to compare against.
There's also some evidence that relative estimation by analogy is more accurate.
Third, keep most estimates within one order of magnitude, such as 1 to 10. Research has shown that we're actually not that bad at estimating items as long
as we stay within 1 order or magnitude.
If you need to estimate outside of an order magnitude and there can be good reasons for doing so, build up to that gradually.
Estimate a dozen or more items all in the 1-10 range, then start reaching a little larger.
Don't estimate some items from 1 to 10 and then go right to estimating something at 100. Instead, estimate a few items that are a little too big,
perhaps up to 20, then maybe move up 40. Keep in mind though, in many cases, you'd be better off splitting work this big into multiple smaller items and
estimations those instead.
A fourth tip is to avoid getting too precise.
It's obvious you don't want to estimate something as 3.47 story points, person days, or whatever unit you're using.
Less obvious, though, may be that you probably don' t want use 3, 4, and 5 as valid estimates.
it's unlikely team members can distinguish between numbers this close to one another.
My local pizza restaurant offers pizzas in three sizes, medium, large, and grand.
That's enough.
I can tell the difference between those three size.
If they offered me pizzas of 15 different sizes between medium and Grand, I wouldn't be able to tell that difference.
So don't get too precise.
Use a smaller set of numbers that you can distinguish.
This is why the Fibonacci sequence and powers of two have become popular estimated sequences.
And just as when ordering a pizza, round up when team members are debating between two sizes.
If you're trying to decide between a medium and a large pizza order the large.
if the team is torn between four and eight, go with the eight.
Odds are there will be some unanticipated work involved that will push the item towards the higher number once the Team gets into working on it.
Tip number five is to triangulate your estimates.
This term comes from old sailing ships.
A ship's navigator could figure out the ship location by looking at two objects at different points on the horizon and drawing a line from each on a map.
The intersection of those two lines would be the ships location.
We triangulate estimates by comparing an item being estimated to at least two other estimates, ideally one that's larger and one the smaller.
For example, if we're thinking of estimating something as five, you want to find perhaps a two and an eight to compare against.
Ask the team if the proposed five seems about twice as big as the two, and a little smaller than the eight.
If so, You've got confirmation that five is a good value for that item.
Often, though, team members will want to change the proposed value based on the triangulation.
If so, great.
Triangulating has helped improve that estimate.
Tip six is to avoid anchoring.
Anchoring refers to providing information to estimators that may unduly influence the estimates they're about to make.
To understand anchored, imagine you're in a store and you see a shirt that was previously $40, now on sale for $20. The mention of $ 40 anchors you into
thinking the shirt is worth that much.
Logically, who cares what price a sure used to sell for?
Your purchase decision should be based solely on the current price, but that old price gets in our head and influences us.
One of the advantages of estimation approaches like Planning Poker is that each person provides a first estimate free from anchoring by others.
But anchoring can occur in subtle ways.
A product owner may start an estimating meeting by saying something innocent sounding like, this meeting today should go fast.
I only have five items that need estimates, and they're all pretty small.
Saying the items are pretty small gets in estimators' heads.
And it's been shown that phrases like that can unduly influence estimates.
So to get the best estimates possible, coach people not to say things like during estimating meetings.
Tip number seven is to avoid settling disputes by choosing the middle value.
A human bias known as the central tendency of judgment shows that we tend to favor estimates perceived as being in the center of a scale.
If, for example, a team estimates with a Fibonacci sequence, one, two, three, five, eight, and 13, it's likely that the Middle values,
3 and 5, will be overused.
The same effect can be present when team members are debating a value, someone will suggest settling in the middle as a compromise.
While the Middle Value may absolutely be the best estimate, don't settle there without sufficient thought.
Encourage the estimators with the high and the low values to make a case for their values before agreeing on the middle estimate.
Estimating well is challenging, but don't throw up your hands.
There are steps you can take to become better at estimating.
I've shared seven such tips in this video.
What other things have you done to improve your team's estimates?
Please share your thoughts in the comments because I'd love to read them.
And if you're interested in understanding or helping your team understand StoryPoints, check out our Estimating with Storypoints video course.
The link is in the description.
If this video has been useful, click the like button.
And, if your new to the channel, subscribe so you don't miss out on future tips.
Thank you for watching and I'll see you next time.

The Easy Way to Estimate Quickly and Accurately

Transcript

What should you do when the estimate you want to assign is between the values your team has agreed to estimate with?
When estimating with story points, most teams use a predefined set of values that does not include every possible number.
For example, teams commonly use powers of 2, 1, 2 4, 8, and 16, or a Fibonacci sequence, one, two, three, five, eight, 13. By intentionally leaving some
numbers out of the set of acceptable estimates, team avoid bogging down in discussions of, for example 15 versus 16. Estimating to that level of precision
would be extremely difficult and time consuming, most likely not even possible.
But what should you do when you think the right estimate is not one of the teams agreed upon values?
The answer comes from thinking about water buckets.
Suppose you have 10 liters of water you need to store.
You also have an 8-liter bucket and a 13- liter bucket.
Which bucket would you store 10-liters of Water in?
the 13 liter, right?
Ten liters does not fit in an eight liter.
The water would overflow and spill out.
Extrapolating further, you'd use the 13-liter bucket for all amounts of water from 9 liters through 13 liters.
Once you hit 14 liters, though, You'd again move to a bigger bucket.
It's the same with the values you use when estimating stories.
Think of each value as a bucket, a value bucket is used for ALL stories between that value and the next lower value.
For example, suppose you're estimating with a sequence that includes 8 and 13. Anything larger than 8, and up to 13, should be called 13 story points.
That is, each story point value is implicitly arranged, just like a bucket can hold a range of amounts of water.
The trick is to choose the right bucket.
For accurate estimating and planning, teams need to understand that their job is not to put an estimate on a product backlog item.
Their job to is put the story in the correct bucket, Yeah, I know that in both cases, someone grabs a pen and writes a number on a story card.
But the goal is to find a bucket just large enough to hold the whole story.
When estimating, ask the team to picture a set of buckets in front of them, labeled 1, 2, 3, 5, 8, and 13, or whatever sequence the teams uses.
And then ask team members to pictures themselves throwing cards into the buckets.
This helps team members move away from the feeling that estimates need to be perfect and precise.
They don't.
Product backlog items merely need be thrown into the right bucket.
You might be concerned that this rounding up of estimates could lead to inflated or padded schedules.
Let me explain why that usually won't happen.
Consider a product backlog item that you believe should be 10 points, but you're using the modified Fibonacci sequence and are following this rounding
up strategy I recommend.
And so the bucket you throw the product back log item into will be 13. Next, let's assume that at 13 points the item is too big to bring into a sprint.
And so the team splits it into smaller stories.
Perhaps they split it in to three smaller stores, which they estimate as 5, 5 and 2 points.
Notice what happened there with the numbers?
The three small stories add up to 12 points, that's one less than the 13 point estimate you actually put on the larger story.
But it's two more than the 10 you really thought was the right estimate for the initial large story.
By forcing the estimate into the next larger bucket, you've improved the likelihood of accurately predicting the delivery date of this project.
If you had rounded down to the lower estimate, eight, the project would be four points late.
the project would be two points late.
Instead, by using the estimate values as buckets and rounding up, you've made it more likely you'll deliver this project on time.
But couldn't the 10-point story have turned out to really be eight points?
Sure, but it could also have turn into 14, 15, or any other number of points.
If you're interested in really gooding good at estimating, check out my video course, Estimating with Story Points.
I've linked to it in the description.

Improve Each Agile Estimate with One Simple Technique: Triangulating

Transcript

One of the best things you can do to improve your estimates is also among the easiest.
It's called triangulating.
The name refers to how sailors could determine a ship's position using landmarks on the horizon before GPS devices became so commonly available.
A ship's navigator would look at two known landmarks and draw a line to each on a map.
The intersection of the lines would be the ship location.
If I see a lighthouse over there and a marked buoy over it there, lines to eat will tell me where I'm located.
How do you use this to get better estimates?
Compare the item you're estimating to two other items you've already estimated.
For example, if a team is considering estimated something as 5 points, compare that item to an 8 and a 3. If the item seems a bit smaller than an eight
and larger than a three, then 5 is probably a good estimate.
One of your comparisons could be to item of the same size.
But if so, make sure to choose a second item that's a bit larger or smaller.
You can triangulate against more than two items, of course, but that can take more time, and there's very little to gain compared to using just two well-chosen items.
I like to chose items that are one value above and one below the item being estimated in whatever sequence of values you use for estimating.
If you're estimating with powers of 2, 1, 2 4, 8, and 16, then 4 is best compared to a 2 and an 8. It's the same thinking if you are using the Fibonacci sequence.
Choosing good items to compare against is critical.
And there's more to it than picking items above and below the estimate you think of.
You want to select items that were themselves well estimated.
To do this, at the end of each sprint, have the scrum master or team members collectively note any finished items that will be good to use in future comparisons.
Look for items after they've been finished seem like they have a right estimate.
That is, the team estimated this item as a 3, and when it's finished, team member still think it is a three.
Also, look for items on which there is strong agreement.
Don't compare against an item that half the team thinks should have been a five and the other half thinks it should've been an eight.
I coach Scrum Masters to maintain a list of these exemplary comparison items.
It doesn't need to be a long list.
No more than three items of each value is plenty.
Then, when a team is estimating, the Scum Master can look at this list and suggest good comparisons.
Age out older items, A team will be much better able to triangulate against an item they worked on three months ago than an items they work on when dinosaurs
roamed the earth.
One of the best things about triangulating estimates is that it can speed up your estimating sessions.
When team members start to bog down in an argument over the estimate, triangulated.
This may not immediately settle the dispute, but it generally will move a team closer to consensus.
Triangulating is easy to get started with and can significantly improve a team's estimates.
Next time you're estimating, try it by comparing the item you are estimative to one larger and one smaller item.
If you would, please click the like button if you found this video helpful.
And don't forget to subscribe.
Thanks, and I'll see you next time.

Stop Trying to Get Perfect Estimates! (Do This Instead)

Transcript

When teams get good at estimating, they can do it quickly and accurately.
When that happens, an organization can comfortably base decisions on those estimates.
But too often, teams you get hung up trying to create perfect estimates Here's the truth, trying to estimate perfectly does more harm than good.
That's why in this video I'm going to show you how to overcome the feeling that estimates need to be perfect.
To start, let's look at an example where the pursuit of perfect estimates caused real problems.
When I met Catherine, she was the senior vice president of a company with over $6 billion in revenue.
She and her teams were responsible for a little more than half of that.
The company had grown mostly by having very little competition over a few decades.
But lately, technology had enabled a lot of small companies to enter their space.
The company was struggling to hold onto market share.
As the company tried to protect itself against these new competitive threats, there was a real sense of urgency.
Catherine bore the responsibility to deliver results and deliver them on time.
When I visited, you could feel the tension just walking down the hallway.
One way Catherine tried to meet company-wide expectations was to hold team members to every estimate they gave.
When teams provided estimates, Catherine took them as guarantees, working those estimates into her plans and the reports she shared with stakeholders.
If team-members took longer than estimated, they got into trouble.
The first negative side effect of Catherine treating estimates as guarantees was that teams started padding their estimates so that they could be certain
they can complete the work in the time promised.
When shown these padded estimates, stakeholders chose not to have the team develop some of the functionality because it was so expensive.
Had stakeholders been given more accurate estimates without padding, some that work would have been prioritized into the product.
A second problem was that even with the padding some estimates weren't big enough.
Team members knew the estimates were padded, so they frittered and wasted the hours in an offhand way.
When they finally, ultimately got down to work, they hadn't left themselves enough time.
This is called student syndrome.
Remember those 10-page papers you had to turn in at the end of the semester for some class?
A full semester was more than enough to write that much, and we all knew it.
So most of us waited until a few days before the paper was due to even start.
And that meant some of us missed the deadline.
Teams behave the same way when they pad their estimates.
They wait too long, and then they fail to finish on time.
A final problem was that the padded estimates in Catherine's organization created a lack of trust between managers and teams.
These problems all happened because leaders expected perfect estimates that could be treated as guarantees.
When some estimates were inevitably overrun, the team suffered.
If you've experienced these problems, you're not alone.
Many teams struggle to estimate well, and to treat estimates as what they are.
Estimates, not guarantees I want to share five practical solutions you can try.
The first is to create a shared understanding among team members about the type of estimate each is giving.
If you ask a team to estimate something, some team member will give you a worst-case estimate.
This type estimate assumes everything goes wrong.
People who like to estimated the worst case are trying to provide an estimate that is safe, something they think they can beat 99 or 100% of the time.
Other team members may provide an optimistic or best case estimate.
This is often one in which estimators assume most things go as planned.
And a team may only beat an optimist estimate 10% percent of time If you have some people giving best-case estimates and others giving worst- case estimates,
no wonder they'll struggle to agree.
No wonder estimating takes longer than it should.
No, wonder some teams want to just stop estimations altogether.
Typically, a Scrum Master or Agile coach will get the team to talk through their differences.
But before doing that, it's critical to get everyone to agree on the type of estimate.
I cover the five types of estimates in detail in another video.
You can see it linked here and it is in the description.
I recommend having team members agree to provide the median estimate of the effort.
Think of it as a 50-50 estimate, equally likely to be too high or too low.
Once team member agree on the type of estimate they'll provide, you need to communicate this to stakeholders.
Unless you've told stakeholders otherwise, most will seem to think a team is providing estimates they will make 90% of time.
You need to inform them that the team is providing median estimates and the work will exceed the estimate about 50% of the time.
Here's how you can drive home the idea that an estimate is not a guarantee with your stakeholders.
Ask them how long it will take to drive to their favorite restaurant on a Saturday night.
Be clear that you want a 50-50 estimate.
Let's say a stakeholder estimates this as 30 minutes.
Next, ask the person for an estimate they are 100% confident in.
This means if they drove to that restaurant on a thousand Saturdays, every drive would take less than that estimate.
If the person is good at estimating, they'll realize that an estimate that can be met 100% of the time should be much larger than one that is met merely 50%
the of time.
If 30 minutes is the median estimate for driving to the restaurant, someone might say 90 minutes as the estimate they can beat 100 percent of their time
If the person only increases the estimate a little, say from 30 to 45 minutes, ask them to consider everything that could possibly go wrong on the drive
to the restaurant.
Car breakdown, tornado, road closure, a traffic ticket, Godzilla, or even all of these on that same drive.
An estimate that can be beaten 100% of the time is a guarantee.
And a guaranteed will be much larger than a 50-50 or median estimate.
When you explain it this way, most stakeholders, bosses, clients, and customers will understand that estimates are not guarantees.
They probably haven't thought about it that way before, but neither have most team members, which is why I suggested having this conversation with the
team first.
Once everyone agrees on using median estimates and understands what that means, it's time to take the third step to help your team avoid getting hung up
on creating perfect estimates.
And that is to give stakeholders an accurate plan, even though the estimates that make up that plan aren't perfect.
Reasonable stakeholders aren't going to get mad that some estimates turn out to be too low.
After all, you've told them you're using median estimates.
What stakeholders get made about is when the overall project is late.
The best way to add accuracy to a plan is to express the plan as a range.
Instead of telling stakeholders you'll deliver 10 features by a given date, say that you will deliver 8 to 11. or instead of promising to deliver in five iterations,
say it will be four to six.
This leads to a fourth thing you can do to help a team that is getting hung up by trying to create perfect estimates.
Get estimates right on average.
Team members often obsess over estimating each item perfectly because they think that's the only way to be right.
It's much easier and faster to instead be write on an average, this requires two things.
First, estimate a large number of small things.
This is necessary so that errors average out.
You can't have a product backlog of eight items and expect errors to average.
With that few items, it's very possible that they could all be over or underestimated.
Fortunately, most agile teams have product backlogs big enough that this won't be a problem.
Second, you need an estimated approach that encourages team members to estimate low or high with equal probability.
A common problem is when a team underestimates much more frequently than they overestimate.
Teams that do this need to incorporate techniques that help balance over-estimating with underestimated.
Most agile teams estimate with a predefined set of values, such as the Fibonacci sequence, 1, 2, 3, 5, 8, and 13, or powers of 2 1 2 4 and 8. I coach teams
to visualize values like that as buckets.
Each bucket can hold estimates up to its size.
With five and eight point buckets, that means items that are six or seven points go into the eight-point bucket, since a six- point item would overflow
a five-poin bucket.
This creates a slight pessimistic bias.
Items are rounded up instead of rounded to the nearest value.
this helps counter the tendency many teams have to underestimate, and it means the team is more likely to balance under and overestimating.
A final way to help a team not get hung up on creating perfect estimates is helping them select the right set of numbers to use when estimating.
Basically, don't force a teams to choose between estimates that are too close to one another.
I don' care how good a a is at estimatin, no team can tell the difference between 42 and 43 story points.
So make sure your team is using a set numbers that aren't far enough apart to matter.
Here's how.
Think about the percentage difference between numbers rather than the actual difference.
The difference in a one-point story and a two- point story is 100%. The differences between 42 and 43, just over 2%. This is why the Fibonacci sequence
got popular for estimating.
For numbers above three, each is roughly two thirds larger than previous.
Many teams feel that's a big enough difference to be discernible.
Other teams use a sequence like 1, 2, 4, 8, and 16, simply doubling each item for a 100% difference between values.
These five techniques work well to reset the expectation of estimates and how they're going to be used.
I've seen significant improvements with teams' estimates just by having these conversations.
They work by uncovering hidden assumptions and encouraging communication that can really help align the understanding of estimates,
both for the people who want the estimates and those responsible for creating them.
Now, I want to hear from you, though.
Which of these techniques do you think will help you avoid the pursuit of perfect estimates?
Let me know in the comments.
And if you found this video helpful, please click the like button because that helps others find the video.
Remember to subscribe if

Want Accurate Estimates: Don't Get Stuck in This Trap!

Transcript

I need a new backup drive.
I don't need 40TB drive, but the site I buy from listed one available.
Thought I might as well click on it and see the price.
The price seemed reasonable for that much storage, But what caught my attention is that the drive ships in 205 days.
Seriously, what are they thinking?
How can they possibly know the drive will ship in 205 days, not 204, 206? The website fell into what I call the precision trap,
which is applying a false level of precision to some estimate or plan.
We often fall into the precision trap because of the math involved in planning.
Let me clarify this with an example.
Suppose a team has estimated that it needs to deliver 100 story points of work to achieve some objective.
They've already calculated their velocity to be 15. Someone on the team does the simple math of 100 divided by 15 to get 6.66. Team members then proclaim
that they will be done in six and two-thirds sprints.
Or hopefully somebody decides to round that up and say it will take seven sprits.
But math like this leads to the precision trap.
You can see from this how the website decided the drive would ship in 205 days.
The precision track persists because we seem wired to like precision.
It feels good to say we'll be in 6.66 sprint.
We must be really smart to know that.
But we should instead favor being accurate over being precise.
Accuracy is about being right.
The easiest way to be right is to less precise For example, that website could have told me the drive would ship in about 7 or 8 months.
That would have been enough precision for me to decide whether to buy it.
When math tells a team they can deliver in six and two-thirds sprints, that's very precise, but it's probably not very accurate.
Just like the ship date of the hard drive, the estimate should be conveyed as a range.
Instead of six-and-two-third sprint, maybe it is six to nine sprinters or even seven to ten sprinter.
When estimating or preparing to communicate a plan, avoid falling into the precision trap.

Two Ways to Create Better Sprint Task Estimates

Transcript

Estimating is tough, but there are many things you can do that will result in better estimates.
In this video, let's take a look at two of them.
As a first tip, uncover hidden assumptions by asking team members what has to go right for you to finish in that amount of time.
This forces estimators to consider and verbalize their assumptions.
as an example, a tester might say that they need to get a fully testable version of a feature with at least four days left in the sprint.
Or a programmer might say they are assuming the last few open issues on the user interface design don't add significant complexity to the work.
A similar question you could ask instead is, what could make this estimate too low?
This question will also encourage estimators to think about things they're assuming will go well.
It's fine to base an estimate on things going well, but the estimate becomes questionable if it requires too many things to all end up being true.
Let's look at a second technique to improve a team's estimates.
This technique is called unpacking.
When unpacked an item to be estimated, the team discusses either the steps that will be performed to complete the item or some attributes of the work.
For example, suppose a team is estimating making a spaghetti dinner for a few friends.
There are two general ways this could be unpacked.
First would be for the team to discuss the steps involved.
Team members list steps such as shopping for ingredients, chopping the vegetables for sauce, cooking the sauce.
Also chopping vegetables from the salad that will accompany dinner, making garlic bread, and so on.
Another way to unpack making a spaghetti dinner could be to list the ingredients that will go into the meal.
Noodles, tomatoes, garlic, onions, butter, bread, lettuce, and so on.
Whichever of these ways a team unpacks cooking a Spaghetti Dinner, their estimate will likely be larger than if they had not unpacked the work.
Research has shown that unpacking leads to larger estimates, which are more likely to be accurate, as most teams tend to underestimate.
Think about how you would have estimated cooking the spaghetti dinner without unpackging.
Then think about your estimate would've changed after listing either the steps or all of the ingredients.
Most likely, the extra detail would lead you to a higher and probably more realistic estimate.
As an example, suppose a programmer on a team frequently underestimates how long programming tasks will take.
In the next sprint planning meeting, ask that programmer to give just a high level description of what the code will need to do.
When the programmer describes the steps the codes will perform, she is unpacking the work.
After describing the coat this way, the estimate she'll provide will usually be larger and more likely a better estimate.
Note that when unpacking something, the team identifies sub-steps of the work, but they estimate the original full thing,
not the sub steps.
If your team chronically underestimates, which will show up as them bringing more into a sprint than they can finish, include unpack in your next sprint
planning meeting.
You don't need to do it on every backlog item being considered for the sprint.
Try it first on the larger or riskier items.
Asking questions like what has got to go right for you to finish in that amount of time and unpacking items before estimating them can help your team get
better at estimations.
If you try either of these techniques, let me know in the comments how it works for your.
And if you have any other tips for improving a team's estimates, please share those as well.
I read and value every comment.
If this video has been useful, click the Like button.
And if you're new to this channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching, and I'll see you next time.

What Is Velocity: Agile Velocity 101

Transcript

Velocity is undoubtedly the most common metric used by agile teams.
Teams use it to plan sprints or iterations and predict future delivery dates.
In this video, we'll explore what velocity is, how it's calculated, the benefits of using it, and some best practices.
Velocity measures the amount of work completed by an Agile or Scrum team in a sprint.
It's measured in the same unit a team uses to estimate its product backlog items, whether that's a number of story points finished per iteration,
or the ideal days, person days or any other unit.
Calculating velocity is straightforward.
Add up the estimates assigned to each product backlog item that has been completed during the sprinter iteration.
For example, if a team completes five backlog items in a sprint and they're estimated at 3, 5, 2, 4, and 1 points, the velocity for that sprint would be 15. Naturally,
calculating velocity requires that each backlog item be estimated.
This should be done anyway before work begins on a product backlog.
The estimates can then be used for prioritizing and planning work.
An item must meet the team's definition of done to be included in the velocity calculation.The team gets no partial credit if a backlog is not done.This
is to help you avoid overstating a team progress.
Measuring and using velocity benefits an agile team in a number of ways.
Many teams plan their sprints using their historical average velocity.
The amount of work a team will complete in its next sprint should be close to its average.
This is known as the principle of yesterday's weather.
More formally, it's called a martingale sequence.
Velocity can also be used planning further ahead than the next sprint.
Using its average velocity, a team can provide a rough estimate of how much it can deliver in any given number of future sprints.
In doing this, it's wise to use a velocity range rather than a single value.
For example, if a team's average velocity is 20, it would be safer and more accurate to use a velocity range such as 16 to 23. Using this velocity-range,
a Team could forecast that in five sprints, they will deliver between 80 and 105 units of work.
As the end of a sprint approaches, team members focus on finishing items that might fall short of meeting the definition of done.
This can lead to a greater sense of team accountability.
When team member see their velocity increase, it can motivate them to maintain or improve performance.
Conversely, a decrease in velocity can prompt discussions on potential issues or areas for improvement.
Velocity serves as a critical communication tool for agile teams, providing stakeholders with concrete data on project progress.
It allows for transparency and fosters trust because stakeholders can see realistic expectations for delivery based on the team's actual performance.
I want to share a few best practices for using Velosity.
Number one, consistency is key.
To ensure that velocity remains a helpful metric, use a consistent method for estimating product backlog items.
If a team changes its estimation units, for example, from ideal days to story points, past velocity data should be invalidated.
Number two, avoid over-emphasizing velocity.
Although velocity is an important metric, a team's primary aim is to deliver meaningful products or features.
Over- emphasising velocity can result in teams compromising on quality or resorting to excess overtime.
And while overtime can provide a temporary boost in velocity, relying on it continuously leads to product defects and employee burnout.
Number three, expect variation in a team's velocity.
Teams, and especially management, should expect fluctuations in velocity due to various factors, such as team member availability,
imprecise estimates, external dependencies.
I've learned by analyzing data from over 100 teams that you should anticipate velocity varying across a plus or minus 20% range.
A team averaging 20 may have a velocity anywhere from 16 to 24 in the next sprint.
Those values are not bad or good news, they're simply random variations.
Understanding this variability can help in making necessary adjustments when planning.
Velocity is a fundamental metric that helps teams improve their planning and communicate effectively with stakeholders.
By understanding and leveraging velocity, agile teams can enhance their productivity, maintain transparency, and ultimately deliver better value to their
stakeholders

No Estimates: Fewer Estimates. Better Decisions: Agile Planning with Mike Cohn

Transcript

Welcome back, Agile Mentors.
We're back for another episode of the Agiles Mentor's Podcast.
I'm here as always Brian Milner and I have the original founder back with us, Mike Cohn.
Welcome, back in Mike.
Hi, Brian.
It's good to see you.
Really glad as all as, always to have Mike here when he can make time for us because Mike has so much wisdom and knowledge to share and especially on the
topic that we have for today.
we wanted to talk here in this new year a little bit about estimating and planning and really kind of dive into that topic in general and why that still
is important, why it still matters here in our current day and age.
So I guess, Mike, I'll start with this.
I know estimations is sort of an emotionally charged topic a little bit.
Why do you think it remains such an Topic in the agile community and just in teams when it comes up.
That's a good question I made a silly little YouTube video years ago where I'd bought a Styrofoam 5 and I think a styro foam 8 They were pretty big big
styrophoam numbers out there for like, you know kindergarten rooms or something like that and with this video of a guy dressed like a manager beating up
a developer with the 5 in 8 that were representing estimates right and i think apart of it is because That's most developers experience with estimates,
you know, they give an estimate and they're beat up with it.
Right.
You know you're wrong and you can't win, right?
You, know.
you've given estimate, and if you make it, nobody says good job or just go on their day.
And if.
Miss it you get beat.
Up with.
It right.
So we were beating people up.
With these styrofoam numbers.
and so it becomes this very emotionally charged thing, because I think a lot of developers don't see.
you know, what's in it for me, right?
What's it in for you with an estimate?
And so they're just kind of get opposed to it and they've been beat up by too many bad managers with estimates in the past.
Yeah, I try to explain that to people in classes sometimes that, you know, as a developer, or as past developer I know like we're always looking for the stick,
right?
The stick is around the corner and we don't know how far around that corner, but we know that we are going to get beat at some point and were just a little
leery that this might be just another way to facilitate the beatings, if you will.
Yeah.
Um, I know one of the, there's a lot of different thoughts and opinions on this in the agile community.
There's the no estimates movement and planning, that kind of thing.
What do you notice that people are reacting really against when they, they argue for those kinds of approaches?
I think they're a reaction to excessive estimating, excessive planning.
And I've written about this essentially probably since my Estimating and Planning book and talked about it at conferences since the early 2000s,
that you want to estimate so that can make a decision.
You don't estimate just for the hell of it.
I mean, estimations can be a useful activity.
Planning can useful, but they can very easily cross over into waste.
And I don't want to have a team spend time, waste time estimating just so the boss has a number they can beat us up with later,
right?
Or so, the Boss can, you know, sleep at night, Right?
You know?
And the BOSS probably was a developer who was asked to estimate when he or she was younger.
And now they ask their team to estimated out of habit, and no, estimate so you can make a decision.
If no one is going to use the estimate to make the decision, then don't estimate, right?
It's a waste of time.
And that's where I'm on board with the no estimates thing.
A lot of the, no-estimates people are, I don t know, it's the world's most clickbait title because it s not really about no estimate.
It s about fewer estimates in most cases, and totally, totally on-board with that.
Estimate to make a decision.
Don t estimate just to have a number.
Yeah, I remember years ago that I actually went to a local meetup group here in my home area and Woody Zool was there and he was talking about the no estimates
kind of approach to things.
And I remembered thinking, oh, i'm ready to fight this guy.
Like I had never met what he before for, and I thought, you know, am an estimates kinda person.
I think estimates make sense and i am ready, to have that discussion.
Right.
But, and then, then Woody comes out and he's this nice guy.
It's like everyone's grandfather.
He's just as kind person.
One of the kindest people I've ever met.
And he starts talking about it.
I remember writing in my notebook from that session.
That it seems to me like the, the S the sum of this is really estimate when there's value to estimating.
Yeah.
Yep.
Hashtag fewer estimates doesn't go anywhere.
So it's a click baity thing to get attention.
And that's fine.
I mean, Kent Beck acknowledged when he called it extreme programming, that it was going to give a lot of attention, right?
That was why he named it Extreme Programming to Get Attention on his process.
Um, so there's no problem with that, but you know, it does harm when people don't really understand the nuance and think that that means we throw all estimates out.
Estimates can be helpful.
We just don' want to overdo it.
Yeah, kind of like it wouldn't be quite as much of click bait to say Agile is done wrong.
It's much better to Agiles dead and then I'll explain to you why it's really just Agil done-wrong.
Yeah.
Well, back to thinking here about estimation a little bit.
I know that you've been talking about this for a long, long time and this has been something that has evolved a bit and I want to kind portion of this
show to talk about really how thinking on this has evolved over time.
So how's your thinking, on estimating and planning changed over the years, especially recently?
There's been a number of things.
When I wrote my book on Agile Estimating & Planning, I rode it with, there were two chapters kind of in the middle.
One was about story points, one was estimated in ideal days.
And I was totally open through the rest of the book, either of those approaches working well for estimations and I've really switched around on that where
I don't think talk about ideal days is a valid approach because it just leads to too much confusion over who's day and things like that.
And so I like the abstraction layer of a story point.
I think one of the mistakes I made in that book was not being clear enough about what story points really are.
You know, go over it again and again to really make the point clear.
And it's led to a lot of confusion where people just think, you know story point is a day and, and crap like that.
That's really caused a a of harm in the agile world.
I'll go into companies.
Oh, we do story points.
You set one story a point equals a.
And it's like, no, she can't do that.
And we were trained by somebody who said they read your book or something.
Um, and it definitely does not say that, so, um, I've become more adamant about, trying to help people understand what story points really are.
and they're a measure of effort where effort is defined as a combination of complexity, risk, uncertainty, volume of work.
We've got to mix all four of those factors together and come up with some sort of effort estimate.
And that wasn't clear enough in some of my early writing.
Another big thing that I've changed in how I think about estimating is a little bit more tactful about sprint planning.
I was pretty adamant for a long time.
And I think I can, maybe I'm just rationalizing, but I was pretty adamant for a long time about how teams should create a sprint plan that included a list
of activities and, and quick estimates, often referred to them as just guesses, But an estimate for each of the activities on a Sprint Backlog.
And, I am quite open these days to teams not doing those estimates of Sprints Back Log items.
I still do recommend teams start with estimates on their Sprits Back log items until they prove to themselves they're good at it.
But once you're good at it, you don't necessarily need to put a number on there.
But I never intended those numbers to be much more than guesses, right?
They were literally 30 second things.
They weren't like big discussion estimates.
Yeah, by the way, I don't think I've mentioned this yet, but if you're listening along to this and are interested in this topic,
we did put together a PDF for this episode as well that you can download.
Look in our show notes.
It's really kind of a field guide to estimating and planning here in 2026. So just know that that's there in Mike, I agree.
I think there's an aspect of this that when it comes up in classes, actually have started begging people to kind of do something here.
And that is that if you're making that connection, if your organization has a story point equals this amount of time, no matter what that,
is hours, days, whatever it is, my ask, My beg that I make in class is just estimate in time.
Yeah, absolutely.
I haven't had anyone.
And so this is a challenge to the audience here.
If anyone knows of a benefit of making that conversion, then please let me know.
But I don't know what the benefit is.
It's just confusing to developers.
Hey, this going to take me about, I dunno, 10 hours.
Story point equals six.
Let me do the math.
I just don' know the benefits.
There is no benefit.
That's just extra complexity, right?
If you're estimating hours, just use hours and don't be apologetic about it.
We're estimated hours.
And that can work for some teams.
Where that becomes a problem is when you have the superstar and the junior intern, Because the superstar says two hours,
the junior intern says, two decades, right?
I mean, you know, they're just not going to agree on if he's that bad, if she's bad about whether or not our junior interns.
But you, know if somebody says 2 hours and somebody else says 20 hours.
How are they going come to agreement?
Right?
They can't, but the Superstar and the Junior Intern can, we're dealing with the extremes here, look at things and say this thing will take twice as long
as that other thing, and that's the benefit to points.
Absolutely agree.
Well then let's reframe it a little bit.
Let's refrain estimation.
If it's not really about prediction, what would you say it really is for?
What do we use estimation for.
To make the decisions that we've talked about, right?
You want to estimate so that you can make a decision.
Put a product backlog item and we call it three points.
And the product owner says, three point's cool, I want that thing.
If we had said that thing was 20 points, the product owner might say, nah, that's too much.
It's not worth 20 point.
And so that quick estimate on a product backlog item lets a team know, or lets the product owner know how much they want the thing,
right?
It's desirable, but not at that price, I'd like a Ferrari, not that at price.
So it helps us make those decisions.
We put a estimate, if we do it in sprint planning, we put an estimate in a sprint backlog, say a programmer says, eight hours and the tester says they'll
take 12 hours, the programmer might say, wow, 12 to test that, you know, is there anything I can do to make that easier for you to.
Well, if you coded me a couple of hooks, I could cut the testing time in a fourth.
Oh, let's code those hooks in there.
And we add an hour to the programming time and we cut testing by 75%. So those estimates can help us make decisions.
Yeah, I agree.
And I think that's kind of the focus is on the purpose.
What are we trying to accomplish with this?
And if it's to make a decision, then yeah, we should keep that as our central focus.
Is it possible then to That's a great question.
And it's the subtle one.
This is where I will have arguments to people that are kind of opposed to estimating.
They'll say things like, oh, no, we don't estimate.
We make all of our product backlog items the same size.
Well, think about what's going on in someone's head to make all their backlog items the same size.
They're looking at a new item and saying, is it the I mean, we're estimating all the time.
You know, you and I scheduled time to do this podcast recording.
I had a doctor appointment about a half hour away from me this morning before we started recording, I have to estimate how long would my doctor take?
How long it would take me to get home?
Things like that, right?
So we are estiming all of the times.
We don't often talk about the estimates, they're just implicit in our head, but I don't think you can get away from estimating.
You're doing it implicitly, whether you want to admit it or not.
Yeah, I agree.
And I've talked to some of those people who do that same thing, who say we get it all down to the same size and so everything's a one.
My response generally is, well, that's great.
I mean, if you can do, then I think there's value in being able to do.
That I can only speak from my experience.
haven't worked on a team where we've been able get everything to same.
There's just always some things that are bigger than others and we can't split those things further.
So that why for me, estimations better.
I mean, if I was on a team where we could get it all down to one, great.
I don't have a problem with that.
But I'm with you, I'd rather have the thing where say, okay, everything's one to five, right?
If that's what we want to do, we wanna target things that are twos and threes, of course we have trivial things, let's call them one.
Of course, things are a tiny bit bigger, will come fives.
That'd be a better approach to me.
It'd faster, be faster.
Yeah.
Well, that leads us to kind of another big area because I know one of the things that people often talk about with estimation and planning is that it is
maybe it's anti-agile, you know, like it keeps you from being adaptable and it''s framed in that kind light of it being an obstacle to being adoptable.
Do you think that's actually true?
So it's a good observation.
Some of the early days of Agile, there was a lot of talk about what do we call the enemy, right?
And some of it was, you know, it, was Agil versus plan driven.
It was agile versus waterfall, what, do, we, call, the opposite and plan-driven was one of, that was discussed.
And I don't think we want to be plan, driven, I mean, when I'll be driven by the plan.
But I think a reasonable amount of planning, and again, it can easily be overdone, a reasonably amount planning improves our agility or our adaptability.
You know, think about a team that's planning to summit Mount Everest, right?
They have no idea when they set out all of the conditions they're gonna face, right?
And the troubles that they are gonna have, the obstacles they gonna encounter.
And so they plan, they planned that the trip up the mountain might take longer than expected.
They plan by taking extra supplies that can use on the way down.
So that planning improves their agility and improves the ability to adapt to the condition.
Yeah, I agree.
It's kind of like this concept of the sooner we know about a problem, the more options we have to actually address that problem.
And I think that's one of things that this gives us in that kind planning is that if we kind can look ahead and see, well,
this is a potential issue.
Well, now we can have more possible avenues to solve that rather than when we're right up against it, there's maybe only one way to deal with it.
Absolutely.
Well, I know one of the other areas that, that's kind of, the hot button topic, or I hear this talked about quite a bit.
I get asked about this in class is kind flow metrics.
And I, know that that is a popular thing right now.
So I'm sure people are kind, of interested in your thought on that.
From a flow metric's perspective, what do you think it does well or what are you thinking it struggles with and falls short with as,
as a way of planning?
I think tracking your flow is a great thing to do.
I don't think it should be the only thing you do when we have novel work, when were doing something that's completely new.
There's extra complexity there and I dont think the flow metrics handle that as well.
um so having you know having kind of more traditional metrics having estimates and you're balancing them out right with the flow metrics is going to be
the way to go you this is the thing with any sort of metric or measurement you never want to rely on just one thing right think about you get on an airplane
you look up and see how many controls or gauges the pilot has like, holy cow, right?
You wouldn't want to fly a plane with one gauge, or you want.
Have multiple views of where you're at.
And so for metrics, you are a good supplement, but, um, I think they help ground conversation.
But I.
Estimating more traditional estimating helps us think through the challenges that we can anticipate with, with work, especially novel work.
Do you think these two kind of compliment each other flow metrics and, and estimating with some story points?
Yeah, I think they can be a good balance.
It's certainly useful to see how many items are flowing through our process, right?
But it's also good to what the sizes of those things are.
I just want to mention, again, if you're listening into this, we do have a PDF about this very topic that you can download in our show notes.
So make sure you take a look at that if this is a topic you want go a little bit deeper on.
Let's talk a bit about the human impact of this.
What do you think happens, Mike, to teams when their planning and estimation are kind of stripped away entirely?
Well, this is a little bit back where we started, where I was saying the developers kind to say, what's in it for me, right?
I estimate what is in for it me.
I gave the boss a number.
They're just going to beat me up with it.
There's no benefit.
We need to get to a point where developers understand that estimating well or planning well, even more importantly, planning can be beneficial,
mad to them, beneficial to.
Imagine a team.
That's just horrible at, at estimatin.
They're just horribly at estimated and planning.
And they're never right.
The business comes that or that, that development team and says, Hey, we need this in three months.
and the developers say, can't be done.
Can't.
Well.
I think the business has every right in the world to say, give it a try.
Right?
Because this team's never been right.
In the past, right?
If they say it can't be done in three months, maybe it, can go give.
Give it.
A try, Right.
And so in those organizations, we see businesses leaders putting a lot of pressure on the team to go do it anyway.
Go give, it try and make it happen.
Now, imagine a different scenario where the team is good, not perfect.
No team's perfect, but they're good.
They say something will take three months.
It takes almost three minutes.
You come in a little bit early.
The next thing they say, it'll take two months and say it takes two and a half.
Again, they are not perfectly, right?
But they were pretty good and they built up this track record of being pretty.
And now the business comes with that same new project and says, can we do it in three month?
And the teams says no.
Now the business is gonna listen, they're gonna say, oh, okay, it can't be done.
What would it take?
And here's the key thing.
what would take for us to get it done in three months?
Well, if you relax this one requirement, right?
Or if we could stop doing second level support of the other product for two months while we work on this, Right?
If we have one more person, whatever it is, we'll have different tools.
So, but now it's a collaborative discussion of what can we, stakeholders and team do to achieve that three months, or maybe we can't do it in three,
but we could do in 3.5. And it's a collaborative discussion now.
Whereas before, when the team was bad at estimating our planning, it was just to dictate, make it so.
That's not a good position to be in.
When we drop the planning or we just kind of give up on it, we're losing a way for teams to establish credibility.
Yeah, I think you're right that it does.
It has quite a lot of impact on just the morale of the team and kind of how they approach the work and everything.
This is kind a bonus side question here for you, Mike.
Just want to see what you'll do with this.
But I know sometimes I will talk to leaders who say that their team is bad at estimating, that they don't estimate.
points well, that they want them to be better at estimating points.
And I'm kind of curious what your take would be on that.
Is it possible for people to better or worse at Well, absolutely, but it depends on why they're wrong.
So let's just talk about a few things there.
Um, so the most common thing when I hear that a team is bad at estimating and they are using story points, it's probably because they do not have a solid
understanding of what a point is.
Right.
You've got people in there thinking that their time, other people are thinking they were just complexity, right?
Points are not complexity.
Complexity is a factor in the effort that is appoint.
So you end up with these, these funky, inconsistent, incompatible definitions.
And that's of course going to lead to problems, right?
So what I want to make sure people do is that they have a common understanding of what a point is.
If you sit in on a meeting like that and you ever hear somebody say, well, it's five points if I do it, but 10 points, if you do.
You know, they don't agree on what point it is, because that is the antithesis of a Point.
So I'd want make they had a very clear definition of, of point.
From teaching this for so many years, that's hard.
There's this magic point people have to get to with points.
And I see this when I'm teaching.
When they get it, it clicks, and all of a sudden, every single thing about estimating makes sense.
Everything makes But they have to do this magic inflection point.
And I contrast that with something like stories and backlog management that I teach as well.
Those are, those are like golf, right?
You can always get better at writing stories.
You always have better splitting.
They're very linear skills.
Just keep getting better with those things with practice, estimating there's this.
Magic point, and you have.
The team members, ideally all of them, at least a majority of.
To that inflexion point If we've done that, there's all sorts of things that we can do to get teams to create better estimates.
I'll just share two.
One is a technique called unpacking.
What unpackings entails is discussing the components of the work, right?
Oh, to do that big feature, we'd have to this and this, and that's right.
Don't necessarily write them down, but just talk about them and then go back and estimate the big things.
So don't estimate to small things, the unpacked refers to identifying those small thing.
So you unpack the big thing, identify the sub-steps, and then re-estimate the Big Thing.
That has been shown through academic studies to be a way to improve estimate quality.
Another thing that teams can do if they're bad at estimating is to make sure they agree on what they are estimations.
And you might have somebody on your team who's very conservative, very nervous and they're estimating kind of the worst case scenario,
right?
Not normally at the worse case narrow, but kind like the 90% scenario.
Right?
You know, they were thinking about all sorts of things going wrong.
You might have somebody else on the team estimated most likely scenario what most like will be done in three days, You might have other people in there
thinking about the median estimate, the kind of 50-50 number.
50% of the time it'll take more, 50 percent of it will take less.
These are all different numbers.
And if you have that going on on a team, you're going to have fights.
You're gonna have arguments.
So if your in with a time and you see them having big discrepancies in their story values, because of that.
Yeah, I just wanted to see what your answer was on that, because I know a lot of times I get that question in classes as well.
I can go on and on.
But I think I've got a video of about five things to do to get better and four things stop doing that'll get you better.
That's awesome.
Well, that kind of naturally leads us to talking about the misuses of this as well, because I think a lot of times that's where a lots of the problems
come from, is just sort of a misunderstanding or misusing of story points.
I know for one, I always know that there's a misunderstand and misuse when I hear developers talking, about I want to get credit for the work from this sprint.
Uh, know there is a, a misunderstanding or a miss use of them.
If the misuse of these is so widespread, why do organizations keep asking for story points then?
Because they...
I mean, I don't know that organizations ask for a story point, organizations asked for plans, right?
You know, give me a date, when will you be done with this stuff?
And it's because, to a large extent, that's how organizations run.
We can pretend that it should be, well, we'll just deliver features as fast as we can, but there's often other parts of an organization that need to coordinate
with the release of something, right?
We might need train users on it.
We may need update website documentation about the new features, all sorts of things.
Having some sort of plan, it doesn't have to be very far into the future, some plan is extremely helpful.
Do you think estimation can become harmful in the organization and what kind of things would signal that it's kind it has taken on a harmful turn?
Well, that's when you're running around beating the team up with the five and the eight that I mentioned, right?
When estimates are used to punish developers, when exceeding an estimate is viewed as a bad thing, it's an estimated you are going to be over.
And I just talked about most likely median and 90% case estimates.
I recommend teams estimate at a 50% level.
Now we do that so that we can plan at more of like a 90% level.
But individual estimates, if we're doing them at a median, that means we are going to be off half the time, right?
If we were to do it well, we would be of half of the times.
And most teams would off a little bit more than that because they are not particularly good yet.
So we have to in some ways celebrate the fact that some of our estimates were over, what we want to have is a process where we some over some under and
they balance out, and that's where a lot of teams go astray.
So I think, you know, punishing people for high numbers, um, publishing teams for, uh, high variance in their work.
Um, I have tracked hundreds of teams, which means thousands of sprints.
And what I noticed was that a typical velocity for a team will bounce around in a plus or minus, 19%. That's very precise.
So it's rounded up and called 20 plus, or 20% range.
What that means, if you've got a team that averages 20 points next sprint, they might get 24. The next after that they make it 16. And those are not good
and bad news.
They're just random statistical variants or variability.
Um, you know, when a, team is bouncing around in a range like that, that's a good thing, right?
And you don't want to punish a.
Oh, no, You were two points under.
You only got 18 done.
It's like, yeah, That's random variation.
Yeah.
Yeah, I agree.
It does have the propensity to be misused.
And I do think that there are a lot of situations where it has been mis-used and people come out of that, those situations and think,
oh, estimation itself is bad, but it's not really the estimation.
That's the way you're doing it.
Now that really ends up being the problem.
Yeah, there's just numbers.
It's all about how the numbers get used.
And that's normally a failure of leadership intent in how leaders are intended to use those numbers rather than of the estimates or the team themselves.
Yeah.
I kind of think about this in the terms of like, when you see adult beverage ads, it always says, you know, drink responsibly.
And so I kind of think about that with this as well, not drink responsibly, but use responsively.
Estimate responsably.
Maybe that's your show title this time.
Yeah.
I estimate responsivly.
What would you give as advice to estimate responsible?
We haven't talked about this, but I think one of the important things is to think about estimates as ranges, and think of plans as range.
The team that I mentioned climbing Mount Everest, I mean, they might have a day they intend to summit, But they're probably looking at a range of days
they are going to submit, depending on the weather when they get close to the summit.
So use a arrange.
If we say we're going finish something, we'll be done in two to three months or two and a half to 3 months, or we're going to be done in four to five sprints,
things like that.
Or we'll be down in 4 sprits, but it'll have between this and that much functionality, right?
Use ranges on things.
Don't overdo it with estimating.
Estimate only if something's going make a decision.
And I think it's very fair for team members to say, would ask for an estimate, very fare for a team member, say cool, we will do that,
by the way, how will this number be used?
Right?
Oh, I don't know.
I just need an estimate.
It's like, we're not estimating that.
So estimate if there's a reason.
Right.
And I do think that teams can get better at estimations.
Most teams don' t give their own little feedback loops.
You know, why were we off on that estimate?
Talk about that in a retrospective, right?
Why did we miss a plan?
I think it's useful in estimating to state our assumptions.
What are we assuming will go right?
If we're summiting Everest, I assume that we are going to have good weather one day during the third week that were on the mountain,
whatever.
So I have to think about things like that and use the estimates, the estimations sessions as an opportunity to discuss the work because that's the real
benefit is the improved and shared understanding that comes out of those discussions.
I've literally done this with teams.
where this was a sprint planning meeting I'm thinking about where we had a Google sheet up.
We put all the estimates in the Google Sheet for the, estimates for this sprint backlog.
And at the end of the meeting, I deleted all numbers.
I just deleted that column and the team members are kind of pissed because I'd made them estimate the numbers and they said,
why did you have us do that?
And I said I don't care about the number.
So I cared if we put the right amount of work in this print and those numbers were there to help us put them out and work.
There we go again.
They were about making a decision, right?
Those numbers helped us make a.
Do we have the right amount or not?
And I didn't want the numbers to remain because then people were going to feel like, Oh, no, I said four hours to code that thing and it's going take me five.
I'm going feel bad or I better rush and be sloppy.
So I knew that was kind of a propensity of that team.
Deleted the column.
Right?
I say, this isn't important anymore.
We got the benefit out of those numbers were done.
I love that.
I think that builds trust as well because of the reason you said you're not going to hold someone to five hours if they said five.
It takes what it takes and we just learn from it.
Yep.
Um, well, I know these, this is a, as we kind of wind this down, uh, there's a lot of hot button, Uh, topics on this.
I'm sure every time you talk about this, your inbox gets flooded with, you know, different opinions and hot, hot takes on these kinds of stuff.
And insults and all sorts of things.
Right.
Exactly.
Please be kind.
Everyone please just be, kind, right?
Uh there, it doesn't cost you anything to be.
Don't insult my mother.
You can insult me.
Right.
Right, but I think the thing I'd want to ask you, Mike, is, uh, as we kind of wrap up is if you could give a message to the,
those listening, the agile community in general on estimation, to help them kind better understand this or, or maybe set right something that's not really
correct on, on this.
What, what, would be your one message you'd people to take away and hear from this?
My one thing.
Yeah.
Your one.
Probably that estimating and planning don't eliminate uncertainty.
We're not estimations so that we can predict the future, we're estimators so we that can make decisions.
And when we estimate and talk about the uncertainty in items, in work, it allows us to navigate that uncertainty, allows to create plans to get around it,
right?
We can dock those assumptions, create a plan together to go around.
But we are not going to eliminate uncertainly and that's absolutely not what estimatting is about.
Yeah, I love that.
I loved distilling it down to just making decisions.
That's a great way to put it because there's lot of decisions we make from them, but those are all kind of the driving point of it.
We're doing it for this purpose, and if you don't keep that in mind, you can really get screwy with these things.
Yep.
If it won't help you make a decision, don' estimate.
Yeah.
Absolutely.
Well, this has been great, Mike.
I really appreciate you coming on.
Now, again, everyone, you know, if you want to read more about this, look in our show notes, find the PDF for this one, and it'll give you some more insight
and information on this.
So Mike, thanks for making time for us and coming onto the show again.
Thanks as always, Brian.

The Real Cost of Inaccurate Agile Plans

Transcript

Bad plans lead to many well-known problems.
Teams deliver later than expected, or the budget is blown by adding people in the hope that will help.
Sometimes a deadline is met but by dropping important features.
Or the deadline met by team members working overtime, causing burnout, frustration, and usually introducing bugs.
Inaccurate plans frustrate both team members and stakeholders, but one of the worst impacts is the team loses credibility with its stakeholders.
I've got a friend whom I'll occasionally meet for lunch.
He's always 5 to 10 minutes late.
If he emails me today and suggests meeting at noon, I'm going to arrive five minutes late myself.
I no longer trust him to be on time.
It's just lunch, so who cares?
But the problem is much worse on projects.
Consider a team that is either consistently late or always has to drop scope to meet a deadline.
The team is now asked if they can deliver a new project in three months.
Team members think about it and decide they cannot deliver it in 3 months, but could in 4 months!
When they tell stakeholders they need an extra month, the stakeholders don't believe them.
And why should they?
The team has been consistently wrong on all prior projects.
At this point, stakeholders may tell the team to do it in three months anyway.
Why not?
the Team never meets its deadlines.
So, Stakeholders may reason that they'll stick with the three-month deadline, but quietly expect it, in perhaps four months.
What's critical here is that stakeholders will not treat the team as an equal partner.
Consider how things might have played out differently if the teams had established a track record of providing decent plans.
Not perfect, just decent.
When that team tells stakeholders a project will take an extra month, stakeholders are likely to engage in a conversation about options.
Stakeholders and the team would discuss ways to meet the desired earlier deadline.
For example, would it help to enlarge the theme?
Is there a feature or two that could be dropped or deferred?
Would it helped if team members were allowed to focus solely on this product instead of also supporting some old product?
When a team has a track record of presenting reasonably accurate plans, they will be treated as equal partners by the rest of the organization.
Many teams try to solve the problem of inaccurate plans by padding their next plans.
This usually makes things worse, as the team now has two things to estimate.
The plan and how much to pad the plan.
When stakeholders call the team on padding a plan, the padding is often removed unless team members can present solid logic and evidence for the size of
the patting.
A better solution would be for team member to assess why their plans have consistently been wrong.
Sometimes the problem is with the estimates themselves.
If that's the case, there are many things team members can do.
I'll share just one technique right now.
It's called unpacking.
Unpacking involves identifying all the subparts of some work to be done.
''I need to do my laundry today.'' I can unpack doing my washing to wash, dry, and put away the clothes.
if needed, I could unpack put-away into fold some items and hang some others.
Agile teams can unpack large product backlog items into smaller product-backlog items, and they can pack small product backlogs into the tasks they'll
perform to complete that item.
Having split work into small pieces, most teams will next estimate those smaller pieces.
However, research by Magda Jorgensen has shown that estimating small things and then summing those estimates can lead to worse estimates.
So instead of estiming the smaller pieces, unpacking involves identifying the components of the work, but then estimating the original larger item.
Research by Kruger and Evans has shown that unpacking items this way will lead to larger estimates.
For teams who chronically underestimate, this is a valuable and easy way to get better estimates I've added references to these two important papers in
the description.
Unpacking is one of many ways a team can improve its estimates But some teams actually estimate most items fairly well, but still deliver late.
How can this be?
One reason is when a team fails to account for what I call the Unknown Backlog.
The Unknown backlog contains all the work that a Team will need to do, but that hasn't been identified yet.
Part of the unknown backlog is just things the Team hasn' t thought about yet, every Team overlooks something.
Beyond things a Teams overlook, there are also emergent requirements.
These are needs that emerge through the process of building the product.
Stakeholders are shown a preliminary version and that gives them new ideas.
In many cases, those new idea become must-have features.
It would be impossible for a team to make a list of everything they've overlooked or that will emerge.
These items are, by definition, unknown.
However, there are techniques a Team can use to roughly estimate the size of the unknown backlog.
A simple approach is to ask Team members to estimate how much they think they currently know about the product they'll ultimately deliver.
Suppose a team has a set of really good detailed discussions with stakeholders.
It's clear that stakeholders hold a crisp vision of what they want, and stakeholders have answers for most of the team's questions.
Following these discussions, team members feel they have a good understanding of But team members also know there will be some misunderstandings and that
stakeholders will inevitably come up with new ideas that they'll insist be included.
Team members in this situation may reason that see about 80% of the ultimate solution.
That means the product backlog is 80 percent of full size of backlog.
The unknown backlog the other 20 percent.
Team members don't know what will be on the unknown backlog, but they can estimate an approximate size for it.
And they could use this to better scope the full size of the project.
By including an adjustment for the unknown backlog, a team can greatly improve the accuracy of its plans, even if the adjustment is a very rough approximation.
Not all teams need to plan.
Some teams are simply instructed to deliver new capabilities to achieve outcomes as quickly as possible.
In the majority of organizations, however, some degree of predictability is important.
This may be to enable coordination with partners, to train users to coordinate marketing efforts, or more.
In a private company, plans feature prominently in the company's ability to acquire funding.
And in a public company plans influence guidance given to shareholders and investors.
For physical products, plan influence manufacturing and shipping commitments.
If creating reliable plans stakeholders can trust is important to you, consider participating in one of our accurate agile planning courses.
This course is designed to help teams produce accurate estimates and plans, including on fixed date and fixed scope projects.
I teach these courses online publicly a few times a year and can also teach a private course for your organization.I've put links in the description.
Thank you for watching and I'll see you next time.

Agile Estimation & Planning in 2026: Why They Still Matter (And How to Do Them Right)

Transcript

By 2026, most Agile practitioners have plenty of scar tissue when it comes to estimating and planning.
I hear the same stories over and over again.
Estimates treated as promises, plans turned into contracts, teams punished for being wrong rather than rewarded for learning.
Given experiences like those, it's understandable that many teams decide the solution is to eliminate estimating and planning altogether.
I think that's a mistake.
Estimating and planning still matter.
Not because the future is predictable, but because it isn't.
They matter because teams and organizations still have to make decisions about what to work on, what delay, and what risks they're willing to accept.
In this video, I want to explain why I believe that, And what estimating planning look like when they are used responsibly.
Anytime you choose one piece of work over another, you're estimating.
You're estimated cost, value, risk, or effort, even if you never put a number on it.
I've worked with teams who proudly told me they don't estimate.
But then I watched them make decisions based on unspoken assumptions about size and difficulty.
The estimates were still there.
They were just invisible and unexamined.
And in my experience, that's worse.
The real choice isn't whether to estimate, it's whether estimates are explicit or implicit.
One of the most damaging beliefs in agile is that estimates exist to be accurate.
That framing turns every estimate into a test and every miss into failure.
In healthy agile environments, estimates exists to support decisions.
Is this worth starting?
Should we do this now or later?
What are we trading off?
So a better question than is this estimate accurate is, Is this estimate good enough to support the decision we're making?
When teams ask that question, estimation becomes far less stressful and far more useful.
I often hear people say estimates are always wrong.
They're usually frustrated, and they're not entirely wrong, but being wrong isn't the real problem.
Estimates are hypotheses.
Reality supplies the data.
I'm reminded of this every time I run a training class.
If it's a course I've taught before, I can estimate almost perfectly how long it will take me to prepare for the class, But if it's a new class,
new slides, different exercises, and new discussion prompts?
When my estimate is off, it doesn't mean estimating was pointless.
It tells me exactly what I didn't yet know.
That's how estimation works on agile teams, too.
The failure isn't being wrong.
Failure is treating estimates as promises and punishing teams when reality turns out to be more complex.
Planning is often portrayed as the opposite of agility.
In practice, the OPPOSITE is true.
Good planning aligns assumptions and intent.
It gives teams a shared starting point so they can adapt quickly when things change.
What actually reduces adaptability is planning too far ahead and over-committing to uncertain work.
I like to think of planning the way I think about planning a hike.
You don't plan because you expect the weather to behave.
Flow metrics have added valuable grounding to agile work.
They tell us how work has flowed in the past, but they struggle with novelty.
Whenever work is new or risky, historical averages become less reliable.
That's where estimation still helps.
Not to predict precisely, But to reason about what might be different this time.
Rather than choosing sides, teams are better served using both.
Flow metrics for grounding, estimation when thinking through new work.
One of the surprises I've seen is that removing planning often increases pressure on teams.
Without boundaries, work expands.
Priorities shift constantly.
Overcommitment becomes invisible.
Lightweight planning creates focus and boundaries.
It gives teams a chance at sustainable pace.
Planning isn't bureaucracy.
it's one of ways teams protect themselves from chaos.
Before estimating or planning, I encourage teams to pause and ask three questions.
What decision does this support?
What happens if we're wrong?
And who will use this information and how?
If those questions don't have clear answers, the problem usually isn't how the team is estimatin.
It's why they're estimati.
Uncertainty isn't a flaw in Agile systems.
It's the reality those systems are designed to handle.
Estimating and planning don't eliminate uncertainty.
They help teams navigate it together.
Thanks for watching.

Kill the Daily Scrum?

Why daily scrums fail—and practical ways to make them shorter, sharper, and worth attending.

Team Hate the Daily Scrum? Kill it!

Transcript

Do your teams hate the Daily Scrum?
Well, you might be shocked with the advice I'm going to give you here, but I am going advise you to kill it.
Kill your Daily scrum.
Let me tell you what I mean.
I got called in to work with an organization.
And when I, when got in, the management of the organization, you know, I did a little intake with them before I worked with the teams and they said,
we're, gonna give you a warning.
We're gonna to give a heads up.
One of these teams has a lot of senior developers on it and, they're going to ask you to kill the daily scrum.
So I was a little taken back by that and I said, really?
Tell me more.
And they said yes, we're gonna, they're going to ask you to kill the Daily Scrum.
They've been begging us for a long time to Kill It.
they hate the daily scrum.
That's their number one thing.They bring it up in retrospectives.they just want to not ever do it again.
So I said, thank you for the heads up, I appreciate that.
And I wanted to go then and observe that team's daily scrum to see what's going on here.
How are they doing their daily Scrum?
What's their practice like?
Well, you can probably imagine what that daily scrum kind of felt like.
I walked in the room and I heard one of the developers say, All right, my turn.
Yeah, yesterday I worked on ticket 1937. Today I'm going to work on Ticket 1938. No blockers.
The second developer said, oh yeah, uh, My update for today is I've worked 235. Yesterday I am going work 236 today.
no blocker.
And this proceeded around the group of senior developers.
At the end of it, the Scrum Master in the room said all right anything else?
No?
Allright, great.
See everybody back here tomorrow.
Have a great day.
and everyone walked out of the room.
So observing that, I thought, wow, i can see why they hate this this meeting.
I can, see, why no one wants to do this, meeting so the first chance i had to actually talk with them about it.
i brought them into a room and said hey i attended your daily scrum today as you know i listened to it i i heard how you guys are running it and this might
shock you But my advice, and this might be contrary to what you think an Agile coach would say, but I'm gonna agree with you that we should kill this.
And their response was a little taken aback.
They thought, wow, that was easy.
I can't believe on the first day with the Agil coach, we were able to convince him to kill the meeting that he'd been trying to convinced leadership to
go for all this time.
I said, yeah, I know, it's a little crazy.
I'm a bit like that.
But here's the thing, right?
I need your help, because there's five other teams in this organization that I am also coaching and trying to help them get on track.
And you guys are the senior guys here.
It's not a bad example, but I don't want them to see that, hey, they gave into you, and then they're going to want me to give into them.
Do me a favor, right?
Let's keep this 15 minutes, okay?
So we have this 50 minutes every day, but I promise you we won't do a daily scrum.
Right?
We're not going to do the daily scram anymore.
Let us make use of that time though.
We are going be here for 15 mins every so that everybody else outside this room thinks we are still having it.
So let us come in here and I don't know, let's just talk about whatever we need to talk to get our work done today." And the developers looked at each
other and thought, yeah, that sounds like a great idea.
And so we did that the next day.
We came in and we just talked about the issues.
we talked what was going on.
Yeah, we needed to finish that thing today.
Let's help each with that.
Hey, I finished this.
What should I pick up?
How about you start this thing?
So we had this really robust conversation.
And I let this go on for three or four daily scrums because I wanted it to sink in.
I want them to get the feel of this, right?
And then after three of four of these, I actually stopped at the end of it and said, hey, before everyone leaves today, i have a confession to make.
What you've been doing the past few days, that is actually a daily Scrum.
What you were doing prior to that, I don't know what you want to call it, but it definitely wasn't a daily Scrum.
In fact, let me kind of share with you what the Scum Guide says about this.
And I read it off to them.
I let them know with the scrum guide said about it.
Well, they did feel a little tricked, but they also, I could see the light bulb go off in their heads.
Every one of them was like, ah, okay, now I get it.
Right, this seemed pointless before.
I did not really understand why we had to come in this room, because my Scrum Master wasn't doing anything with our status.
It just seemed like Scum Master was micromanaging us.
But now that I understand we're here to really talk to each other and help each with what we are going to do today, it clicked.
Maybe I was a little deceitful.
I get that, I'll take that.
But the point was driven home and that team never looked at their daily scrums again the same.
So I would propose to you Maybe if you have a group of those long time developers who have seen it all and done it, all before they know what this daily
scrum thing is, they're familiar with the three questions.
Maybe you need to help them get out of their mindset and say, Hey, let's try something new.
And sometimes just changing the name is all it takes.

Why Teams Complain about Daily Scrums

Transcript

If there's one meeting in all of the Scrum framework that I look at and think causes the most consternation, the more problems,
most headaches, I think I'd have to say it's the Daily Scum.
How can that be the case?
It's only a 15-minute meeting.
When we have something like sprint planning that lasts up to eight hours for a month long sprint, how can this little 15 minute meeting be the source of
so many problems?
Well, for one, it's the only event in Scrum that happens every day.
So just like if you put a card in a bicycle wheel, that noise happens over and over again, squeaky wheel kind of problem.
Also, I think the reason it's the most problematic is that it is the one that is most misunderstood.
So I hope you'll join me in this short little series where I want to describe to you some of my experiences with a daily scrum and we'll talk about some
possible solutions and ways to improve your daily scums.

Common Problems with Daily Scrums

Transcript

Before we get too deep into this topic, I want to ask you a question.
If I were to asked you how your daily scrums are right now, what would you say?
I often ask this when I do this as a conference talk, and the responses I get are maybe somewhat surprising.
I ask people, do they suck?
Are they okay?
Or would say they're perfect?
And it might surprise you to hear that about 80% of people say that they're okay.
They're not perfect, but they are doing okay, 11% or 10 or so percent say they actually suck, and maybe 8% think that their doing them perfectly.
So keep that in mind as I talk about some of these other answers that I get from folks in the same kind of data set, the group of folks that have presented
this to in conference talks.
I follow that question up and say, what kinds of problems do you see in your daily scrums?
I give them choices here.
I say do people treat it as a status update?
Does someone ramble on and on?
Do you have trouble staying in the time box?
Are there people who are constantly late to your Daily Scrum?
or do you have lots of outsiders that are interrupting?
Well, this probably isn't going to be a big surprise to you, but the number one answer that people vote for in that scenario is that,
people treat it as a status update.
In fact, you know, it's a large percentage of the people who say that's the No.
1 problem.
So that's my second question.
Then I ask them a third question, and I say, what would you say is closest to what you understand is the purpose of a daily scrum?
Now, this is where things get a little interesting, because I asked them what they think the purposes is, And I give them few choices.
I said, is it the reason that it serves as a team building activity?
Is it that the point is to inspect the team's progress in order to plan today's work?
Is it to provide a status report to the Scrum Master?
Or is it keep the team on track to ensure that they meet their commitments?
Now, take a breath because the number one answer that I get from folks in this, thankfully, is what I was hoping for.
It is to inspect the teams progress in order to plan today's work, which is basically what the scrum guide tells us.
About 50% of people answer, But the scary stat for me is about 40% answer that the purpose of the Daily Scrum is to keep the team on track to ensure that
they meet their commitments.
It might be a side product of The Daily Scrum that a team gets back on the track in order to meet commitments, but that's not our purpose.
Our purpose at The daily Scum is inspect our progress towards a sprint goal and to adjust our plan to what we need to do next.
It's to talk to each other, it's for the developers to interact and make a plan for that day's work.
When I tell people the purpose, I oftentimes get shocked faces.
They are so used to it becoming a status report that that's all they know.
It is a Status Report.
I'm here to tell my Scrum Master what I did yesterday, what i plan to do today, and if I have any impediments.
That gets in the way, i think, a lot of times of the Purpose.
So just keep these stats in mind as we go through the rest of this series.
I just wanted you to know there's a lot of misunderstanding out there.
And I think a lotta it can be pointed directly back to why are we here?
What's the purpose?
Can you answer that?

Purpose of the Daily Scrum

Transcript

Creating valuable daily scrum starts with understanding the purpose of why we're there.
So let's go to the source.
Let's look at the 2020 version of the Scrum Guide to see what the purposes of a daily Scum.
The purpose the daily scum is to inspect progress toward the sprint goal and adapt the Sprint Backlog as necessary, adjusting the upcoming unplanned work.
Now, that's a bit complicated and hard to remember, I know.
But let's try to break that down and distill it to the core of what it's trying to get across.
Inspect progress and adapt our plan.
That's easy to understand and it is easy remember.
Focus then on the purpose.
Why are we here?
If your teams understand the purposes of the Daily Scrum, form comes later.
In fact, the form doesn't really even matter.
If we're achieving the Purpose, that's the point.

Daily Scrums Showcase Team Dynamics

Transcript

When I'm asked to work with teams, one of the first things I want to do is to observe their daily Scrum.
For me, that daily scrum becomes a very vital barometer.
It helps me to understand so many dynamics of how the team is actually interacting with each other.
I am looking to see if the daily scrum is a valuable part of their day, but I am also trying to understand some of the team intradynamics.
At this point, I want to bring something up that sometimes I've gotten some pushback on, and that is that Scrum is a team sport.
Now, I don't get pushback on people thinking that it's a team sport, but I get pushed back on the sports analogy itself.
Sometimes people get uncomfortable with sports analogies and say, hey, don know sports ball at all, so why would this make sense to me?
Trust me, you don have to know the inner dynamics of how teams actually work together in a particular sport to understand this analogy.
I'll make it simple for you.
Scrum is at its core a team sport.
It is an analogy that comes from rugby.
A scrum is part of the game of rugby and the authors of Scum deliberately chose that reference to help us to understand in a large picture view how this
should work.
it should be like a Team Sport.
It should not, for example, be like playing golf.
Right, if we're playing Golf, and let's just say even that we add the word team golf to that.
then what would happen is we'd each play our own holes, and then we would add up our total scores to see what our team score was.
So individual effort combined together to create a team approach.
That's not the kind of team sport we're talking about.
We're taking more about something like soccer, football, basketball, baseball, cricket.
Pick your favorite team's sport.
The dynamic here is people on the field at the same time with the goal, working together to accomplish that goal.
If we're playing soccer together, or as most of the world says, football, if we are playing that sport, one of very first things that any beginning coach
will say to their teams is, make sure you're talking to each other out there.
Call out to each other, call for the ball, say I've got it, yell for someone else to do something that you need them to,
communicate.
We don't need two people running into each to try to the same thing.
Well, that same dynamic should apply to how teams actually accomplish work when they use the Scrum framework.
Working together, common goal, on the field at the time.
I'll give you a little bit of an example here.
Oftentimes, this is what I see with new teams.
Let's say we have a two-week sprint.
Developers will take eight of those two weeks, eight or those 10 days, to actually do their development work.
And then at the end of it, they'll throw it over the fence to testers who then scramble because they have two days left in the sprint to actual test all
this work, Well, you can imagine how much carryover work happens in that scenario.
The testers feel responsible that they weren't able to finish all the work when it's not really their fault.
They weren' given the full two week sprint, they were given two days of the sprint to do their work.
So that's gonna work, what I like to challenge my teams with is to say, What would it take for you to get something all the way done,
matching all of your definition of done in the first two to three days of the sprint?
Now, I'm not telling them to all work done but get SOMETHING done.
How would you have to change how you work in order to accomplish something in first 2-3 days?
Well, you can imagine the answer here.
We've got to team up.
And we've gotta break our stories down to their smallest component.
Those two disciplines are at the core of how a team should be working.
Consequently, how does this relate back to the daily scrum?
Well, if my team is playing the sport like golf, then the Daily Scrums are unimportant.
I'm going to say what I did, but no one else cares because they're not doing it.
They're no working with me.
But if I am working on a team sport environment, then it's vital we talk to each other so that we don't both go after the ball at the same time.
It's viral that you know what I've done so you can accomplish your work for that day.
That's what i'm looking for when I observe the Daily Scrum.
Are we playing Scum as a Team or are we as individual contributors?
What does your team do?

Improve Teamwork: Stop Starting. Start Finishing.

Transcript

There's a phrase that a lot of agile trainers and coaches use that I think is very vital to understand when we talk about something like the daily scrum
and how the team does their work.
The phrase is stop starting, start finishing.
Now, many of you have probably heard that phrase before, but what do we mean by it?
What we means is it's very easy to begin something new.
but it takes discipline to actually carry something across the finish line.
If I'm a developer on a team and I finish up my work, It's easy for me to begin something new, but it's harder for to try to help my other teammates to
get something else across the finish line.
And that's what we would prefer, right?
We wanna get things actually over the finished line, so here's where I'll give you a tip that I have found to be very vital in helping teams to to Get
this dynamic of how they work together.
That is to institute what we call a whip limit on the work of the sprint.
That term, if you're not familiar with it, stands for work in process.
So we're instituting a limit to the amount of work that can be in-process at any given time in a sprint If I am on a team that accepts five items into
their sprint, I want a WIP limit that's something along the lines of one to two.
Not five.
And a lot of teams will take that five approach.
Each developer will grab their own story and go off, put their headphones on, and do their work.
But if I have a WIP limit of two, and I've got five developers, only two stories can be in process at any one given time.
So as a developer then, I am forced to approach that with a sense of, how can I help?
And that's what we want to instill in our team.
This is about teamwork.
Rather than starting something new, Let's stop that, let's finish what we've already started as a team.
So maybe that will help your team, stop starting, start finishing.

Daily Scrums Make Teamwork Possible

Transcript

One of the very important things to keep in mind when we think about daily scrums is that daily scums help team finish work.
It helps them get across the finish line.
it helps him to actually get to done.
We've talked about working as a team, we've talk about not being in individual silos.
If we're meeting up in a daily Scrum and we are not working in that way, then the conversations we have in the daily are vital.
If we're all looking at our phones while everyone else is speaking, we are not working together.
Why are we looking our our phone?
Because I don't care what someone else's saying.
It doesn't impact what I'm going to do today.
But if we working as a team, then those conversations become vital.
That's something that we have to have in order to get our work done.
Its important to understand that route here.
How are working?
If we want to play this team sport to win, then we've got to get as much over the finish line as possible.
When we think about how teams actually talk to each other in a daily Scrum, you don't have to convince a collaborative team that is working as a team,
that the daily scrum is important.
That's not part of your job.
You don't have to do that because the value of the Daily Scrum is intrinsic to that team.
They understand that they have do this.
And that's all based on just the way that that is team is working.

Tip 1: Eliminate the 3 Questions

Transcript

I wanna make sure that I leave you with some tips on things to do, things that you can do to make this a better event for your team.
And the first big tip I have for you there might be a little controversial to some that have been around for a while.
Kill the three questions.
Now if you're not familiar with what I'm talking about, earlier versions of the Scrum Guide listed out three questions as a possible format for a way to
run a daily scrum.
That was for each person to answer the questions, what did I do yesterday?
What do I plan to do today?
And do have any impediments in my way?
This was intended to be a way for the teams to have a starting place, a jumping off point for conversation about what needed to happen over the next 24 hours.
Yet what it actually became was a self-centered kind of approach to doing the daily scrum.
It was an individualistic mindset, and it actually encouraged teams to think of this as what is my responsibility versus what are we responsible for as
a team?
So my first tip to you is if you're using the three questions and you are not getting a lot out of the Daily Scrum, try a different format.
Try something else.
There are other ways of running the daily scrum, And I highly encourage you to experiment with it.
Ask your team, hey, if we didn't do these three questions, what format could we give for this that would actually be helpful?
What format would help us to plan our day's work, inspect our progress, and change our plan for the next 24 hours?
So that's tip number one, kill the three question.
Now, in the next video, I'm gonna talk to you about the second tip.
Hold on to your seats because the 2nd one is to bench your scrum master.
I'll talk about that in a next one.

Tip 2: Bench the Scrum Master

Transcript

As I said in the last video, my next tip is to bench the Scrum Master.
Now, you might be a Scum Master and hear this and think, wait a minute, Brian, what are you saying?
Are you are saying that I'm out of a job?
Or you're saying my team doesn't need me?
No, I am not saying you out-of-a-job.
I think that you very needed on a scrum team.
But I AM saying, that the scrumb team does not need you to facilitate this event every time it's run.
Again, I said this early in the videos, but I just want to emphasize when a team is new, yes, they probably need some help facilitating this event.
But our goal as a Scrum Master should be to release it, to turn it over to the team as soon as possible.
If I am the focus of the event as Scum Master, i'm doing something wrong.
The event isn't for me.
It isn' about me, In fact, what I used to like to do when I was in person with Teams is I would put the developers in a circle,
the product owner and I, would stand outside the circle.
I wanted the developer to understand, this is your event.
We're just observers.
we're here to help you.
If there's anything you need our help with, we are here answer those questions.
But it's not about us.
It's about you!
The sooner you can help your developers to Hey, I'm releasing this to you.
You take ownership of this.
This is your event.
Then the sooner I think that you'll get really the maximum value out of his time that they spend every day together.
The third tip I am going to talk about in the next video is really about getting back to basics.
So I'll talk to about that one in next one.

Tip 3: Focus on Finishing by Walking the Board

Transcript

I've seen a lot of discussion around performance metrics and trying to understand the progress of the team.
I think we need to think back to the Agile Manifesto for guidance in this area.
Working software is the primary measure of progress.
Now, let me make a little disclaimer.
If you don't work on a software team, just replace that word software with products or whatever it is that you make.
But whatever that is, it's actually working finished, whatever that product is, that's the primary measure of progress.
So, it is important for the team to keep in mind, working software is the priority measure progress, and if our goal is to get as much working over the
finish line as possible, what would we need to do to that here in this sprint?
that should be the focus of the daily Scrum.
My favorite technique to facilitate a daily scrum is to in some way shape or form project the sprint backlog.
Now that if I'm using something like Jira or some software tool I can probably put that up on a screen somewhere.
If it's not if i'm, using more of a physical board hopefully I, can roll that into the the room so people can view it.
Either way, I want the focus to shift from person to the commitment that we've made.
Our sprint backlog is the plan that put together in sprint planning.
It's what we all looked each other in the eye and said, hey, we're gonna get this work done.
I've got your back on this.
Uh, i'm gonna hold you accountable to getting this done, will you hold me accountable as well?
We're a team, were gonna accomplish this together.
So why wouldn't we focus on that every day in our daily scrum?
If you do that, then you can take a look at what items are in process at the time, talk about what needs to be done to get those across the finish line.
If if you've taken my earlier suggestion to put in place a whip limit, a work in-process limit that becomes even easier to have that discussion because
we're not pulling a new item into in processes until we finish one of the previous ones.
So the focus of the team becomes, what can I do to help get this across the finish line?
That's the conversation I wanna have in a daily scrum.
That what I want the teams to understand is the point of why we're here.
So feel free to use that, feel to experiment with that.
Or if you don't, if use some other technique, great.
If something's not working, that should be built into the DNA of you and of your team.
Hey, this isn't working.
We have to try something new.
Let's run an experiment, and then let's inspect and adapt afterwards.
So, if you're going to abandon the three questions, maybe try walking the board.

Two Key Takeaways

Transcript

Daily scrums are a time for the team to inspect their progress and adapt their plan accordingly.
When teams hate their daily scrum, it's usually because they have misunderstood the purpose of why they're having this 15-minute event every single day.
And if teams aren't listening to each other, It's likely an indicator of a much bigger problem, which is actually how the team is working together throughout
the course of the sprint.
There are three tips, remember, to how to get more out of your daily Scrum.
One, kill the three questions.
Two, bench your Scrum Master, and three, walk the backlog.
The two most important things that I want you to take away and remember from this are remind the team of the purpose of The Daily Scum and give your teams
the power to inspect and adapt The daily Sc rum to be the most effective that it can be for your team.
the way that your Team process as a daily scrum might be different than every other team in your organization.
That's okay.
You're made up of different people.
Your solution shouldn't necessarily work for every team.
In each team that you're on, find the solution that works for that group of individuals and help them to keep in the forefront of their mind the purpose
of why we're here.
Inspect our progress to the sprint goal and adapt our plan accordingly.
If you go to the URL shown here, you'll find some great tips on surviving the Daily Scrum.
The blog, too, has a ton of content on Daily Scrums, overlapping work, sprint backlogs, and you name it.
I strongly recommend you watch our Mistakes series.
with the most frequent mistakes scrum masters, product owners, and teams make, AND how to correct them.
Thanks for watching this series.
I hope you got a lot out of it.
And I HOPE that your daily scrums can now be an effective use of that 15 minutes every single day.

Let Go of Knowing

You undoubtedly have a firmly held set of convictions about what is necessary to do agile well. These convictions have served you well—your teams have delivered better products more quickly and more economically than before they were agile. But could some of your firmly held convictions be holding you back? And have you ever wondered why some of your most agile friends are similarly firm in their own opinions—even ones that are the exact opposite of your own?

Learning from an Experiment in Estimating

Transcript

Let go of knowing. I'm sure you know that I am a big proponent of Agile. You almost certainly know that I like estimating and planning and have written a book on that. I've written about these topics and I believe in these things because I have seen them work. But hey, I could be wrong. As a matter of fact, i hope time has proven me wrong about some of the things I written. Agile is about trying things. It's about experimenting, having a hypothesis, a best guess about the best way to achieve the result. But sometimes things don't work out for the better. And a big part of being agile is being able to admit that, to learn from it, and move on. Let me give you an example about deliberately setting up an environment where we could learn, even when we were wrong. Back in 1999, I was the vice president of engineering for a public company in Colorado and I had a really good boss, the CEO. Things were going very well for this company. Our projects were finishing on time and our products were successful. I wanted to take advantage of all that to get good at something we were not yet good, estimating. Our CEO knew that not every project would finish on time and not ever product would make a ton of money. He wanted that, of course, but he was realistic and knew it wouldn't always happen. I took advantage of this good situation, a successful company with a great CEO, to undertake an experiment. i told each of my development teams they had to estimate differently from every other team. When I first told everyone that each team had to estimate differently, it led to a wide range of estimating approaches being tried. We had teams doing good old task decomposition in which you think about the work and break it down into a big list of tasks. This is where you identify the parameters of an estimate and do things like multiply the number of expected lines of code times the domain complexity divided by the average number years of analyst experience plus the square root of the architect's birth date, and that tells you a due date. We also had teams estimate with what today we'd call story points and ideal days. Most of our projects were two to three months long. And every time a team finished a project, they looked at how well their estimating approach had worked. They looked how at well what other teams were doing had work. And they decided what to do next. Based on the rules I'd put in place, each team had to try something different on each new project. It didn't have to be dramatically different. Just a little different would do. But they had try to something When we first started, I thought an approach we'd been dabbling with called Experienced Senior Programmer Days would turn out to be the best. I wanted it to win. And not just because it had the great acronym of ESP Days. The premise behind this approach was that each team member would estimate as though he or she were an experienced senior programmer. It was a way of normalizing what today we call ideal days. And it was an attempt to get around the problem that your ideal day aren't the same as mine because we have different skill and experience levels. These teams had a definition of an experienced senior programmer, and each team member estimated as though they were that person. So people were estimating for themselves and then adjusting longer or shorter for this archetypal experienced senior programmer. It was a nice theory and it had worked well on an initial project. But it worked because the people on that initial were all pretty close to the archetype. When other teams tried it, we realized it wasn't going to work. it is hard enough estimatin how long something is going take you to do. This approach required everyone to estimate how long it would take a mythical person to do. Bad idea, but I had thought it'd work. Fortunately, although I went into that experiment thinking experienced senior programmer days would be our winning idea. I was open-minded enough to realize, hey, I could be wrong about this. And the rest of the department went in to the experiment with a similar attitude. After the first projects finished, and teams were picking their second approaches, we saw teams begin to coalesce around certain ideas. Parametric estimating was out because it relied on having something like lines of code or function points to multiply by. And estimative lines-of-code was no easier than directly estimated the length of a project. Task decomposition was up because is was too time-consuming and because was impossible to think of all the tasks anyway. Through nothing I did, other than put in a rule that said no two teams can estimate the same way, our teams were converging on approaches around story points and ideal days. There were still some big differences in how teams thought about those, but the differences were smaller than when some teams where advocating parametric estimating or task decomposition. These teams, in fact, that entire development organization, had learned quite a bit about how to plan projects. But as the teams were not yet close to agreement on an approach, the experiment continued. We had teams experimenting with different number sequences, 1, 2, 4, 8, 16, or the Fibonacci sequence, for example. Other teams experimented with whether it was better to always round estimates up, always around estimates down, Still other teams experimented with how to conduct estimating meetings. Some teams experiments with what turned into planning poker. Other teams tried more traditional Delphi and wideband DelPhi approaches. Others teams try creating checklists of things to consider, or having only one or two people estimate each product backlog item.

Changing Our Minds

Transcript

Based on what I've been writing and training about for the past 10 years, you can probably imagine where we ended up. But where ended isn't the point of this story. The point is that when we started this experiment on various approaches to estimating, I had an idea of what would work. I told myself, You know what? I could be wrong. So we start experimenting. And it turns out I was wrong, But you know what I learned from being wrong? Enough to write Agile Estimating and Planning. You know, what else? Parts of this book could be wrong. In fact, pages 238 through 240 are, as are other pages. I wrote them because they're what believed then, but they are not at all what believe today. And that's the key to success. not just in this story, but with Scrum, with Agile, and with life for that matter, being willing to learn. Everyone in that company knew we were not good at estimating and we wanted to get good estimations. During the process we had some very fierce arguments but we didn't let those arguments get in the way of learning from what we're doing. In putting this talk together, I was at first reluctant to call these team members open-minded, because I remembered some of those fierce debates. But I looked up open minded in a dictionary, and it just means willing to consider new ideas. And yes, fortunately, just about everyone on the teams in this story was willing consider ideas, even those who were very opinionated were at least willing And you know what? That's all we needed. The courage to say, hey, I could be wrong. I think it's vital that we approach Scrum with an open mind. Fine. Go into a situation thinking you're right. Think like I did, that experienced senior programmer days is going to be the answer. but reserve that little bit of open-mindedness that says, hey, I could be wrong. What was the last thing about Agile that you changed your mind about? It could something relatively small, like deciding one week sprints are better than two week Sprints. Or it could it be something that required a leap of faith, Like including your product owner in your retrospectives. Whatever it is, Can you think of something that you once firmly believed about how to run an Agile project that that no longer believe? This type of openness is important to the progress of Agil. Think about Scrum would look if early Agiles had never thought, but hey, I could be wrong. I asked a few prominent Agilles for things they changed their minds about. I want to share a few with you. Ron Jeffries and Chet Hendrickson are well known for having abandoned estimating. That's like a dagger to my heart. They used to advocate estimative product backlog items in story points, but they thought, hey, we could be wrong. And now coach teams not to estimate at all. Ken Rubin, who gave the 2014 Scrum Gathering keynote in New Orleans, was once adamant that the scrum master not also be part of the team. He now says a scrumb master can be a development team member. Mitch Lacey, author of The Scum Field Guidebook, like many of us, took the daily scrumm as gospel. You have to do it daily. He's since told himself he might be wrong about that and says that some high-performing teams can get by without a daily scrum because they're essentially doing it every minute of every day. Robert Martin, Uncle Bob of the Clean Coder Videos, who pushes all programmers to take their craft seriously, has told me he was a complete skeptic about test-driven development when he first heard about it. He was so skeptical he flew to Oregon to pair program with Kent Beck and try test driven development. he says that experience rocked his world and he changed his mind. Jeff Sutherland has always stayed open-minded, and he adjusts his recommendations based on what he sees working and not working. When Jeff invented Scrum, he established the goal for teams of being able to release at the end of a sprint or perhaps every few sprints. By 2005, though, He'd started to write about the importance of decoupling releases from sprint boundaries. In his first book on Scrum, The Black One, Ken Schwaber wrote that one of the main duties of The Scum Master was to make sure there were enough chairs at The Daily Sc rum. I'm sure Ken doesn't believe that anymore. Gene Tabaka, author of Collaboration Explained, used to focus on sprint planning and sprint reviews as a team's main inspect and adapt checkpoints. But she's told me she since learned that for teams she works with, that isn't usually enough. And they benefit from a form of mid-range planning or road mapping in order to really create awesome products. Henrik Nyberg, author of the Scrum and XP from the Trenches book and the great Spotify culture videos, once believed that each team needed a dedicated Scum Master. But he told himself, hey, I could be wrong. and now says it's fine for a full-time scrum master to perhaps work with up to three teams. Henrik also once believed that teams should be stable with the same team members from sprint to sprint. That's something I still believe. But Henrik is one of the most open-minded people you'll ever meet and says, sometimes it works really well to have dynamic teams where people switch around as needed. He's got me saying, hey, I could be wrong about this one.

Early Scrum as Waterfall, But...

Transcript

Scrumbutt is a well-known joke in our world. Our team does scrum, but we don't have anything shippable at the end of a sprint. our team scrums, we do three-month sprints. We like to make fun of scrumbutt. But can't you imagine early Scrum projects being called waterfall but? Early Scum teams must have existed in waterfall organizations, but they were trying something new. I'm sure what they we're trying was laughed at and called Waterfall But. Picture their coworkers laughing as those early scrum team members said, we do waterfall, But we integrate weekly. Or we Do waterfall But We test all the time. What's new is often laughed at. A huge challenge is that we can't know in advance which new practices are going to work and which aren't. We have to try them and see what works. In doing so, we have approach each new practice as an experiment saying, I think this will be better than what we're doing now, but hey, could be wrong. Saying I could be wrong isn't nearly as hard as admitting after the fact I was wrong. In fact, my wife likes to tease me that I have a hard time admitting when I'm wrong about things, at least in our personal lives. Back in the 1990s, My wife and I used to watch a TV show called Mad About You. It starred Helen Hunt and Paul Reiser as a 30-something married couple living in New York. In one episode, the husband gets a chance to invest in a virtual reality company. But as an early stage investor, he gets to try out the product before he invests. So they show him putting on these virtual-reality goggles and these Virtual Reality gloves. And in this particular product, user gets the conjure up a Virtual reality in which to interact. Well, the virtual reality the husband conjures up is of himself rubbing sunscreen on a swimsuit model. And after that, he's ready to invest, except his wife needs to try out the product. You can see him getting nervous, because if that's the reality he conjured up, what is his life going to invent? Well they show her putting on the Virtual Reality goggles and the VR gloves, And the reality she conjures up is of her husband repeatedly saying things like, I was wrong. The vastness of my wrongness was staggering. My wife has that clip saved on YouTube and shows it to me any time she says I'm refusing to admit that I am wrong

Admitting I Was Wrong About Retrospectives

Transcript

Unfortunately, I have a much easier time admitting when I'm wrong about something involving work. Let me share with you a story about a time I was wrong something about involving Scrum. Back in its early days, Scum didn't have sprint retrospectives. That's probably not very surprising. No one thought about it at first. But you're probably thinking that as soon as someone did think about, we all quickly added sprint-retrospectives to our sprints. No, not really. Many people did, of course, quickly add retrospectives. But some of us, me included, did not. That sounds crazy now, and it's something I was wrong about. See, I can admit that. Let me tell you why I My objection was basically, why should a team member wait until the end of the sprint before sharing with the rest of team a suggestion for how they can improve? If I come up with an idea that will help us build better software, I should share it with my teammates immediately, not at the of sprint. But here's what happened. Suppose I do come up with some great idea in the middle of some day in a sprint. I am not going to stop programming right then to tell everyone about it. Besides, you're all in your own things. So I tell myself, I'll tell you about at tomorrow's standup. But at tomorrows stand up I can't remember what it was I wanted to you. What teams learned, what I learned. was that it was better to set aside a designated time to talk about ways to improve. Of course, it's theoretically better, to jump up and tell a team about a great new improvement right when you think of it. But you probably won't do that. So set a side a designated time every sprint. There's nothing that prevents you from jumping up, and sharing some amazing improvement immediately, if you do happen upon one. I was wrong. I'd thought that just talking about improvements whenever someone thought of one would be better. It wasn't.

A Mind Is Like a Parachute

Transcript

Being able to admit when we're wrong is important to maintaining an open mind. We can be opinionated, but we have to remain open-minded. Frank Zappa, the musician, said, a mind is like a parachute. It doesn't work if it's not open. Here's my challenge for each of us. Today and throughout this conference, go into each session with an opened mind, Sure, bring your opinions, but go into each session thinking, hey, I could be wrong. You know what would be even better if every speaker, every presenter, Every trainer, and every agile guru you encounter here was also thinking hey I Could be Wrong. Why? Because then we might all be open-minded enough to learn a little something, right? I'd like everyone to practice saying this with me. Let's all say this together. I could be wrong. That should feel liberating, admitting that we don't always have to be right. But it doesn't feel that way. So let's take a look at some ways we can ensure our minds remain open to new possibilities.

Question Your Assumptions

Transcript

Back in the 1970s, California had a senator, S.I. Hayakawa. The senator had young son, and one evening, he was drawing a bath for his son. When the tub was full, the senator put his sun in tub. But as soon as he did so, his sons screamed, Dad, make it warmer! The Senator, suspecting that, if anything, that tub water was too hot, reached down and felt the water. It was indeed too-hot. yet his son was screaming for him to make it warmer. But make-it-warmer means add hot water. So what's going on here? Question your assumptions. I think I know what makeit warmer means, but I could be wrong. Fortunately, the senator questioned his assumptions, when his sons said makeIt warmer, he meant make It closer to the state I call warm. To a young kid, there were temperatures of cold, warm, and hot. Make it warmer meant move the temperature closer to warm. Fortunately, Senator Hayakawa realized this and turned on the cold water. Back when my daughters were that age, if they'd said, Dad, make it warm I wouldn't have thought about it. It would have cranked up the hot water, My problem is that I would have not stopped to question my assumptions. I just would've gone along with the seemingly reasonable assumption that make it warmer meant to add hot water. Questioning our assumptions is vital to remaining open-minded. Let me give you another example. When I was seven years old, I on a family vacation driving up the coast of California. And I think I was being a particularly obnoxious seven-year-old. I probably was pestering my dad with questions. And my Dad took out a piece of paper and he drew the image on the screen. Two rectangles on top of three rectangules. My Dad told me that he would give me $100 if I could draw a single line that went through every line segment once and only once. $ 100 to any seven year old is a lot of money. But I checked the inflation since I was seven years old, and that would be over $650 today. All I had to do was to draw one line through each line segment. I could start inside or outside the rectangles. So I tried for hours to get it right. And when I have a solution, like the one on the screen, I'd hand it to my dad. and then I'd try some more. And I had my dad another solution. He'd say, you went through a line twice. I tried for the entire drive up the coast. We got to a campground that night, and I try by flashlight. For the next 12 years, any time I have a spare few minutes or was bored anywhere, I remember trying in the margins of my notes during high school classes. I remember sitting in the waiting room at a doctor appointment. For 12 years, I tried to solve this problem. It wasn't until sophomore year of college and a lecture on graph theory that I even began to question my assumption that there was a solution. Some of you by now will have recognized this as a variation on the famous seven bridges of Konigsberg problem that Leonhard Euler proved has no solution. But because the problem had been given to me by my loving father, I assumed it could be solved. When we fail to question our assumptions, we can stubbornly repeat our mistakes over and over, and, over. For 12 years, I failed to question my assumptions. Question your assumptions because you know what? Your assumptions could be wrong. There are really two things that make assumptions so dangerous. Confirmation bias and hindsight bias.

Confirmation Bias

Transcript

Confirmation bias is our human nature tendency to look for information that confirms our beliefs. Suppose you don't like one week sprints. You're convinced they're too short. If you're going to hear, let's say, eight anecdotes about the evils of one-week sprits while you are here at this conference, you'll hear just as many anecdots about evills of sprint of any other length. But because you're looking for it, you'll be more attuned to noticing the problems with one-week sprints. A couple of years ago, my daughter decided to buy a car. She wanted to by a Nissan Juke. she was convinced she is the first person to discover that car, but between deciding to buying one and actually buying, she started to notice them everywhere. This is confirmation bias. We need to be aware of this because confirmation bias convinces us that things we believe are true, even though they may not be. Nissan Juke's were not suddenly everywhere. My daughter was just more observant of them. One-week sprints do not create more problems. But if you think they do, you're likely to notice that more while you are here. When you go back to the office, You'll be more convinced than ever that one- week sprint cause more problem than sprin of any other length.

Hindsight Bias

Transcript

Somewhat related to confirmation bias is hindsight bias. Hindsight bias makes us forget how ignorant we once were. I love being a writer, but one thing that absolutely sucks about it is that your words are out there forever. You might forget that you ever believed a certain thing, But if you wrote it in a book, someone will eventually remind you about. Here's an example that happened to me that has to do with sprint planning. I'm a pretty strong advocate that a team should leave the sprint planning meeting without having assigned all the tasks to specific team members. That is, we should live with a big pool of tasks, but we shouldn't leave with some tasks assigned to you, some to him, her, and me. Instead, just have a pool unallocated tasks and each day we figure out who should work on what. Well, that's not what I wrote in User Stories Applied back in 2003. Back then, I write that the team puts a name next to every task, because up until then that was how I'd been doing it. I changed my approach shortly after that book came out. So a year or two ago I'm teaching a Scrum class and I am teaching the approach where we do not put names on tasks. And I am teaching that approach as though I've believed it my entire life. Because as far as I can remember, that is what I believed. But as soon as we finish the little discussion on that topic in class, someone asks me about what i'd written in user stories applied. This is an example of hindsight bias. It convinces us that we've always been as brilliant as were are now. So while you're here at the conference, be aware of your biases. Be aware that you might only be looking and listening for things that back up what you already believe. Make a deliberate attempt to seek out things challenge your assumptions instead. You might be surprised with what find.

Intellectual Humility and the Dunning-Kruger Effect

Transcript

So, the first thing we need to do to stay open-minded is question our assumptions. The second thing that we should do is exhibit intellectual humility. I came across this term last year in an article about hiring practices at Google. the article said Google likes to hire people who exhibit Intellectual Humility. This term caught my attention because I remembered it from college. I took a lot of philosophy classes in college. In fact, I could have minored in philosophy. But to have a minor, my college required us to pay an extra $36 fee. All you got for that $ 36 was they would print minors in, and in this case, philosophy on the bottom of your diploma. Well, wasn't going to be $26 just to that printed on my diploma, so I don't have minor in Philosophy. So when I came across the term intellectual humility, I remembered it, but didn't remember what it meant. So I had to Google it. Perhaps if I'd paid for the minor, wouldn't have had Google. Anyway, intellectual humanity is an idea from John Stuart Mill back in the 19th century. Mill said it was a virtue to be able to imagine one of your most fundamental beliefs being wrong. Intellectual humility also has to do with understanding the boundary between what we know and what merely believe. As an example, I think sprints or iterations are a good thing. I don't have any proof of that, but I do think there is something valuable about a team getting together at the start of a period of time, deciding what to and then getting to the end of the period and seeing how they did. I believe that sprints are valuable. I have no scientific proof of that. It would be intellectually arrogant of me, the opposite of intellectual humility, if I were to claim this as a fact. So, intellectual humanity has to do with knowing what you don't know. And I'm going to repeat that, Intellectual humility has do to with what knowing you do not know, Here's a good example of a time when I was not intellectually humble. A couple of years ago, I asked a question while teaching a Scrum Master class. I don't remember the exact question. And the specific question isn't really important. But it was one of those, who does such and such in Scum questions? And I knew the answer was the Sc rum master. So I opened my mouth to say that. Before I could answer, Someone from the other side of the room yells out, the team. And he was right. My lack of intellectual humility had me ready to answer a question without pausing to really think about it first. Shortly after this, I read an article in the New York Times about a professor from The University of Chicago. This professor had a great attitude that really captured intellectual humanity for me. He said, When you're teaching, always assume there is a silent student in the class who knows more than you do. I remind myself of that as I start each scrum class. i want to share one more example of a lack of intellectual humility. Anyone without talent who has ever appeared on America's Got Talent. Think about some of the horrible singers who show up on TV and we laugh at how bad they are. They must know they can't sing. Well, it turns out they don't know. This is due to something called the Dunning-Kruger effect. The Duning- Kruger Effect says that the less you know about a subject, the least you think there is to know that subject. It's what lets amateurs think they're experts. A horrible singer on America's Got Talent is a little better than her friends, so she thinks she's talented. Her friends don't want to hurt her feelings, so they let her believe it. All of a sudden, she's on national television. Instead of going on TV, She might want stop first and think, I could be wrong about my talent. The less we know about something and the less experience we have doing it, the worse we are at gauging the depth of our knowledge.

Quality After 6 and 24 Months

Transcript

A little knowledge is a dangerous thing, right? Agile is no different. Along with a couple of colleagues, I am involved in a website called Comparative Agility. This is free website that allows teams to assess how agile they are. Team members are presented with the set of statements and then decide if those statements are true or false. For example, one statement is, management sets goals but doesn't tell team members how to achieve them. Team members assess whether that is false, mostly false neither true nor false mostly true or true. Another sample statement team member would see is all bugs are fixed during the sprint in which they are found. The questions on the comparative agility assessment are grouped into seven different areas called dimensions, such as teamwork, requirements planning, technical practices, quality, and so on. The questions about quality have to do with the practices that produce quality products. Things like, is the product owner involved in determining acceptance criteria? Are tests being automated? Our tester's involved right from the start and things like that. One of the nice things about the Comparative Agility website is that it allows us to track a team's answers over time. We can see how agile they are today, and then again at some point in the future. I want to share something interesting I found with some, not all, but some of my clients involving the quality dimension of The Comparable Agile Assessment. And that is that teams with six months of experience with Agile had higher quality scores than teams two years of Agiles experience. What you see on the screen here are the results from one company. These are averages for all teams six month into their Agil adoption and then two year into Agils adoption. And as you can see, they appear to be getting worse at producing quality products. Yet I could take every one of you to visit this company, and we would all agree in some subjective manner that they have improved over the 18 months between these two periods. There would be no doubt in our minds, but here they are saying they'd gotten worse. So what happened? Remember, these results come from self-assessments. This is an example of the Dunning-Kruger effect. When we asked these team members with six months experience if they were testing early and if were they testing often, they said, testing is through the roof. It's all we do. We automate all the time. we write two or three, sometimes even four tests per sprint. To their agile novice minds, that was a lot. They were like the horrible singers who decide to appear on America's Got Talent. They didn't know what they didn' know. But when we asked them again when they had two years of experience, they were thinking, wow, we test all the time, but it's not enough. We have so far to go. Two years in, They knew better. They know better because they knew more. So especially when you are first learning, Remind yourself of the need for intellectual humility. Then, just when you are certain you've got something mastered, remind yourself how far you probably really have to go to really master something.

Avoid Brand Loyalty

Transcript

I want to talk about one last thing that sometimes prevents us from being open-minded, and that is becoming too loyal to any one brand of Agile. If we want keep learning and growing, we cannot become too strongly attached to a single brand Agil. A few years ago, I was witness to an online discussion involving Ron Jeffries. At the time, Ron was considered much more of an extreme programming advocate than a Scrum guy. And Ron, was in a discussion with some Scum folks. The discussion started to shift into the direction of XP versus Sc rum. and Ron had a perfect comment about the brands. He said, I'll drop mine if you drop yours. For many years, i've said I consider myself an unbranded Agilist. Sure, I get associated with Scrum because it's largely what I do, and it was what started with many years ago. But I like to pull ideas from everywhere. I'm pretty much known as an advocate of user stories and story points, both ideas that come from extreme programming, but ideas I started using on Scum projects. Like Ron Jeffries said, ''I'll drop mine if you drop yours.'' I'm anxious for everyone to drop all the brands someday. I don't even want what we do to be called Agile anymore. i just want it to become software development again. So while you're at the conference, would you do me a favor? Go to at least one session on a topic you've completely dismissed. If you are a Scrum person through and through, go see what Kanban has to say. if you firmly convinced that Kanbon is the only way to go, Open your mind to the possibilities of safe. If you're a hardcore techie, go to a session on softer skills like facilitation or retrospectives. And when you do, remember the things we can do to stay open-minded. Question your assumptions, exhibit intellectual humility, and let go of brand preference, even if only for a moment. I think you'll be pleasantly surprised.

Scrum Rules

Transcript

I've said we need to be open-minded, but please, don't misunderstand me. I don' mean we have to question everything. The sun will come up tomorrow. That is a certainty. There's no need think I could be wrong about that. Similarly, there are certain rules within Scrum we can be sure about. If we change those rules, We're creating a process other than Scrum. It might even be better than Scrum, but it's not Sc rum. And for a few minutes, I want to stick with just Scum. If we do, there are certain rules we DO NOT want violate. We don't need to waste time pondering whether they're right or not. These are things like sprints can't be longer than a month. Be done with something by the end of the sprint. and get together at the start of the sprint and figure out what you'll do in the Sprint. And for that last one, it's not saying there's some grandiose sprint planning meeting. It could just refer to a 30-second discussion. I wouldn't even call that a meeting, there is just some initial discussion of what are we going to work on that just helps team members all pull in same direction during the We want to be careful here. We don't want turn Scrum into a list of rules. In fact, I've deliberately never sat down and created what I'd consider a complete list Scum rules I'll probably need to someday just for myself, but I resisted so far. The Scrumb Guide or Agile Atlas are probably as close as we need. The danger with a list of rules is we start to lose creativity and spontaneity. So it's important we keep the list scrum rules to an absolute minimum. I think it is good to have a small set of rule that define what scrums is. Things that if you aren't doing them, the scrumb police can knock on your door and rightfully say, you are not doing scrumm. What that team is doing might be better than Scrum, but if they're violating a Scum rule, it's not Sc rum. Here's an example of going too far with a rule. Are you aware that one of the main books on Scrum says that the daily Scrom must be conducted left to right, starting with the person to the left of The Scram Master? Well, one Of The Scrum Masters at a client I worked with knew this rule and he insisted on it. If it was in the book, then this scrum master was going to follow it. His team knew that this rule was ridiculous, and so they rebelled. They'd go right to left, or they'd randomly, Or people would move around during the meeting. they would do anything but go left to right, like the scrumb master wanted them to do. The team was trying to show their scrumm master how ridiculous that rule is. Going left or right should never have been made a rule. A few rules are fine, but we want to keep them to a minimum.

Practices

Transcript

Frankly, I don't find talking about or thinking about the Scrum rules all that interesting anyway. What I find interesting is thinking of the practices of Scum. Some of practices Scumm teams use are technical and come from extreme programming. Things like test-driven development and pair programming Other practices are more focused on the product backlog. Things like user stories and product backlog grooming, sometimes called backlog refinement. Not all teams do these practices, but that's why we're going to categorize them as practices rather than rules. Having a definition of done is a great practice that many, perhaps most, Scrum teams use. It's not a rule, though. In other words, you can still be doing Sc rum even if you don't have a Here's a really minor little practice I'll mention. Don't start sprints on Mondays. When I first started doing Scrum, all the teams I worked with started sprint on Monday. We didn't even think about it. Of course, sprits start on mondays, it seemed obvious. But Monday's kind of suck for starting a sprint. No one wants to come to work on a Monday, especially if Monday has a big long planning meeting on it, All of a sudden, Monday starts to look like a great day to schedule things like dentist appointments. Because even a root canal can be better than going to a long meeting. Also, we have a lot of Monday holidays. All our presidents were born on Mondays. Monday's are just kind of bad day start a sprint. This is not a common practice. It's not well known. Is not even all that important. It's certainly not as important as the other practices I've listed here. I'd put it in the category of just a nice little optimization that could be helpful for some teams. Sprint zero is another practice that a lot of teams like. Maybe it's not a great practice or even a good one, but it is a pretty common practice, so it worth including on any list of practices. The same is true for task boards, another extremely common practice for scrum teams. When we look at all these practices, it's clear that some of these are more important than others. Some of them are so important, in fact, that I think just about any good scrumm master should be aware of him. Think about a practice like pair programming. Imagine someone walks up to you today and announces, I'm the world's greatest scrumb master. First of all, the world's greatest scrum master is probably not the type of person who would ever say something like that. But imagine someone says it, and you say, that's great. What do you think of pair programming? And the World's Greatest Scrum Master says, never heard of it. Well then, That is not The World Great Scum Master. I'm not saying The world greatest Sc rum master has to have his or her team doing pair programing. but the world's greatest scrum master better know what it is. Even if their opinion is pair programming sucks, I never recommend it to my teams. I'm fine with the World's Greatest Scrum Master having a strong opinion about any of the practices. But this is where I'd hope that that great scrumm master and I could have a conversation. And while we each enter that conversation with a stronger opinion, I'd also want each of us thinking, hey, I could be wrong, because these are the things we need to stay open-minded about. The rules are rules, and we can't fiddle around with those. Fortunately, there aren't many rules and they're easy to live with. But where agile gets interesting is with the practices. Which practices work best? and which combination of practices works best. And does that change by domain? Does it change my team size? That's where things get interesting. That where we need to be most willing to learn from one another. By having opinions, yes, but also by always admitting I could be wrong.

That's a Really Good Argument: My Position Is Mistaken

Transcript

I have not had a chance to watch the recent Cosmos television series, but I do remember the one from 1980. It starred Carl Sagan, who commented on the importance of scientists being open-minded. Sagen said, It often happens that scientists say, you know, that's a really good argument. My position is mistaken. And then they actually change their minds. You never hear that old view from them again. They really do it. It doesn't happen as often as it should because scientists are human and change is sometimes painful. But it happens every day. I cannot recall the last time something like that happened in politics or religion. I don't want to talk about politics and religion, but I'd like to add Agile to Sagan's list. There are too many of us. who are no longer as open-minded about various aspects of Agile or Scrum as we should be. When confronted with a great view that is different from our own, we don't say, you know, that's a really good argument. My position is mistaken. As Sagan says, a good scientist should do. At least we do not say it as often as should. You are investing a lot of time to be here, and you or your company has paid for you to here. It would be a shame if you went back to your job after this is over and haven't changed your mind about anything. To do that would mean you haven' grown or improved. My challenge to each of us, myself especially, is while we are here to find something about which we can say later You know, that's a really good argument. My position is mistaken. Without this willingness to change our minds, we are no longer improving. So let's remain open-minded. Let's question our assumptions. Something you're doing is working for you, but is it working because of something unique to your domain or something you need about your team or about you situation? When someone here tells you about some alternative approach that also works, be open to it. Remind yourself you could be wrong about the general applicability of whatever has been working for you. Let's all remember to be intellectually humble. We don't want to the singers on America's Got Talent who don' have talent. Remember that the less we know about a subject, the least we think there is to know, about that subject. A true expert at Agile realizes he or she can probably never be an expert in Agiles because people are involved and we're hard to predict. And let's not get hung up by our brand loyalties. Sure, we all may have our preferences. I love Scrum. For the most part, it pays my bills. But the two ideas I'm most closely associated with, user stories and story points, Both come from extreme programming. Look around and use the best ideas wherever you find them and in whatever process you found them. Let go of knowing. Be open to experimentation. be willing to say, as Carl Sagan said we should, that's a really good argument. My position is mistaken. If you loosen your grip on your own certainty just a bit, what I think you'll find is a whole world of possibilities, a new path to learning and growth that you might never have considered. But that's just what I think. And hey, I could be wrong.

Product Owner

Explore the Product Owner role, from deciding whether it fits you to setting product goals, prioritizing the backlog, engaging stakeholders, and making better product decisions.

Should You Become a Product Owner?

Transcript

Have you ever considered becoming a product owner?
Maybe you should.
In this video, I'll share the skills needed, which roles often become product owners, and some questions for you to think about to decide if you Should
Become a Product Owner.
If you're new to the channel, i'm Mike Cohn.
I'm a co-founder of both the Scrum Alliance and Agile Alliance.
i help organizations become more agile.
One of the most important skills of a product owner is a solid understanding of industry or domain of product.
I worked with a company developing various medical software products.
Their product owners were nurses and medical doctors.
These product donors were fantastic, but they would have struggled as product-owners for a financial services product, you have to know your industry.
Product owners need to be good communicators.
As a product owner, you will need communicate with various stakeholders, possibly inside and outside your organization.
And you'll also need you communicate team members.
You can be an introvert and be a great product owners, but you WILL need talk with people.
Product owners must also be visionary.
You don't need to be Steve Jobs who can see the future 10 or 20 years ahead, but you need see at least the near future of your product.
To be a great product owner, you must be decisive.
Your team will be under pressure to go fast.
They won't be able to if you have to convene a user advisory group meeting to make every decision.
I want to mention one more skill that would-be product owners ask me about, technical skills.
Should a product owner have spent time as a programmer, tester, or something similar?
No, I don't think this is needed.
I think good product donors need to be familiar with the type of work the team does and the jargon they use.
So as the product of a software team, you don' t need know how to code, but you need what coding is.
Most product owner roles are filled by promoting someone within the organization rather than hiring someone outside it.
This is a direct result of product owners needing a deep understanding of the industry, as I've mentioned.
Since product donors are often promoted from within, let's look at some of roles people have before they become product-owners.
The most common move is from business analyst to product owner.
A business analysts is often the right hand of the product oner, doing portions of job to help the project owner If the current product owners moves on
to a new product or company, the analyst often becomes the Product Owner.
Another common move is from product manager to product owner.
There's no industry-wide agreement on the differences between these roles.
Most common, however, is that product managers are outward facing, dealing with customers, competitors, pricing, marketing,
and so on.
Product owners are then inward facing and working with the team and treating the product measure as a stakeholder.
Similarly, a common transition is from project manager to product owner.
As organizations adopt Agile, project managers often become scrum masters, coaches, or product owners.
A fourth common transition is from a user of the product.
This is especially common for internally developed software.
Users will often have the industry knowledge required.
Those who develop a passion for the products often make great product owners.
Finally, development team members can make great product owners.
This is especially true of UX designers and testers.
So should you become a product owner?
First, you'll want to have the skills I've listed and see a path from your current role to becoming a Product Owner.
Additionally, here are some questions to ask yourself to determine if being a Project Owner is right for you.
Do you enjoy talking to people?
I've said you can be an introvert, but you'll continually need to talk to users, customers, developers, and various stakeholders.
Being a product owner is not something you could do with headphones on all day or by sending emails and surveys.
Are you willing to listen to others?
As product owners, many decisions will be yours to make.
But are you will to listening to developers who suggest alternatives?
You'll also have users, customers, and stakeholders you'll need to listen to and make happy.
Can you handle conflict?
Those stakeholders that you need satisfy, they won't always want the same things.
You will have to list to their positions and then make some hard decisions.
Not everyone will be happy with those decisions every time.
Do you relish being accountable for the ultimate success of a product?
As a Product Owner, you will generally have more influence over the success the product than anyone else.
Does that excite you or fill you with dread?
What do you think?
Are you pursuing a career as a product owner?
Or if you're currently a project owner, what other skills or personality traits are needed?
are there other questions you'd ask to decide if becoming a Product Owner is right for you?
Let me know in the comments.
I read and value every one.
If this video has been useful, click the Like button.
And if you're new to this channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching, and I'll see you next time.

Is Being a Product Owner Right for You: 4 Questions to Ask

Transcript

Here are some questions to ask yourself to determine if being a product owner is right for you.
If you're new to the channel, I'm Mike Cohn.
I am a co-founder of both the Scrum Alliance and Agile Alliance.
Being a product owner is not something you can do with headphones on all day or by sending emails and surveys.
Are you willing to listen to others?
As product owners, many decisions will be yours to make.
But are you will to listening to developers who suggest alternatives?
You'll also have users, customers, and stakeholders you'll need to listened to and make happy.
Can you handle conflict?
Those stakeholders you need to satisfy, they won't always want the same things.
You will have to listen to their positions and then make some hard decisions.
Not everyone will be happy with those decisions every time.
Do you relish being accountable for the ultimate success of a product?
As a Product Owner, you will generally have more influence over the success the product than anyone else.
Does that excite you or fill you with dread?
What do you think?
Are you pursuing a career as a product owner?
are there other questions you'd ask to decide if becoming a Product Owner is right for you?
Let me know in the comments.
I read and value every one.
If this video has been useful, click the Like button.
And if you're new to this channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching, and I'll see you next time.

5 Common Paths to Product Owner

Transcript

Since product owners are often promoted from within, let's look at some of the roles people have before they become product donors.
If you're new to the channel, I'm Mike Cohn.
I am a co-founder of both the Scrum Alliance and Agile Alliance.
The most common move is from business analyst to product owner.
A business analysts is often the right hand of product-owner, doing portions of job to help the product.
If the current product owner moves on to a new product or company, the analyst often becomes the product donor.
Another common move is from product manager to productowner.
There's no industry-wide agreement on the differences between these roles.
Most common, however, is that product managers are outward-facing, dealing with customers, competitors, pricing, marketing,
and so on.
Product owners are then inward-facing and working with the team and treating the product manager as a stakeholder.
Similarly, a common transition is from project manager to product owner.
As organizations adopt Agile, project managers often become scrum masters, coaches, or product owners.
A fourth common transition is from a user of the product.
This is especially common for internally developed software.
Users will often have the industry knowledge required.
Those who develop a passion for the products often make great product owners.
Finally, development team members can make great product owners.
This is especially true of UX designers and testers.
So should you become a product owner?
First, you'll want to have the skills I've listed and see a path from your current role to becoming a Product Owner.
If this video has been useful, click the Like button.
And if you're new to this channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching, and I'll see you next time.

Seven Mistakes You'll Definitely Make as a Product Owner

Transcript

Being the product owner for a Scrum team is a tough job.
There are a lot of competing demands for your time.
You need to keep stakeholders, customers, and users happy, all while being responsive to team members' questions about work in the current sprint.
Oh, you need ensure the team has a steady stream of new work for future sprints.
The job is hard and that means product owners are bound to make some mistakes.
Hi, I'm Mike Cohn and I am the author of three best-selling books on Agile and Scrum.
I help teams succeed with Agil.
In this video, i'm going to share seven mistakes you'll make as a product owner and what you can do about them.
Interrupting a sprint with new work is the first of seven mistake product owners commonly make.
Sprints are supposed to be protected time boxes.
As good product owners, we tell the team that what they work on will not change after a sprint has been planned.
But that's a hard promise to keep when customers and stakeholders change their minds or come up with new needs.
You'll be tempted to bring some of these changes into a sprint rather than waiting for the start of the next.
And you know what?
In some cases, that is okay.
Some changes are very important and worth interrupting a Sprint.
But many others are not, and you need to learn to reign in your temptation to interrupt a sprints with those.
An easy way to guard against these interruptions is to solicit the help of your scrub master.
Make sure they know it's okay to push back against you anytime you want to bring something new into a sprint.
Most scrub masters know they should do this, but sometimes they're afraid of pushing back.
Let them know, it is okay.
I learned to keep my tendency to interrupt in check by writing the new ideas somewhere.
Sometimes I put them in the team's backlog tool.
Other times I'd write an email and schedule it to send to myself the day before sprint planning so I remember to bring that new idea up.
Getting the idea out of your head is often enough.
The second common mistake product owners make is not attending scrum meetings.
While the Scrum Guide says it's not mandatory for product donors to attend daily scrumb meetings, the best productowners make every effort to participate
whenever possible.
If I had a way of identifying the, let's say, 100 best scrumm teams I've ever worked with, I guarantee their product owner participated in the daily scrums.
Similarly, some product owners don't attend sprint retrospectives, or just as bad, their teams don' invite them.
You are part of the overall Scrum team.
Your participation in these meetings demonstrates your openness to improve and encourages team members to also improve as well.
Many product donors make the third mistake, telling the team how to build whatever they've been asked to deliver.
As a product owner, your job is to tell the team what you need.
It's the developer's job to figure out how to fulfill your request.
Suppose your company plans to offer a pool table that will help players learn exactly where to aim.
You tell them that's what they want.
They decide the best way to do that.
Perhaps it's with a series of LED lights around the edge of the table.
Or perhaps it is a voice command saying left, left until the cue is aimed perfectly.
You can avoid telling a team how by considering each product backlog item or goal you give a Team.
For each, ask yourself if you've left the Team multiple ways in which they can fulfill the goal.
As a product owner, your job is defining products or solutions that make people happy.
You probably like saying yes to their requests, but many product owners do not say no often enough, which is the fourth of the common mistakes product
donors make.
For every request you say yes to, you are saying no to some other request.
This can be particularly bad because you're often saying No to a feature someone hasn't requested yet.
Customers, users, and others will continue to identify new needs.
If you've already committed the team's time, You are implicitly saying NO to unidentified requests.
Be careful in how far ahead you commit what a team will work on.
While I encourage not committing all of a team's time too far ahead, it is important for product owners to avoid mistake number five,
not prioritizing far enough ahead.
Going from sprint to sprint, always pursuing what is most important at the start of the sprint is suboptimizing.
Good product donors prevent this by setting slightly longer term product goals.
I recommend setting quarterly product goals.
A three-month horizon provides a good balance between a long-term goal and one that feels achievable.
Additionally, a three month goal is one against which a team can notice their progress.
A sixth mistake product owners make is taking on the job without the authority to do the work well.
When a product owner makes a decision that is later reversed, often by the product's owner's boss, team members quickly learn to think of all decisions
as tentative.
If you find yourself in this situation, you obviously need to have a conversation with your boss or whoever is overruling you.
To structure that conversation, prepare by writing various product owner responsibilities, each on its own sticky note.
You can also use any of the virtual whiteboarding products.
Write things like prioritize the backlog, determine release dates, provide feedback on implemented features, and so on.
then collaboratively separate the items into piles of yours, theirs, and shared.
Achieving this clarity of your responsibilities will often result in gaining more of the authority you need to fully succeed as a product owner.
The seventh and final mistake is not listening enough to feedback.
As a product owner, it's easy to get overly attached to your vision for whatever you're building.
You need instead to listen to customers, users, stakeholders, and yeah, your developers too.
you don't need to do everything any of them suggest.
Remember the mistake of not saying no often enough.
But good products become great when product owners listen the feedback, What other mistakes have you made or seen product owners make?
Let me know in the comments.
I read every comment and I plan to make new videos about some of the problems you mentioned.
This video is part of a three-part series.
Be sure to check out the seven mistakes Scrum Masters and Team makes by clicking the links.
Don't forget to subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching, and i'll see you next time.

Why Most Product Owners Fail (And How to Succeed) with Barnaby Golden

Transcript

Welcome in Agile Mentors.
We're back.
This is another episode of the Agiles Mentor's Podcast.
I'm here with you as always, Brian Milner, and we have a very special guest with us today.
Very excited to have Barnaby here.
Barnabee is an agile coach, also a scrum master.
He is known to us because he is part of our agile mentors community and he's an active member there and has weighed in on several issues and helped people
and mentored people through things there.
So we wanted to share some of the wisdom of, the crowd that we have there at agile mentors, just a few select people that have really contributed and given
us some really good advice there with the podcast audience as well.
So you guys can kind of hear what kind, of stuff is there on the agile mentor's discussion forums.
But we were talking about topics here with Barnaby and about what we're going to talk about, and he proposed one that I really found intriguing.
It was focusing around the underpowered product owner, the Underpowered PO.
And I think that's probably a good place for us to start then.
Barnabee, why don't you kind of just explain to everyone what that idea is, what you mean by the underworld PO?
Sure, of course.
So in fact, what I'll do is I will explain it by giving you the opposite, which is what does a good, effective, powerful product owner look like?
And I was working for an organization a few years back and it was a publishing organization and we had the head of the editorial team was the product's
owner for a particular scrum team.
And this head of editorial had a lot of power and influence in the organization.
They were pretty much a decision maker in terms of the products that the team was building.
And I remember a particular conversation where the theme was talking to this product owner and the teams said, look, we know you want to get this release
out this week, but we've got some technical debt.
We really need to fix it.
I'm going to let me think about this for a second.
OK, I can make the decision on this, which is, yep, you can have your time.
Communicate with others within the organization that the release will be delayed.
And that was such a powerful moment, because in that second, the product owner trusted the team.
The team completely trusted, and it felt slick and efficient and worked really well.
Conversely, I've worked in organizations where in some way, surprisingly enough, product owner is seen as quite a junior role.
So I, I have seen the situation where you have a whole hierarchy of product people and the most junior roll in the product organization is the products owner.
And what happens in that scenario is that the product owner is powerless to make a lot of decisions.
So they have to, they, have, to push them up the tree.
And in, that situation, the conversation between the team and the products owner, is the teams says, yeah, we need to do this thing.
The product says.
Okay, give me some time.
Might be a day and I'll get back to you.
Hopefully I can get in contact with other people within my hierarchy and flows broken.
What's the, team going to now?
They're going, maybe you find something alternative to work on.
It's very frustrating.
And you sometimes get the situation as well, where the, the underpowered product owner will sympathize with something the team is saying,
but will not be able to make a change because they haven't got the authority to do the change.
So they'll say, yeah, I agree with you.
I know what you're saying.
This is a really bad idea, what's being suggested, But I have no choice.
We have a roadmap.
we've got to meet the roadmap Yeah, that's a clear picture.
I agree with you that those are two stark contrasts.
And what I like about the explanation is you kind of highlight the effectiveness of one versus the ineffectiveness of the other,
right?
It's such a dramatic difference when that person is able to make the decisions on the spot, go forward, and the team is just free to move as quickly as possible.
Whereas the other one, it's just holdups.
It's delays and obstacles, roadblocks in the team's way.
So yeah, a really clear picture there.
Just as you were talking about this, I was thinking to myself, well, maybe one of the worthy paths for us to go down here and talking this is trying to
understand a little bit about the why behind it.
Because I think there's just in thinking about it, I, think maybe there are several causes for this or several things that might lead to having an underpowered PO.
What's been your experience?
What kind of things have you seen that may contribute to an Underpowered Po?
I Think the main reason, the biggest driving factor behind it is the feeling that the people with the authority to make decisions do not have time to spend
with a team.
So you've got your head of product or the real decision makers in the organization.
They are saying, I can't spend two, three hours a week with a team.
I Can't go to a planning meeting.
You know, i'm a busy person.
i've Got things on my schedule.
So they see the product owner role as a stand-in for themselves with the team.
And the stand in has lots of time to spend with a team, which is good, and that's a powerful thing.
But at the same time, if they've not got the authority to make decisions, then maybe that time is not effectively spent.
Yeah, it's almost as if they just want a warm body there, you know, like it sits, It's a placeholder.
You're you're here as a, place holder for me.
Cause I can't be two places at once.
I've heard, uh, kind of a couple of things that people will, will frequently point to that a product owner needs to be successful.
And there's sort of this dichotomy of these two things, that are part of that.
That's, the, You know kind, of empowered product, owner that is, is empowered to make decisions.
versus having the availability, uh, to actually be present with the team.
And it's always, it seems like that's a fracture point that sometimes causes this because you have the leaders who, Hey,
I need to make all the decisions, but I don't have availability.
and the people that they know have, the, availability they don' want to empower to, make the decision.
So they're kind of setting up their product owners to fail.
I think it's a classic example as well with when you want to be an agile organization, you can't just have pockets of agility.
You can just to have a scrum team and say, well, that's where we'll be agile in this scrumm team.
The entire organization as a whole has to think in the agile mindset.
And if you wanna be able to adapt to change, then one of the ways you're gonna have to do that is you have the decision makers close to the teams that
are implementing the decisions.
And so you can't have your cake and not eat it, if you see what I mean, in terms of, you, can pick and choose the aspects of agile that you want.
You need to, as an organization, adopt the whole thing.
Yeah, that's always one thing I try to tell people as well is when you're selecting a product owner, when trying to decide who's the right person to be
the product for this team, those are two of the things you have to really consider strongly is does this person have the availability to is this person
empowered to make decisions?
I've run up against leaders before that don't want to empower someone.
And kind of the counterpoint I give them a lot of times is, I don' know, maybe in their head they're thinking this is giving someone free reign to really
long-term decisions on their own, when that's not really the case.
The product owner can be fully empowered, but the decisions that they are making on the spot are just a couple of weak decisions.
You know, it's not a six month decision.
There's going to be sprint reviews.
We're gonna, we're going display stuff and get feedback and we can course correct and all those things.
So once, once you can kind of put it in that frame that, you know it really just a couple of weeks that you're empowering them to make decisions.
I've had more success framing it that way.
What about you?
Yeah, I think that makes a huge amount of sense.
The fear is loss of control.
So the fear that by empowering the product owner, they might do something which they would regard as a mistake.
And they will often see themselves, because they're in a senior position, as being responsible.
If they are responsible and the products owner makes the decision they don't like, perhaps that will reflect poorly on them.
There's a trust issue here.
A good product owner is going to be consulting their stakeholders anyway, and I would think the senior product leadership team is part of their stake holders.
So you would hope that they were keeping them very, very up to date on their thinking, that there would be no great surprises,
they wouldn't do something, you know, suddenly switch from one product to a completely different product.
They would always be keeping their Stakeholders in the loop.
And in which case they would be building up the trust of the people around them.
And then you would hope that over time that they will become more empowered.
Yeah.
I kind of wonder if that's maybe part of it, that the they have a misunderstanding.
of, uh, kind of how the role works, you know, because maybe they, maybe, they see it as completely independent.
This person is just making decisions on their own without consulting anyone.
Maybe that's because that how they do their job.
So they may, may look at that as, this is, how I would do it.
Why wouldn't this person do at the same way?
Well, that not how it's designed.
Yeah, it was designed to be done in concert.
Yeah, it's a misunderstanding of the product owner role and it is also a misunderstanding of why the Product Owner role came about.
which is the reason it was there was to solve the problem of too many chefs, of two many people trying to make decisions.
So there's huge value in the role, but the value and the roll only comes about if that person can actually take ownership of the product.
I mean, the clues in name, isn't it?
They are the owner of products, therefore they can make the critical on the ground decisions, all the time talking to their stakeholders.
So, I mean, as with many things in Scrum, it's about a misunderstanding, a general misunderstanding of what the roles are within the Scum team.
Yeah.
I think they also have the fear of the wrong decision that somehow that's going to lock them in, or this person's not equipped to make the right decisions.
They are the knowledge expert for the product, and so they should be the one making all the decisions, they have authority.
And I have had a couple of cases where I've had to have difficult conversations with leaders to say, Well, let's examine the decision because you're looking
at them as making the wrong decision, but is it the right decision?
You know, you, your, kind of disconnected from the day-to-day of the team.
This person is fully connected to the data day and they're more likely to have more current knowledge.
And it's, it, not always the case that just because it is the, wrong, decision that it actually is, they may actually be right.
You could be wrong.
And funny enough, this brings on to another topic I'm greatly interested in, which is the definition of value.
And that is, if there is no clear understanding within the organization of a value, then decisions become arbitrary.
We decide to do x rather than y in the product.
Well, why did you decide do that?
Well because it was my decision to that.
Yeah, but is there a rationale behind it?
Do you have a definition to the value of x and the of y and why you chose one over the other?
And I think that's part of the problem as well.
The kinds of organizations that don't have empowered product owners also typically don' have a definition of value.
Yeah, I completely agree.
I know I've had conversations in classes where I talk to people about how when you're prioritizing, when your looking at things in your backlog and we
always say you prioritize according to value, Well, what's the value of doing that thing?
And so many times I think there are organizations that can't really identify what it is.
Why are we doing this thing, because it sounded cool, cause it seemed like the right thing to do.
It just felt right.
No, we're doing it so that it does something, it creates some outcome for us.
And if you can even really define what that outcome is that you're hoping it achieves, Well, isn't that the start of the problem?
And I think part of, the root cause of that as well is the tendency for these types of organizations to do long-term planning.
So what they'll often do is they will have a roadmap for the year and they say, in this roadmap, for a year, we will achieve all these things.
And then it becomes less about delivering value and more about, delivering the roadmap.
And I've had conversations with product owners where I said to them, you do realize what we're doing doesn't make sense.
And they say, yeah, of course they do.
But I'm not being measured on sense or the delivery of value.
I am being measuring on whether or not I meet the roadmap.
Right.
That's what's important to me.
You can see how all these elements are tied together within the organization.
Yeah.
No, that's an excellent point.
And you're absolutely right.
So much of our metrics and some of the things that we judge teams on or performance by is basically just a volume kind of metric.
It's how much stuff is being produced.
That's not value.
Volume does not equal value, value can be achieved with much less a lot of times.
If we're This is why sometimes I'll advise product owners in classes to say, look, start of your sprint review, maybe go back and look at some things that
you've done recently and show the metric that's you're using for that thing to see if it's successful.
Because if I've.
If the team's done something in the past three or four sprints and it actually moved the value needle some way.
is increased customer satisfaction, added new members to our site, whatever the thing is, right?
If you can show that kind of business value to it, my experience is that people stop focusing as much on volume, because that's volumes of means to the end,
which is the value.
Yeah, absolutely.
And the other thing I've noticed as well in these types of organizations is that the value they're focused on is not the incremental delivery.
It's usually a new feature or something like that competing.
What you often find is the teams are not end value creators.
They're often parts of the creation of value.
Rather than the whole creation value, there may be a component of it.
And because of that, people will say, well, there's no direct link between you and value creation in the organization.
I find that is very problematic and it really flies against the rationale of Scrum, which is that you want within each sprint,
you wanna deliver some incremental value.
And if you can't measure it, if can clearly define what that value is.
And as you were saying, If the product owner can stand in the sprint review and say, well, this is, the value we've delivered.
How does the team keep motivated?
How do they, how do, they keep passionate about what they're doing?
Yeah.
Yeah, I think part of that is just trying to put yourselves in the shoes of your customers and try to look about what they would find as being really valuable.
I don't know about you.
Well, sure, this applies to you as well.
But we all are consumers of different software products, whether that's a business software product or even games or other things that we would use.
And when they come out with new releases of those things, they came out With release notes.
Now, when They come up with the release Notes, are you looking at the Release notes and going?
Wow, I'm satisfied.
There's a ton of things that's in this release.
Or are You looking through the individual items and Going?
Well, care about that.
I don't care About that on care.
About this, that thing.
Oh, yeah, That's important to me.
Right.
That's what we do.
And, and that's a clear picture of value over volume.
Yeah.
I mean, I think the thing that gets in the way here is a lot of it is the pride of the management team.
So they often have strong self-belief.
They believe they make, they believe by definition the decisions they're making are powerful decisions.
So it's also, I think, one of the reasons why a lot of organizations aren't data driven.
You would hope they would produce a feature and then measure whether or not that feature was a success, but that's not as common as it should be.
There's very rarely business metrics tracked against deliveries.
I mean, I'm generalizing here.
There are many organizations do this very well, but I found there's quite a few organizations that don't really do that.
And it leads to a disconnect with the customers.
I can think of an example, an organization I was working at where they worked on a feature delivery for six months that was on the roadmap and they got
it done and I think The expected users were tens of thousands and they got 16 users for this feature.
And at that point, there wasn't even a post-mortem.
They didn't look back and say, well, what are the lessons learned here?
It was like, oh, that's a shame.
Let's move on to the next item on the roadmap and hope that works instead.
It's very frustrating, especially because the feel of a good Scrum team is the connection with the customers and the feeling that you can see the passion
in the engineers and in that the team size because they're delivering things that people want and they feel connected to it.
And it means they work better and then work more effectively.
Yeah, there's no worse feeling than building something no one uses.
I used to joke with the team.
It's kind of like that old joke about if a tree falls in the woods, no, one's around as a mix.
If we build software that nobody uses, did we built it?
Yeah.
You know, it just, i-it's, not going to be used for anything.
So it didn't serve any purpose.
Yeah, the way I like to think of it is that an organization should not view people's time spent in the job as important.
What they should view is the value that that person has delivered is important, so sometimes people will say, well, you know,
yeah, okay, we delivered a feature that nobody really used, but you did your job.
You came in for eight hours a day during that time.
And that's hard for people, I think, because they feel like this is my life.
I'm investing time and energy into this.
Yeah, the money is important, of course.
So I am doing it as a career.
But at the same time, i also want to feel reward.
i want feel I can achieving something.
And i think with that element, you get so much better performance from the team if they fill that.
I agree.
There's another thing I was thinking of here too, when we were talking about underpowered POs, another cause I think that,
that maybe you've encountered or seen as well, but screwy things that people do with, with kind of personnel, like for example,
having multiple product owners for a team that leads to under power product owner or, or the opposite, even putting a product on her on too many teams,
and that's going to lead to power PO's as.
Well, what's been your experience with that?
Have you seen that I have one extreme example.
where there was an engineering team and the organisation was international organisation.
politically within the organisation, it was unacceptable to have one backlog.
They had to a backlog for the UK, a back log for US, backlog Australia, backlog for other areas of the world.
And the team then had too prioritise them kind of in this wild order.
So they would say, right, we'll take number one from UK and number from US.
There was no coherence to what they were building at all.
It was really just about satisfying people within the organization.
And it kind of brings you back to that key point about why do we have product owners?
Because product tenders, they narrow down all the ambiguity.
They narrow about down, all of the possibilities to the thing that's most effective for the team to do next.
Yeah, I like it.
I liked your example because it highlights kind of what I think about that.
Those scenarios a lot of times is that they're theater, you know, they are an act.
They're not really serving the purpose, but they, are making someone or helping someone to feel a sense of security about something that really they shouldn't feel.
It's not there, But it has the appearance of it and has, the stage set of something, that looks secure, Yeah.
I mean, whenever somebody mentioned that to me, the first thing I always think about is the length of the backlog.
Yeah, but we're adding 10 new items a week and we are only completing eight.
So in fact, you're moving further down the backlog.
You're not actually getting closer to being done.
And it's, it is a disconnect to gain.
This is what it all about.
Good agility, good scrum is when there's a strong connection.
If you start having that, that just doing things for appearances sake, then you lose that connection Yeah.
And it really is kind of that fundamental flaw that we try to address throughout Scrum of transparency.
When you do those kind theater-ish things to give the appearance of something, it's the opposite of being transparent.
You're trying to make it more difficult to see the reality.
Yeah, It's on the backlog.
So you have this false sense of security.
It is on backlog, but it is never going to get done.
But that's not transparent that it will never get it done because it was on a backlog Part of that I put on the product owner a little bit,
but that could also be that the organization demands it.
Like your example with it having different backlogs across different geographies, does it serve a purpose?
Well, maybe the purpose is to make someone feel better.
Hey, my thing's number one on our list, that doesn't mean it's the next thing that's going to get done.
It was done exactly for that reason.
I mean, it was because they didn't want to alienate the heads of the individual countries.
So they wanted to make them feel like they were going to get something even though they weren't going get it.
Which is really frustrating.
Because there's a, I don't know if there is a fear that someone's going to feel undervalued if they're not called the product owner,
but it just seems like, uh, yeah, we want all these voices to be involved with it, which again, maybe it's the misunderstanding of the Product Owner role.
That's okay.
You can have multiple voices involved.
But you got to define who's the decision maker.
And if a team doesn't know that, that's going to cause a whole host of problems.
Absolutely.
I mean, I've been in scenarios where you would have multiple product owners.
The team has been instructed by a product owner to go in a direction.
Then midway through a sprint, the other product will come along and say, yeah, That's not really what I had in mind for this sprint.
Can you please switch on to this other thing?
And I was a scrum master at the time.
And what I ended up doing in my sprint report was I would say, and the team lost 20 to 30% of their capacity in switching between what one product owner
wanted and what the other product owners wanted.
That at least got a reaction because people said, well, okay, maybe that's not a good thing if we're losing output from the tea.
But it's a failure of the organization to make value judgments and make genuine decisions.
Instead, it becomes political decisions, Well, I'll give you my trick for when I when i've encountered it as a consultant a couple times.
I usually just ask one question and it'll clear it up.
i'll just go to them and whoever the leader is that's insisting that there's multiple product owners on the team.
And usually the immediate thing I hear back is, oh, no, they get along.
They usually understand.
And I always just counteract it really quickly and say, yeah, but what happens when they don't?
What happens?
When the day comes when one of the product owners wants something that's number one, and the other one wants an entirely different thing as the number-one priority,
who makes the call?
And, usually they'll point to one them and push comes to shove that one.
Got a little bit more authority, so they make the decision.
I mean, at that point, I just say, well, you just told me that's your product owner, right?
That's the product on the other person's stakeholder, which is fine.
But there's nothing devaluing about someone who's a stakeholder.
They can work all day, every day with that product.
Yeah, absolutely.
I think that people feel if they're not in the product owner role, then they will just be another stakeholder and maybe they won't have as loud a voice.
But what's so frustrating about the situation is when you see it done well, when we see done effectively with a really good,
empowered product, a very motivated team, it's such a powerful thing.
And I mean, that's why I stayed in Agile for so long is because I know how good it can be.
And it's very frustrating and I guess I have sympathy for organizations because maybe if they've never seen it done well,
it is difficult for them to understand just how effective it it.
Yeah, I agree.
Well, this has been a great discussion.
I really like this topic.
It's great to focus on product owners a little bit and hopefully maybe there's a leader out there or somebody listening who heard some of these things
and thought, you know what, maybe it is time to give our product owner a lot more power.
You know, we talk about testing things all the time, inspecting and adapting as we go.
Leaders, try that.
Yeah.
Maybe just try it as an experiment.
If you're concerned, give it a go, Yeah, give it a shot and see what happens.
You may like it and you may decide this is the best way to go.
So yeah, I think that's a great suggestion.
Well, Barnaby, this has been great.
I really appreciate you making time for this and thanks for not only being on the show, but for the contributions you made in the Agile Mentors community
as well.
Thanks a lot, Brian.

3 Ways to Help a Busy Product Owner

Transcript

Being a product owner is a tough job.
Product owners often carry a heavy burden because they have to get a succession of decisions exactly right.
And they usually need to do this while being extremely busy.
Everyone seems to need some of the product owners' time.
Fortunately, there are things a good scrum master can do to support an overly busy product owner.
And in this video, I'm going to share three of them with you.
Hi, i'm Mike Cohn.
I am the author of three best-selling books on Agile and Scrum.
One of the most useful ways a Scrum Master can help a product owner is by helping them make time for important work that could get pushed aside by the
day-to-day emergencies of work.
For example, suppose your productowner needs to write acceptance criteria for the user stories for their next sprint.
They hope to get it done on Monday.
Doesn't happen.
The hope you get done it on Tuesday.
It doesn't happened.
Wednesday, same thing.
This happens because items on a to-do list are promises to ourselves.
And we don't treat those promises as well as we treat promises to others.
Today, I had two meetings and seven things on my to-do list, such as making this video.
I made all the meetings because I didn't want to let others down.
But four items remain unstarted on My To-Do List.
If your product owner is struggling to fit certain work into their week, offer to schedule a time to meet with them to help do it.
Agree that tomorrow at 2 p.m., the two of you will meet to write the acceptance criteria for next Sprint's stories.
The product will almost certainly make time for that shared activity, whereas they probably wouldn't fit it in if it were just an item on their own personal
to-do list.
Another way you can help a Harried Product Owner is to convince team members that they can answer some questions for themselves.
Some team member fall into a trap of thinking that their Product owner needs to specify every last detail about every product backlog item.
It's not true.
Product owners need to specific the things about a backlog items that are so important that the item will be rejected without those things.
But there are many smaller details about how something is implemented that can best be decided by the team.
For example, imagine a system with a screen that could be sorted by various columns.
Now, the columns can be sort in ascending or descending order.
Which column and which order should be the default?
If the product owner has a strong preference, the Product Owner can absolutely state that preference and the team will need to sort in that order on that column.
But lacking a Strong Preference, a decision by the Team is likely to be just as good as one from the Project Owner.
As Scrum Master, help your team understand this.
And where the product owner has not already stated a strong opinion, encourage team members to make a decision.
They'll probably make the right decision, if not, the Product Owner can redirect the team as soon as they next see the products.
Sure, the team will occasionally have to backtrack and redo some work, but that will probably not be much, probably won't happen often,
and needs to be balanced against all the time saved by not having to discuss every small issue like that in advance.
A third way you can help your product owner is by being on the lookout for best practices.
You are more likely to be attuned to advances in how products are developed.
For example, as Scrum Master, you might have heard about story mapping or job stories shortly after each was introduced.
It could easily be years before such innovations come to the attention of a product donor.
Keep your eyes open for advances in product development, agile, and so on.
And bring time savers to the attention of your product owner.
What do you do to help a busy product donor?
Are there things you've done to your project owner manage all they're expected to do?
Please let me know in the comments.
I read and value each comment.
And if this video has been useful, click the Like button.
If you haven't already, Click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching and I'll see you next time.

3 Ways to Get Your Product Owner Engaged During Sprints

Transcript

A big deal is made in the agile world of the phrase inspect and adapt, and that's as it should be.
Inspect and adopt are both important words, but they belong together.
There's no point inspecting if you don't go on to use what you learn to adapt.
And adapting without first inspect results in arbitrary changes.
Unfortunately, some product donors don' take advantages of all the opportunities they're given to inspect.
These product owners often disengage during sprints.
They might show up for a planning meeting and probably for the sprint review, but throughout the Sprint, they're as elusive as Bigfoot.
I've got some tips that will help you if your product owner is not engaged for peak agility.
Hi, I'm Mike Cohn, the author of three bestselling books on Agile and Scrum.
And today I want to help YOU and your Product Owner.
The first thing I suggest is speaking with your product owner about the importance of staying engaged throughout the sprint.
Point out that the team will benefit from feedback as they develop, that team members will have questions that need timely answers,
and that working together is the best way to ensure success.
Also note that I said to speak with your product owner about this.
Email and chat software are great.
They have their purposes.
But I think you'll be more persuasive if you actually speak to the product.
If you can't persuade the Product Owner to become more engaged throughout each sprint, here's an easy next thing to try.
Tell the Project Owner that they will be responsible for running the demo during the review.
I prefer to have various team members run the keyboard to show the new features each worked on.
But when faced with a disengaged Product Owner, I tell the Product owner to be the one with their hands on the Keyboard.
I sometimes go so far as to imply it's a Scrum rule that they give the demo.
It's not, of course.
But I've learned that if they know they'll have to demo the product at the review, they don't disengage as fully during the sprint.
They don' want to embarrass themselves, so they stay more in touch with the work and the team members during this sprint Product donors often disengaged
during sprints because they're busy.
If that busyness is self-made, we can sometimes help by showing the product owner how to be more effective or how delegate parts of the job.
But in other cases, the busy is real and cannot be removed.
If this is the case and your product is too busy to do the work, you may need a different product.
You probably won't be successful at making this change if you go to the product owner's boss and tell them you need someone different.
But you can often succeed in getting a new product donor if your convince the current product to support the idea.
I do that by telling the Product Owner that they're too busy for the job.
They'll nod along as I point out the obvious.
I then tell them that they should instead be the key stakeholder.
I tell him the Key Stakeholder is the person that the whole team, developers, Scrum Master, and product owner are focused on making happy.
The Key stakeholder has the right to get mad if the team doesn't build the features.
I often make it sound like this is an official Scrum or Agile role.
It's not, but you know what?
Maybe it should be.
When I tell the overly busy, disappearing product owner that they may instead be the key stakeholder, the idea almost always immediately resonates.
They see that they can delegate the product owner responsibilities to someone else, yet retain the right to insist the products contain certain features.
This is often enough to encourage them to delegate their job to somebody else or to support the organization in an effort to find someone.
And of course, we should be looking for someone who has time to fully be the Product Owner without disengaging during the sprint.
Have you worked with a product owner who is less engaged than you would like?
What did you do to correct this situation?
Please share your thoughts in the comments.
I read and value every comment.
If this video has been useful, click the Like button.
And if you're new to the channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching and I'll see you next time.

What Are Product Goals & When Do Product Owners Create Them?

Transcript

On a recent Agile Mentors podcast, I turned the tables on host Brian Milner and interviewed him about a resource he created for our community called the
definitive guide to the what and when of product owner responsibilities.
The link to download the free PDF guide should be appearing just above my head as I speak, and it's also in the description.
In this video, I want to give you a sneak peek into that interview.
We'll start at the moment when I asked Brian to tell me more about one of the activities he recommends product owners do about every quarter,
Create a Product Goal.
I want to talk about your quarterly items on here.
And you've got a couple, let me just kind of read some of these here, so you got establish a product goal.
That's a relatively new thing in Scrum.
I mean, I still think of 2020 as relatively knew, but as a old timer with Scum, product goals is one of the newer enhancements.
You've got doing the story writing workshop, so you're supporting what you said there.
Talk to me about the product goal here.
Yeah.
So I feel silly talking to Mike Cohen about what a product is.
Product goals are just that, they're a milestone, right?
And that's typically the way I talk about this in class is to say, especially when you're starting something new, you may not know everything that you
are going to do, but you know the next big thing that need to accomplish.
You know, the big mile marker that your going hit in the life of your product.
And that's what we want to establish with a product goal.
Something's going to take longer than a sprint, multiple sprints to do.
I've got this in the quarterly section, and that kind of how we tend to talk about it a lot here at Mountain Goat.
But even in class, we'll even say quarterly-ish, you know?
It's the bigger than the sprint section.
Right.
Bigger than sprint.
And sometimes it'll be longer.
Sometimes it will be shorter.
That's okay.
You just want to have that big thing that the team can keep their eyes on and kind of know, you know.
Here's, You got a sprint goal that tells us why what we're doing in this sprint is important and how my small task feeds into that.
And you've got this product goal to say, how does the sprints work?
fit into this bigger picture of what we're trying to do.
So you're making those connections consciously for the developers so that they are not just, hey, here's a laundry list of stuff to,
but here is the objective we are trying accomplish.
Yep.
I think it's important to have something that's out there bigger than a sprint.
A sprint is just, it just kind of sub-optimizing, right?
I'm thinking about if you're climbing a mountain and a sprints is like, what's the highest thing I see?
And just always walk into the thing you see.
Meanwhile, those are all false summits.
The real summit is, you know, behind some valley, but you don't see it because you set out that bigger goal.
And I like how you talked about it quarterly because if the goal's too big, if it is too far out, there, we're not going to feel very motivated.
about it.
I had this, the wackest example of this.
Hope the guy's not listening.
Actually, I hope he is.
But he told me he was on a project with the large particle collider.
And he said his whole project won't be due for 40 years.
I mean, I don't get it, but it's like they've got to run like 40 years worth of data before it is like totally done.
And I just picture myself showing up for work on a 40-year project, right?
I know you, you're going to be reading Dallas Cowboys news for the first 35 years, sports news.
That's a forty- year project too.
You're not going to take it serious for 35 years.
Then you're going wake up and go, oh, the deadline's only five years away.
I better get to work on this.
And then what I would do is realize, wow, I'll be retired after 40. Right.
Exactly.
So anyway, I've been silly, but I mean, you're on a project with a 40-year deadline.
How do you say motivated, right?
And I think three months is a really good time where I can see a bigger impact than a sprint.
But it's not so far that that student syndrome kicks in, and I feel, oh, don't really have to worry about it.
Let's go to a long lunch.
We'll get to work on it tomorrow, so I do like the quarter-ish approach there.
We greatly exaggerated a project length to make a point, and I can never resist a dig at Brian's favorite Dallas Cowboys team.
But I do want you to notice that I said quarterish.
I call this level of planning milestone planning versus other terms like release or quarterly planning.
And I talk about all of that and more in my Agile Planning Layers video if you'd like to know more.
In the meantime, I'm curious, how do you handle product goals?
Do you set them?
do find them useful?
Are they something you do regularly?
Let me know in the comments.

5 Key Factors for Effective Product Backlog Prioritization

Transcript

Not only do you need to build the right features, you have to build them in the right order. I want to share five key factors you should consider when prioritizing a product backlog. Let's start with a biggie: value. And while it's a given to consider how valuable a feature will be, value is a nebulous term. Most work a team will pursue will be valuable to users, but other work may be valuable just to the team. Still other work may be valuable to both users and team members. For example, consider refactoring: improving the structure but not the behavior of code. Because this makes code more maintainable or easier to change, refactoring is valuable to developers. Still, the cost of refactoring is usually justified by the way it benefits users too. If code is more maintainable, users should experience fewer bugs. Similarly, improved code means that users should receive new features in that area of the product a bit more quickly. The second factor to consider when prioritizing is the cost. The largest cost is usually the team's effort to develop a feature. Most teams estimate the effort product backlog items take in story points, but some estimate in person-days, ideal time, or other similar units. In some cases, there may be additional costs that should be considered. A current common consideration: the ongoing cost of delivering features that rely on various artificial intelligence products. These products often include small per-use fees, but those fees can certainly add up at scale. Regardless of the unit in which a team estimates their product backlog items, that cost to develop and support a feature should factor into an item's priority. For example, an item that a team estimates as five should be prioritized higher than a feature estimated at 20 if all else is equal. This is true whether these are story points, person-days, person-hours, ideal time, or any other unit. A third factor to consider when prioritizing is this: the amount of learning that will occur when the team develops the product backlog item. If you'll learn something important by developing a backlog item, develop that item early so that you have time to act on whatever you've learned. Learn something too late, and you won't have time to benefit from the new knowledge. Learning can take two forms. It can be about the product or the project. Learning about the product occurs when the team develops a feature and receives feedback on it. If users love the feature, do more of it and more things like it. If users don't love it, consider removing the feature or lowering the priority of related features. Learning about the project refers to knowledge team members gain about how to develop the product or solution. For example, suppose a team intends to build part of a product using a technology that team members have never used before. When team members develop the first product backlog item using that new technology, they will learn things about it, such as: Does the technology work as promised? Should estimates for using the new tech be revised? And can the technology be used in other parts of the product or project? The fourth factor to consider when prioritizing is the risk inherent in developing the product backlog item. If something is risky and you need to do it, do it early. You want to know whether that risk is going to materialize. On the other hand, if a feature is risky and you may not need to develop it, delay working on it until it becomes clear you need to do it. The final factor you should consider when prioritizing is dependencies between product backlog items. Some items may not be high priority on their own, but they're necessary for delivering other items. When that's the case, the enabling but lower-priority item needs to be moved higher on the backlog in order to be done before the item dependent on it. As an example, consider a summer camp I helped use Scrum. Among their product backlog items was repainting all the canoes. That was high priority because they wanted to show photos of the shiny, newly painted canoes in their marketing. But painting the canoes was dependent on another backlog item: sand and repair any canoes that needed it. Technically, repairing the canoes didn't need to be done until a day or two before the summer camp opened, but that item was prioritized higher in the product backlog because the marketing photos of the canoes needed to be taken long before that. While all five factors are important, I don't recommend combining them through some fancy formula. The value of a feature and its cost, our first and second factors, are the most important. I recommend continuing to prioritize based on these, but then using the other three factors to adjust priorities. For example, suppose a product owner or product manager has prioritized an item such that it won't be done for another three or four iterations based on its value and cost. At that point, consider learning, risk, and dependencies. Move the item up an iteration or two if any of those factors is significant. Additionally, there are many ways to prioritize product backlogs, including formal prioritization frameworks such as Kano analysis, RICE scoring, and relative weighting. Even with those formal methods, keep the five factors I've mentioned here in mind, even when they're not explicitly part of those frameworks.

The Product Owner's Dilemma — Where's the Line Between What and How?

Transcript

In its role definition, Scrum establishes the classic product management distinction between what and how.
The product owner says what to build and the developers decide how to built it.
As important as it is to separate what to build from how to built it, there is often a very fine line between what and how.
Let me give you a really simple example.
Suppose a product owner tells the developers that users need to be able to reset their passwords.
That is what is needed.
The productowner has left it entirely up to the developer how do that.
Now, suppose instead that the product owner tells the developers that users need to be able to reset their passwords by answering a security question.
The productowner has just dipped down into the how.
In doing so, the Product Owner has shrunk the solution space.
There are now fewer ways in which the Developers can achieve the Project Owner's goal of enabling users to Reset their Passwords.
It can be okay for a product owner to dip down into the how.
If how a solution works is vital to whether a project owner will consider the solution acceptable, then the productowner needs to specify that.
So if it's critical in this mythical product that passwords are reset by answering a security question rather than in some other way,
than the projectowner is allowed to say so.

How to Talk to Stakeholders (6 Guidelines for Saying No to Stakeholders)

Transcript

Saying no to a stakeholder can be very difficult.
Most of us like to please others, and when we say no, we know we're disappointing someone.
But saying no the stakeholders is an important part of the product owner or product manager's job.
They're tasked with optimizing the value delivered by a product, not with saying yes to every customer request.
For every time a product owner says yes to one stakeholder's request, the product will need to say no to some future request.
A team's time is limited, and a yes today will necessitate saying no some later opportunity.
This means that learning to Say No to Stakeholders is a skill every product needs to master.
I want to share six guidelines for how you can do so politely but firmly.
When you need to tell a stakeholder no, be clear what no means.
If you're saying that you'll never have the team work on this feature, don't leave the door open to encourage the stakeholder to ask again later.
That's a waste of their time and frustrating for you to have to continually say no when you know you will never do that feature.
If, on the other hand, you're telling the customer no for now, that you might work on their request later, be clear about that as well.
Tell the stakeholder why you can't work their requests now and when you'll reconsider it.
I also like to ask them to remind me about the request at that time.
This is a simple way of confirming the requests is still important.
If the stakeholder isn't willing to do something as minor as remind me later, whatever they want probably isn' t that important.
Most importantly, don't let the stakeholders leave the conversation they should ask again in a month if your answer was really that you never intend to
what they've requested.
When you have to say no, express both appreciation and empathy.
To do this sincerely, take time to understand the request, both what the stakeholder wants, but also why it's important to them.
The feature may be required to fulfill goals assigned to it by their boss.
It might even be tied to a bonus or other incentive.
To express appreciation and empathy, say something like, I appreciate you thinking of how our product could be better, and I can see why this feature is
important to you in achieving.
And then in your own words, restate what they told you about why the feature important.
Be sure you're sincere about this.
False empathy is obvious and frustrating.
When saying no, it's best for product owners to provide one compelling reason rather than a list of reasons.
When offered a List of Reasons, people tend to pick the weakest reason and argue against it.
For example, I heard a product owner tell a stakeholder that she was unwilling to interrupt the current iteration to work on the stakeholder's latest request
for four reasons.
It would interrupt a team's momentum.
The team would need to re-plan the iteration.
She wasn't sure the new work would fit, and she wasn' t yet convinced the request was truly a higher priority.
The only one of these that mattered was the last.
That she was not convinced the new thing was a higher priority.
None of the other reasons matter.
But when the stakeholder heard the four reasons, she argued against the need to re-plan the iteration.
When saying no, be firm and offer your one most compelling reason.
If you and the stakeholder you're telling no to share the same overarching goal, remind them of this.
A product owner and stakeholders often have many different goals.
And yes, sometimes they're in conflict, but usually there is a higher product level goal that is shared that you can reference.
While working on a SaaS product, I saw the product owner handle this very well.
He and the team were working diligently toward a goal of decreasing subscriber churn by 10%. When asked to work on something he considered a distraction
from that, he reminded the stakeholder of their shared overarching goal, of reducing chern.
This helped the stakeholders understand why his request wouldn't be worked on in the short term.
When rejecting a stakeholder request, product owners should explain the consequences of saying yes.
This can help the stakeholders see why you feel compelled to say no.
If working on the stakeholder's request will affect the team's ability to achieve another goal, say so.
Explaining the consequence will help this stakeholder understand and hopefully empathize with why your saying no Instead of outright saying no to a customer,
a product owner may be able to offer an alternative.
While there may not be time to do everything a stakeholder is asking for, would it be possible to just do a portion of it?
Or ask the stakeholder if it would be acceptable to start on the request in three weeks.
Be careful though, only offer alternative if you really mean it.
Product owners often fear saying no and disappointing their stakeholders or customers.
But saying, no doesn't have to be so difficult.
I've found that being clear, providing one reason rather than many, being empathetic and appreciative, conveying that we share the same ultimate goal,
Explaining the consequences of saying yes and offering an alternative makes saying no much easier.
When done well, saying No can improve rather than harm a product owner's relationship with their stakeholders.

Double Duty as Product Owner and Scrum Master: Why It's a Bad Idea

Transcript

At some point, you've probably wondered if you might be able to be both a team's product owner and its scrum master.
Banish that thought.
To see why, let's look back in history at the job of being a pirate ship captain.
A Stanford professor studied this by having his MBA students design the jobs of a 17th century pirate captain ship.
They designed a job that lumped together two areas of responsibility.
The first type of tasks are known as star tasks.
These are the strategic work of deciding which ships to attack, commanding the crew during battle, negotiating with the other captains,
and so on.
The second type tasks, are know as guardian tasks These the operational work distributing the pirate booty, settling conflict,
punishing crew members, organizing care for the wounded.
The problem with this job description is that it mixes star and guardian tasks.
There are very few individuals who excel at both types of task.
Star tasks require risk taking and entrepreneurship, whereas guardian task require conscientiousness and consistency.
A pirate captain good at identifying ships to attack and at leading his crew into battle would likely be bored by the administrative minutiae of the Guardian tasks.
To make matters worse, people tend to spend most of their time doing what they're good and what enjoy.
This means it is even harder to succeed when mixing roles that require different skills.
Pirates solve the problem by having two leaders on each ship, a captain responsible for the star tasks and a quarter master general responsible the guardian tasks.
Scrum teams should do the same.
Have a product owner perform the Star Tasks of establishing a vision for a project, defining the best outcomes the product can create for its users,
and defining features that will get it there.
but also have a scrum master to perform the guardian tasks, those tasks that protect a team from distractions and that improve collaboration and focus.
I have, of course, seen teams with one person as both scrumm master and product owner.
Each has been an exceptional person, perhaps the blackbeards of Scrum.
However, in each case, my reaction was to think how much better that person could have done their job if enabled to work in only one of the two roles.
I think something is lost when doing both roles, remember most people don't excel at both star and guardian tasks.
So can you fill both role?
Perhaps, but consider what you might lose when both doing roles?

Scrum Foundations

As an agile framework, Scrum is deceptively simple. Yet those who implement it successfully know that simple doesn’t always mean easy. To help you on your agile journey, I have created an introductory Scrum Foundations video course. This series of short videos introduces you to the terminology and concepts associated with Scrum--from Scrum as a framework to sprint planning to potentially releasable product increments.

Why Scrum Won't Tell You How to Work

Transcript

Hi, I'm Mike Cohn. Welcome to Scrum Foundations. One of the first things you need to understand about Scum is that we tend to think of it as a framework rather than a methodology or process. What's the difference? A methodology of process is much more complete. A Methodology or Process will specify essentially everything about how work should be performed when using that approach. For example, a methodology might specify exactly how testing and quality assurance should be performed. Or it might specifiy how a team should go about gathering requirements for a new product. A framework, on the other hand, is purposefully incomplete. Scrum, for example, has an artifact called the Product Backlog, which is essentially a prioritized requirements list. Scrum is absolutely silent on how the product backlog comes into existence. It could be delivered to the team by little green men on a spaceship, as far as Scum Similarly, Scrum says a team needs to produce high-quality work, but doesn't say how the team is to achieve that. Things like these are left to the Team because a Team owning its own process is a critical success factor for Scum. A Team is going to be much more bought into a way of working if they contribute to determining that way working. So, Scrum is a deliberately incomplete framework to which each team adds whatever is necessary given that team's context. Scum takes the position that the team knows best how it should work and provides tremendous flexibility for teams to choose what needs to be added to make the Sc rum framework into an appropriate methodology for that teams work. I want to caution you, however, about removing things from a scrum. As a framework, scrums are very small, but the things that are there have been shown to work over and over again. Be very careful about deciding to remove something, especially before you have sufficient experience to make very educated guesses about how removing something from scrumb would affect the other parts of scrumm. In a nutshell, Scrum is a series of events that happen over a defined period of time called a sprint. Those events are repeated every sprint If Scum is so simple, why is it so difficult to implement? Because it's fundamentally different than how most of us are used to working. It's a change. And change is hard.

Empirical vs Defined Process

Transcript

There are two types of processes in the world, defined and empirical. In a defined process, someone can write down all of the steps to achieve some output, and then the process can be executed repeatedly to the achieve the exact same goal. When I was 16, I worked at a fast food hamburger restaurant. I only worked there for a few months before upgrading my job to a fast food burrito restaurant. But I can still perfectly remember everything I was taught about making burgers there. Our burgers were cooked on a conveyor belt that moved the burgers through a flame broiler. For each burger ordered, I put the meat patties three inches into the conveyer belt. If someone asked for the burger well done, i put to pattys at the start of the conveyer belt Every burger got two leaves of lettuce, two slices of tomato, three pickles, and three onion slices. No more, no less. If a customer asked for extra onion, I was instructed to add five onion slice, not three. White onions meant one slice. This well-defined process allowed the restaurant to take anyone, including pimple-faced teenagers like me, and turn us into chefs. Well, not exactly chefs, but my burgers came out of that flame broiler and tasted just as good as those from a cook who'd been there 10 years. This is the epitome of a defined process. All of the inputs and each of steps can be defined up front, and the process can be executed by anyone with appropriate skill, and they will achieve the exact same output. A defined process is good for something repeatable, like making burgers. But some things are much more complex. That's where an empirical process comes into play. An empirical is built on the idea of inspecting and adapting. We look at how something is going and make changes. As an example, I was on a plane recently and we encountered some pretty nasty weather. Rather than sticking to some predefined flight plan, our pilot inspected and adapted. He flew a little more south than the normal route for that flight, and he announced that he was moving to a higher altitude. By making these adjustments, our pilot got us to the destination and did it in a way that was safer and more comfortable for everyone. My father-in-law was a pilot for one of the big airlines. He used to tell me that for a two-hour flight, an hour and 50 minutes of that flight his job was no more difficult than being a bus driver. But his 40 years of flying experience were extremely helpful during the other 10 minutes. During that time, he needed to inspect and adapt. What type of process is better for software development or product development in general? an empirical one. No one can write down all of the steps to build a product, give those steps the various teams, and expect to get the exact same results. At a high level, I can say the step to software development are analysis, design, coding, testing. If I give that guidance to 10 teams and ask each team to build me a word processor, there is no chance I'm getting the exact same word processer from each of the teams. Each might give me word processors, but each will be different. This is true even if I wrote much more detailed guidance than do analysis, design, coding, and testing. I could write hundreds of pages of procedures on doing each of those. i'd still get 10 different word processors from those 10 teams. This because product development of any sort is too complex for a defined process. When an endeavor is complex, a more appropriate strategy is to use an empirical process, I've already mentioned two pillars of an empirical process, opportunities to inspect and adapt. A third pillar is transparency. a team needs visibility into its way of working in order to make adjustments. Scrum is all about transparency, which is really the glue that holds it all together. We want to show our work early and often and be transparent in what we're doing, even if it isn't perfect. Doing so allows us to inspect and adapt.

Three Core Elements You Need to Start Using Scrum*

Transcript

In this video, you'll learn the three core elements you need in order to start Scrum in your company. First, strive to create a working product every sprint. Working product doesn't mean the finished product. It doesn' necessarily even mean something you want to release to customers. Rather, a work product is some usually small part of your product that is done. On a software product, done means that design, coding, and testing are all complete. Hold on a second before you tell me this is impossible and that many of the features you build are too big to fit within a few weeks sprint. Remember I said we don't need to be creating the finished product each sprint? I get it. In many cases, that is possible. The goal is to create a working product and then add functionality incrementally each Sprint. Let me give you an example. Suppose you're building a word processor and it doesn't yet support tables. In the first sprint, you add very basic support for tables. And I mean very, basic. All tables must be two rows by two columns. Columns cannot be resized. You can't add headers or footers. you can add shading to cells. Can't change border styles. This is pretty basic, so basic you would never ship it that way. Very few of your users need only 2 by 2 tables without headers, or shading, and that use the default border style. But this is, sure, a nice step forward. It's a working product, even if not one that is worth shipping yet. And if you keep building the product in this manner, eventually you have enough to give sellers show to users. And you often get there well before you've added everything. This allows the team and its product owner to get early feedback on what they're building. That early feed back can be used to guide future decisions about what functionality to add and when. Second, inspect and adapt continually. Scrum is about continuous improvement. Therefore, Sc rum teams inspect an adapt both their product and their process every day. By inspecting and adapting the product, I mean the Scum team, the developers, and the Product Owner are constantly assessing whether they are building the right features. Returning to the word processor example, say the team has a plan in mind for how they'll add support for tables. They give a quick demo of the planned functionality to a few stakeholders, and the stakeholders don't like the user interface. The team and product owner would consider that feedback and quite possibly make a change to how the support tables By inspecting and adapting the process, I mean the team is routinely assessing how they are working together and especially their use of Scrum. Let's suppose the Team is struggling to produce high-quality code within a sprint. To improve, they may decide to start pair programming or taking automated testing more seriously. When I say a team should inspect and adapt their product and their process daily, I don't want to imply that there is no continuity in what the team is building or how team members work together from day to day. Often an opportunity to improve will not be put in place until the next sprint. That's fine. But team members should have their eyes open to opportunities to improve the product or process at all times, even if every improvement is not immediately put in place. Third, trust the team. Trusting the teams is key to succeeding with Scrum. A Scrim team is built on the idea of self-organization. This doesn't mean that a Screm team works without boundaries. There are confines that the a team must work within. However, a scrum team should be trusted with making a lot of the day-to-day decisions on how they will work. Many teams form working agreements. The team collectively decides on things like, what are our overlapping office hours with a distributed team? Do we want remote team members to participate by video? When can the team work from home? Creating a culture of trust is vital to success with Scrum. Scum itself is easy, but to be successful requires the entire organization to to disciplined and dedicated to learning a new way to work.

The Five Values of Scrum

Transcript

One way I can tell if a Scrum team is really a scrum team, is if they live up to the five values of Sc rum. The Scum framework is easy to learn, but living by the values day in and day out often requires changing a lot of ways that we've always worked. During this lesson, we'll go over the Five Values of Scrum, and I'll give you some practical tips for implementing them into your organization. The five values of Scrum are focus, openness, respect, courage, and commitment. I always find that using an acronym is an easy way to remember things. The acronym, FORCC, force, can help you remember the five value of scrum. Of course, you don't want to force your team into learning these values, but thinking about them as a powerful force in your scrumb practice may be a good way keep them top of mind. May the force be with you. Let's begin with our first Scrum value, focus. It's important to stay focused on the product and the value you are trying to deliver. One way to do that is by eliminating or reducing competing priorities. If we have too many competing priority, we start a lot of things, but never finish anything. And if we never finished anything, We don't deliver any value to our customers. One afternoon, my goal was to write the scripts for these videos. I set aside four hours of writing time from 1pm to 5pm. My goal, after all, was focus and produce something of value. At 103, I checked my email. I didn't want to delay my responses to clients, so I replied to four emails. That took until 113. Then I went back to writing my next script. At 120, my wife texted me about, what should we have for dinner tonight? I spent five minutes thinking about it and another minute replying, let's go out for Mexican food. And I spend the next six minutes on Google trying to find a good Mexican restaurant we hadn't been to before. In just the first hour, I spent 21 minutes on activities that had nothing to do with the goal I was working toward. The teams that get the greatest benefit from Scrum are the ones that can minimize distractions and maximize focus. Having a good Scrim master on your team is vital in helping the team focus on its work and maximizing value. The second scrum value is openness. Be open to new ideas and to ideas of others. Don't just settle for how things have always been done. A truly agile team displays innovative thinking. A helpful tip for openness and encouraging innovative thinking on your team is to use the phrase, yes and, when you're discussing a new idea. By changing your language from the typical yes but reply to yes, and you encourage team members to share new ideas. and remove the fear that their ideas will be shut down. So next time you're working with your team and want to encourage the Scrum value of openness, teach them the yes and technique. The third value in Scrum is respect. A good Scum team respects each other's ideas and opinions. Without respect, team members close down. They lose openness. And without openness, the team plays it safe and fails to innovate. Just like in a family, good scum teams disagree and argue. But when they disagree, they argue respectfully. Remember I mentioned looking for a new Mexican restaurant to try? What I didn't tell you earlier is that my wife and I have different criteria in choosing Mexican restaurants. I live for fajitas, so food is my number one concern. For my life, it's all about the guacamole. Well, and the tequila selection. So even though we disagree on what makes a great Mexican Restaurant, we do so respectfully. As a member on a Scrum team, make sure you are respectful to your teammates, even when you disagree with them. The fourth value in Scrum is courage. Some of the most successful companies today got there by having the courage to look at things from a new perspective and by not being afraid of failure. Netflix reinvented the way we watch movies, first by mailing DVDs and then with streaming, while Blockbuster continued with its retail model. Amazon was not the first company to sell books on wine, but they saw it would be the future. Borders and Barnes & Noble were bigger at the time when Amazon started out, But they did not have the courage to jeopardize their brick and mortar models. Scrum teams need the encourage to step out of the way they have always worked and to innovate. Scrum Masters and product owners need to foster courage. By allowing teams to fail and learn from their mistakes, we can give them the courage that they need improve. The fifth value in Scrum is commitment. The team makes commitments to each other. Everyone on the team is accountable for the commitments they've made. I'm going to emphasize the words each-other here. In traditional project management, commitments were made to the project manager, the department manager or the business owner, or someone else with a higher rank. The commitments were individually made. Hey, Johnny, I need that TPS report done tomorrow. And Johnny would say, yes, boss. I'm on it. In Scrum, the team decides what they will work on, and then each person commits to the rest of the Team that they'll do what the've said. Now that you've learned the five values of Scum, print our poster showing the values and hang it near your workspace. By not only knowing but living the Five Values of Scrum you're on your way to becoming an outstanding team.

The Product Owner, SM, and Developers

Transcript

Let's talk about who does what on a Scrum project. On a scrum project, work is split between a scrum master, a product owner, and a group of developers. Each of these is given a set of accountabilities, which is what I'll cover in this video. If you're worried that you don't see your job title here, don' panic. While Scrum only defines three sets of accountabilities, many job functions still exist in organizations practicing Sc rum. It's up to each organization to determine how its job titles map to Scum's set of accountability. Let's start by looking at the Product Owner. The Product owner is responsible for delivering a product that customers value. Maybe value isn't a strong enough word. Maybe product owners should create products that captivate users, delight them, thrill them or that they lust after. Okay, maybe lust is a bit too strong, but you get the idea. Without a product owner, developers build stuff that's really cool to them. And building really, cool stuff is fun. When I was a developer, I loved building cool things. But some of the cool stuff I built never got used by customers, which was less cool. So the product owner's goal is to maximize the value delivered to customers. To do that, a good product must do two things. Ask the developers to build the right features. ask for them in the right order. To determine their right features and the optimal order, a good product owner needs to understand users, customers, competitors, trends in industry, and much more. As such, most product owners will meet regularly with customers and stakeholders to show them progress and learn what they want next. It's important for there to be only one product owner. A product is the single voice of authority on what the developers should build. The product needs to listen to stakeholders, customers, and users. But ultimately, what gets worked on and in what order is up to the product. The product owner's job is made difficult by the need to face in two directions at once. The Product Owner needs to look outward at stakeholders, users, and customers to understand what is needed in the product. But the Product owner must also look inward at the developers to explain those needs so the developer can build them. Best Product Owners work closely with their developers, usually being available daily to clarify issues and answer questions. Speaking of the developers, their job on a Scrum project is easy to define because it's so big. They work collaboratively to build the product. they do whatever is necessary to accomplish that. On a software project, developers would likely include programmers, testers, user experience designers, database engineers, business or system analysts, and many more. The term developers sounds software-centric, And that is the origin of the term. But in Scrum, a developer is anyone collaborating to develop the solution requested by the product owner. On a marketing Scrum project, developers could mean a copywriter and a graphic designer. The developers are responsible for estimating their own work because they know the most about how they'll go about that work. Scum does not prescribe how the estimate. The developers can use story points, days, hours, or whatever method they prefer, as long as those doing the work are the ones estimating the word. The best Scrum teams I've worked with share one very noticeable trait, a feeling of everyone being in it together. There's no us versus them mindset, this happens too frequently on traditionally managed projects. The best Scrum teams don't devolve into finger-pointing and blaming with statements like, that wasn't in the specification, or, I would have built it that way if you'd told me, but I built exactly what you asked for. I've been fortunate enough to work with several hundred Scum teams over the years. And I can always pick out an awesome Sc rum team immediately. When I see an Awesome Sc Rum team, they have a few things in common. First, they work really well together and are focused on the same goal. When one person gets behind, someone else immediately jumps in to help. Second, the have a lot of pride in their work and continually want to improve how they worked together to get even better. Third, there's healthy conflict. Since team members trust and respect one another, They aren't afraid to debate. While this may appear like fighting to an outsider, it's a sign of a good Scrum team. It's like being in a family. Its easier to disagree with your wife or kids because you know that at the end of the day, you're all still in it together. That brings us to the Scrum Master. The Sc rum Master plays a vital role in creating the all for one and one for all attitude and sense of team unity. But that's just one thing a Scum Master does. the scrum master is also accountable for ensuring the developers are able to be their most productive, facilitating meetings and difficult conversations and helping the Developers and the organization learn how to work in a new agile manner. One thing a Scrum Master can do to help the developers be the best they can be is to remove any impediment to their progress. I hear some people refer to these as blockers. I never use that term. Here's why. When I'm a Scrum Master, I don't want to remove only the things blocking the developer's progress. That includes anything that slows them down or hampers them, not just things that are absolutely blocking progress, The Scrum Master should be neutral and objective. This makes them an ideal person to facilitate, especially when difficult conversations need to take place. That doesn't mean that a Scum Master must lead every meeting, though. In fact, doing that often leads the developers to look to the Sc Rum Master to solve every issue rather than produce a solution on their own. A good Scrum Master facilitates when necessary. When a team is first learning Sc rum, the Scum Master will do this more actively, actually running the first few of each type of meeting. Over time though, the Scrum Master can shift to a more passive type of facilitation, there when needed, but not orchestrating every meeting. The Scum Master serves as a change agent to the team and to their broader organization. Therefore, The Scrum master really needs to have a deep understanding of Agile and Scrumb and be able to identify where an organization can improve. To help a scrum team achieve its goals, the Scrum Master keeps the team focused on the sprint goal and removes distractions. Early in a new team's adoption of Scum, The Scrum Master will also need to teach other team members about Sc rum. This will include the importance of time boxing, both the meetings and the overall sprint itself. The sprint cycle creates a rhythm for the Team, which helps the teams meet the goals of the Sprint. A good scrum master also helps members of the scrumb team improve. Sometimes, this means helping the developers replace old ways of working. Other times, it may be teaching something new, like estimating with planning poker. So there you have it, the three sets of accountabilities that make up a scrumm team, The Product Owner, Scrum Master, and The Developers.

How A Scrum Team Differs

Transcript

In this lesson, I want to address two ways in which Scrum teams differ from teams on traditionally managed projects. First, Scum teams are cross-functional. Second, scrum team are self-managing. In a traditionally- managed project, each person has a specific role. The tester tests, the coder codes, and the designer designs. And if the project needs more than one person in any of these roles, the Project forms specialized teams. We might have a test team on the third floor, programmers are on second, and the designers, they're not even in the building. They're from an outside agency. On a Scrum team, we do it differently. We create what is called a cross-functional team. A cross functional team is made up of individuals who together have all of the different skills needed to build whatever it is being developed. So instead of a test team or programming team and a design team Scum will feature a team that has testers, programmers and designers on it. A big advantage to a cross-functional team is that it is self-sufficient. It isn't reliant on another team to do something before it can do its work. As an example, think about the projects that I referred to with designers from an outside agency. The programmers can't start their work until the designers finish the designs, and testers can start working until they hand over some code. When teams are structured like this, there tends to be a lot of waiting time. Cross-functional teams greatly reduce waiting times and the effort to manage dependencies. The common myth about cross-functional teams is that each person needs to have every skill, not at all. The team as a whole needs all of the skills to take an idea from the product backlog and fully implement it. Sure, it's great to team members who can do multiple jobs, a tester who could do some programming, for example. But expecting everyone to every have skill is absolutely not necessary. A second way in which Scrum teams differ from traditional teams is that Scum teams are self-managing. A self managing team chooses how best to accomplish its work. Since the team is closest to the work, we want to give them the freedom and flexibility to figure out how to do it. When team members are empowered to self manage, they develop more pride and ownership of their work A common fear around self-management is that the team will just do what they want. Management asks them to build an e-commerce website, and the teams decides making a video game would be more fun. The first book to mention Scrum, Wicked Problems, Righteous Solutions, by Peter DeGrasse and Leslie Stahl, addressed this concern back in 1990. the author said that control is still exercised, but it is subtle and much of it indirect. How a team self-manages is greatly influenced by leadership decisions. Who is put on the team, the size and nature of the challenge given to the teams, how team members are evaluated and rewarded, How tolerant management is of mistakes, and so on. So self-managing teams in Scrum are not running amok working on whatever team members choose. Rather, self management is about allowing a team to determine how they will tackle a problem.

Implications of Shared Roles

Transcript

Many organizations try to mingle the accountabilities of the Scrum Master, Product Owner, and Developers. For example, an organization may decide that the scrum master will also be a programmer or a tester, or that product owner will be also a designer. While this may seem like a good idea at first, it can create problems, especially for a team that is new to Scrum. Having a Sc Rum Master also be a developer can make it hard for the Scum Master to be impartial during discussions. As a simple example, consider a Scrum master who is also a programmer. There will undoubtedly be times when the team is having a deep technical discussion or debate, and our combo Sc rum master programmer will become engrossed in that discussion. For the programmer half of that person, this is fine. But that personally is also the scrum master and should be making sure the team isn't going too deep into solving technical issues in a meeting. Or this combined scrumm master programmer may get so engrossed in the discussion that he or she fails to notice that two team members have mentally checked out of the meeting Arguably more difficult than a Scrum Master who is also a developer is having one person be both the Scum Master and Product Owner. This is a lot like pairing peanut butter and mustard. I like each on its own, but I can't imagine they make a good combination. One of the problems with combining the Product owner and Sc rum Master in a single person is that it becomes very hard for that person to fulfill the scrum master's duty to protect the team. Product owners, by their very nature, often get excited about the possibilities of their product. This leads many product owners to want more, more more. I can assure you, I do this when I'm a product owner. And I have a hard time waiting. A good scrum master is there to protect against that. When a product owner pushes too hard or at the wrong time, such as when a team has burnt out, the scrumm master should be there push back. And this is really hard to do for anyone who is both product-owner and scrumb master. There aren't a lot of guarantees in life, but let me offer a guarantee. Any Scrum team will be better with a dedicated Scum Master and a separate, dedicated product owner who can focus just on that job. But that doesn't mean it's always economically justified. If you're a startup with three people, you aren' t going to have a full-time Scroom Master. Try to avoid mingling the accountabilities of the scrum master, product owner, and developers. Understand the consequences of doing so, but realize that just about every product is constrained by realities, such as budget and availability of people.

Getting Started with Sprint Planning*

Transcript

The Sprint Planning Meeting addresses three questions. Why the sprint is worth doing, what will be accomplished during the Sprints, and how the work will get done. Let's look at each of these questions, starting with why. It's important that everyone on the Scrum team understand why the sprint is to be undertaken. Most organizations have plenty of competing priorities, so why do this particular work? This does not have to a grand justification of the product. It can be as simple as their product owner describing users' most pressing needs and perhaps how those were determined. Starting the planning meeting with why the work is important ensures that everyone understands the value of the works they'll perform during the sprint. Ideally, the reason why their work will be performed can be expressed in a sprint goal. The sprint goals is usually a one or two sentence summary of what the developers will try to accomplish during this sprint allow users to check out and pay for the items in their cart, improve the accuracy of the search results, improved the usability of account maintenance screen, released a first version of Data Explorer with at least 10 visualization types. A sprint goal is not necessarily a product backlog item itself. Instead, we mean goals based on completing a set of related product-backlog items. And at this early point in the sprint planning meeting, the Sprint Goal is only a draft. As the meeting progresses, that draft Sprints Goals can be refined, especially if it turns out to be too ambitious. After the product owner addresses why the work is important, the developers focus on determining what will be accomplished and how they will get it done. These topics are intertwined because it's challenging for a team to know what they're going to develop without having discussed how to do it. To determine what will be delivered in the Sprint, the developers select items from the Product Backlog that align with the Draft Sprints goal. Because the product backlog is prioritized, developers work down the project backlog, selecting as many items as they think will fit within the sprint. As they workdown the backlog developers can ask questions of the products owner to clarify their understanding of what each item means. Most high-priority product backlog items should be aligned with achieving the spring goal. But it's quite often the case that some high priority items are unrelated to the goal, and that's OK. At some point, developers discuss how the items they've selected will be developed. Basically, they discuss the steps or tasks necessary to deliver each item. Some teams determine who will perform each task during sprint planning. Other teams let those decisions be made as the sprint progresses. Similarly, some teams roughly estimate the effort to complete each tasks because this helps them select the right amount of work for the Sprint. Some teams have these discussions as each new item is selected for inclusion in the sprint. Other teams wait until they have a hunch the Sprint is close to full and then discuss all items. Either approach works. The key is to remember that things can and will change during the sprint. team members should not be expected to create a perfect sprint plan. Instead, they should do just enough to confirm they have selected the right set of product backlog items, not too many and not to few, and have a rough idea of how they'll get their work done. The official time box for a four-week sprint is eight hours. It's progressively shorter for teams doing shorter sprints, down to two hours for team doing one-week sprits. I think these are reasonable time boxes or limits for the team that is new to Scrum. For experienced teams, I recommend targeting 45 minutes per week of sprint duration. That means 90 minutes to plan a two- week sprint and three hours to plant a 4-Week sprint. After the developers have selected the work they can do in a sprint, the entire Scrum team should revisit the draft sprint goal. They may choose to reword it, perhaps making it smaller or larger, based on the results of the sprint planning meeting.

The Heart of Scrum: The Sprint

Transcript

At the hardest grum is the sprint. Sprints are short time boxes during which the team turns product backlog items into working product. That is, they take an idea and implement it. All of your sprints should be of the same length. Any length you choose is fine, up to a month. You don't want to do six weeks or two month sprits. It's just too long. Nearly all teams choose a sprint length that is a multiple of weeks. One week, two weeks, three weeks for four weeks You won't find a lot of teams choosing to do three-day sprints. That just makes it too hard to feel the rhythm of a sprint. And that rhythm is important. You want a team to get into a regular rhythm. If they're doing one-week sprint, for example, after a while they don't even think about it. They come into the office on Monday knowing that is Sprint Planning Day and that Friday will be for review, retrospective, and releasing the product. The same idea applies with two, three, or four-week sprints. The sense of rhythm is important. This means you don't want to change your sprint lengths all the time. When I first started doing Scrum, we started each planning meeting by deciding how long that sprint would be. We'd do a short sprint, two weeks, if we were working on small stuff that could be finished in that amount of time. we'd a long sprint if felt the need for a LONG time to complete the work of the new sprint. Even did a few six-week sprints back then. We learned, of course, that six weeks was too long. But we also learned that changing lengths was a bad idea. We do a four-week sprint, then a two, and then another two. Then a three, a six, two and so on. we never got a sense of rhythm to our work until we settled on one length. This doesn't mean that whatever length you pick becomes a life sentence. When I say you shouldn't change sprint lengths, I mean don't bounce back and forth. Pick a length and stick with it until you feel like you have a good reason to make a change. You can change Sprint lengths but don' bounce around between different lengths.

Team Collaboration wth the Daily Scrum

Transcript

Every day during the sprint, teams have a daily scrum, which is sometimes called a Daily Stand Up. Either name works, but officially it's a Dayly Scrum. The meeting is limited to no more than 15 minutes. A common mistake is to think of the Daily Scum as just a status meeting. It's not. I think of it much more as a synchronization meeting. Sure, status is conveyed. I'm working on this, you're working that, and she's working the other thing. But the goal of the Daily Scrum is not just one directional reporting of status. Rather, the goals is for team members to synchronize their efforts. We want to make sure that two people aren't unknowingly working in the same thing, or to realize that no one has started the important critical path task. And yeah, to know those things, team members convey status. Traditionally, each Scrum team member would answer three questions during this daily meeting. Those questions are no longer considered a mandatory part of Scum, and I think that's an improvement. But for many teams, the three-questions remain a great way to conduct the daily Sc rum. The three questions team members would answer in the daily scrum were, what did I do yesterday that helped meet the sprint goal? What will I Do Today to help meet this sprint Goal? Are there any impediments that may prevent achieving this Sprint Goals? Notice that a moment ago I said each team member answers. I didn't say the scrumm master asks each member three question. Sure, a new team will start out with the Scrum Master asking the three questions. But the 3 questions aren't that hard to remember. So after participating in a few daily scrums, I'd really prefer to see the team shift into a mode where each person just answers the questions without being asked. When a scrum master or even another team member asks the questions, the Daily Scrum starts to turn into merely a status meeting. I've been in Daily Scrums where it felt like each team was being interrogated by the scrummaster, who peppered off each question to each member. That's not the feeling you want in your Daily scrums. The daily scrum is for the developers. It's their meeting. The Scrum Master facilitates, if necessary. However, the Scum Master is not there to run the meeting, instead the scrummaster is watching for conflict and impediments and ensures that everyone participates. Technically, the product owner is not required to attend. But I think that's a big mistake. All of the highest performing teams I've worked with have had product owners who did attend the daily scrums. Most of these product donors participated by giving their own short updates. Your team's daily Scrum can occur at any time in the day, but you want to keep the time consistent. It helps everyone remember to show up.

The Sprint Review: Why It's More than a Product Demo

Transcript

A sprint review is held at the end of each sprint. It is a chance for the team and stakeholders to inspect and adapt the product. If stakeholders like what the team has done, the teams should do more of it. If the stakeholders don't like something that team is done the, team may have to go back in and rework it A lot of teams refer to the sprint review as a demo. While demonstrating the product is a key component of the Sprint Review, there's more to it than that. The Sprinterview is also the time to collaborate on the next things to be done to add value to product. Let's walk through what a typical sprint review might look like. Let imagine we're a team opening a new chain of pizzerias. And in the sprint that's coming to an end, the team focused on developing the perfect pizza crust. Our product owner wants to ensure we get valuable and useful feedback and so invites some internal stakeholders. Perhaps our national marketing VP, a couple of salespeople, and our VP of operations who is focused on keeping costs down. It would be a shame to invent a perfect crust that costs $50 a slice. Our product owner also invites a few of our initial franchisees, people who will own and operate individual restaurants in our new chain of pizzerias. And hopefully they invite me because I'd really love to try this perfect crust. During the meeting, the team shares what their goal was for the product increment and what they accomplished. Then they ask the other participants to taste the crust and provide feedback. During the sprint review, the scrum master fosters a really open, transparent conversation about the team's work. One participant might want a lighter crust. Another might love the taste, but wonder if it can be made gluten-free. another might be concerned that to achieve the great flavor, the pizza is cooked longer at a lower temperature, which will affect cost and delivery time. The product owner processes this feedback and uses it to influence what the team will build next. If the gluten-free idea is essential, it may be added to the top of the product backlog. Reducing cooking time, on the other hand, may worth doing, but doesn't need to be done immediately. Not all feedback needs to acted on. Perhaps only one person thought the crust should have a lighter taste. The product owner may choose to ignore certain comments. Ultimately, its the Product Owner's call. Sprint reviews should occur at a regular cadence at the end of every sprint and are no longer than four hours for a one-month sprint. The majority of teams find that an hour, maybe two, is sufficient.

The Sprint Retrospective: The Scrum Team

Transcript

Congratulations on finishing your first sprint. Now let's reflect on the process. In Scrum, we call this event the Sprint Retrospective. The Scum team inspects its process and how it can improve during the next sprint. This takes place at the end of each sprint on a regular cadence, ideally shortly before sprint planning. It is time-boxed to no more than three hours for a one-month sprint, but most teams can have a good retrospective in under an hour. There isn't a scrum standard for how a retrospective is done, only that the team takes time to reflect on its process at least once every sprint. Although a formal retrospect is held at the end of each sprint, that doesn't mean team members need to ignore obvious opportunities to improve whenever they discover them. Here's one way that I've seen a good retrospect happen. There are a pile of sticky notes on a table. All of the team members take a few minutes and a sticky note to jot down what they think went well in the sprint and where they can improve. If team-members are working remote, you can do the same thing with any general purpose whiteboarding software such as LucidSpark. When all of the ideas seem to have been generated, the team members place the sticky notes into one of two columns that are pre-drawn on one the walls or in the software, what went well and where to improve. Some teams use a happy or sad face as column headings. The Scrum Master, or anyone on the Team, begins reading off the Sticky Notes. Many notes will spur further discussion. A good team isn't just going through the motions here. They really want to talk to each other and improve. At the end of the retrospective, team members agree on one or a few ways that they can improve in the next sprint, and they commit to make it happen. Since Scrum is all about continual improvement, we want to think about incremental change. A team with a healthy retrospective is one that is able not only to talk about change, but also to see it happen, even if it's just one small change a sprint.

The Product Backlog - A Prioritized Features List*

Transcript

There are three artifacts in Scrum, the product increment, product backlog, and sprint backlog. Artifact is just a fancy word for something made or given shape by man. Stonehenge is an artifact built by ancient druids 2,500 to 5,000 years ago, or according to some, perhaps built my aliens. Each of Scrum's three artifacts include what is called a commitment. I find that term a bit confusing. You can think of each artifact's commitment as what the Scum team is working toward with that artifact. With the product backlog, the team is working toward a product goal. With this sprint backlog the, team working towards a sprint goal and for the increment that will be built in a Sprint the Team is Working toward meeting a definition of done. Let's begin by looking at the Product Backlog. When I first started doing Scrum, that term didn't yet exist. So my teams called this a prioritized features list. I'm not suggesting a change to the vocabulary of Scum, but I still like that. The product backlog is a prioritize features. It's a list of the desired features, and it's been prioritised by the product owner. As such, the product backlog should contain everything the Product Owner once added to, or done to the, product. I should be careful when saying everything. The product backlog does not need to include things in the team's distant future. Why not? Because the project backlog is emergent. It evolves over time. The product backlog is always changing and evolving as the product owner and the rest of the team discover new information about the products. In traditional project management, we had a requirements phase. In that phase, We expected all of the product requirements to be known ahead of time. in Scrum,we recognize that we need to quickly adapt to change and that planning is good, but detailed planning should only occur shortly before we do the work. Because the Product Backlog is prioritized, higher priority items are at the top of this list and are likely to work on sooner. The items toward the bottom of the list may be vague ideas, and that's okay. As they move up the lists, more detail is added. Items on the product backlog should be created and prioritized in pursuit of a product goal, which I mentioned earlier as the commitment associated with the Product Backlog. The Product Goal describes a future state of product. it is essentially the products owner's vision for the The team and product owner can define a product goal that is any distance into the future. A month, a quarter, or a year, decade, an eon. My recommendation is that a Product Goal should be far enough in the Future to be inspirational, but not so far away that progress toward the goal is barely discernible each Sprint. I like setting a series of quarterly Product goals. Achieve one, and then set the next Product goal three months further ahead.

The Sprint Backlog – A Plan for Delivering the Work of the Sprint*

Transcript

During the sprint planning meeting, the developers will create a sprint backlog. A sprint back log comprises three elements. The sprint goal, a subset of product backlog items selected to be worked on during the Sprint, and a plan for how the team will complete that work. Let's look at each of these three items. First is the spring goal which is a team's single objective for the sprints. The sprint goal should serve as a focal point for the work of a sprint. The goal can also be used for assessing the success of the sprint If the goal was met, the Sprint was a success. A well-formed sprint goal will not define specifically how the developers will achieve the goal. For example, I worked with a team developing data visualization tools. They had a sprint go to triple the number of charts that could be rendered per minute on a given hardware configuration. The team was given a clear goal, but they had many ways they could achieve that goal The second element of a sprint backlog is the subset of product backlog items that developers plan to work on and try to finish during the sprint. During sprint planning, the developers work their way down the prioritized product back log, selecting as many of the most valuable items as possible. As developers are doing this, they are creating the third element, a plan for how they will deliver that work and achieve the Sprint goal. The plan doesn't need to be detailed, thorough, or complete, but the developers should leave sprint planning with a set of product backlog items they plan to deliver within the sprint, and at least a rough plan of how they'll work together to do it. This means that most teams augment the set of product backlog items for this sprint with a short, rough list of tasks for each item. This helps a team assess whether they are committing to too much work, too little, or just the right amount in the coming sprint. No one should expect the team to leave a sprint planning meeting having thought of everything. The sprint backlog will emerge throughout the sprint. A good team will think of most things during sprint planing. But I think it's impossible on a complex project to think all tasks up front. And even if a team does, it is impossible for team members to know who might be out sick or fall behind during the Sprint. So at the end of the sprint planning meeting, the team leaves with a rough plan for how they'll coordinate and work together during the Sprint. But things change. and team members will discover a few new tasks that need to be done as they begin work on each product backlog item. Adding these newly discovered tasks to a sprint backlog should not be confused with adding new product-backlog items within a Sprint. Once a sprints has been planned, the product owner should endeavor to resist the temptation to request new functionality from the team within the Sprints. But that's different from a team adding into its own sprint backlog a task or step they did not identify during the planning meeting.

The Product Increment*

Transcript

Let's look at the third of Scrum's artifacts, the product increment. The product incremental is the thing being built, produced, developed, or delivered by the developers. Increment is a step toward the Product Goal. Multiple increments will often be needed to reach a Product goal. In delivering each increment, the developers strive to produce work that meets an agreed upon definition of done. This is a set of criteria that must be met for the work to be considered complete. In Scrum terms, that definition have done is the team's commitment for their product increment. As a first example of a definition of done, a software team may agree that work can only be considered done when the code is written and meets coding standards, the coat is checked in, The code fully validated with automated tests, and any necessary documentation has been updated. Let's consider a marketing team for another example. Their definition of done may state that an ad is done when the copy has been approved by the lead copywriter, the ad has be double-checked for spelling and grammar errors, their graphics have been improved by lead designer, and the add has approved the client. and agreed upon definition of done improves communication among everyone on a Scrum team. It also clarifies exactly what the target is for the work of the sprint. Without a definition of done, team members could have varying assumptions about the work to be done in this brand. To see how this works, and since it's getting close to lunch as I record this, let's again use pizza as an example. Suppose you plan to open a new pizzeria. You know you can't just toss some pepperoni, cheese and sauce on a store-bought dough and be successful. you need to come up with a great new pizza recipe for your pizza restaurant to succeed. You start by establishing a definition of done. Let's say that includes tastes great, can be cooked in a reasonable amount of time, and uses only sustainable locally sourced ingredients. But you don't try to do everything all at once. For the first sprint, you establish a goal of determining the recipe for perfect pizza dough. You start with your grandmother's famous pizza-dough recipe and fine-tune it during the sprint. And you offer taste tests to friends and family. At the end of that sprint, you are done thinking about pizza dough. You've met everything on your definition of done. This is your first increment. you've taken a step toward achieving a product goal of having a great tasting pizza you can sell. Next sprint, you turn your attention to the sauce. You experiment with a few variations on Grandma's secret recipe that she entrusted only to you. By the end of the second sprint you've got the perfect sauce to go on the Perfect Crust that you developed the prior sprint. In each sprint the developers incrementally improve the product. With each sprint and each increment, the developers move a step closer to the product goal. To help make this happen, sprints are time-boxed to no longer than a calendar month. Not surprisingly, most teams operate in one, two, three, or four-week sprints, with two weeks being by far the most common time box. Time boxing the sprint creates an appropriate sense of urgency. Not so much urgency that developers rush and make mistakes, but enough urgency, that the team keeps the goal and deadline in mind.

Timboxes: Maintaining a Sense of Urgency

Transcript

You've probably heard me talk about time boxes a lot by this point in these videos. We have a time box for all meetings in Scrum. Even the sprint itself is time-boxed. If your team has two-week sprints, two weeks is the timebox. A time Box is a maximum, not a recommendation. So when I say that the daily Scum is Timebox to 15 minutes, that means it takes a Maximum of 15 Minutes. Why are time boxes so important in Scrum? Back in 1955, a British historian, Cyril Parkinson, noted that work expands so as to fill the time available for its completion. This has since become known as Parkinson's Law. It means that the more time we have to do something, the longer time doing it will take. Time boxes keep team members focused and create a sense of urgency, whether in a time box meeting or a Time Box Sprint. the urgency creates a bit of pressure. Finish this within a certain amount of time. You don't want it to create so much pressure that team stress levels rise, just enough pressure to be aware of it. The 15 minute time box for a daily scrum is plenty of times for most typical seven person or so teams to synchronize their efforts. But the timebox reminds them to careful of going too deep into discussions during that meeting. One of my favorite sayings is be quick, but don't hurry. It comes from legendary college basketball coach, John Wooden. He won 10 national championships in 12 years. he was an amazing coach. By be-quick-but-don't-hurry, Coach Woodin meant to get good at a task so you can do it quickly and confidently and to do the work deliberately but without feeling rushed, especially to the point where you make mistakes. The time boxes of Scrum are all quite sufficient for doing high quality work. You want your team to execute them quickly, but without feeling hurried.

Product Backlog Refinement: Getting Work Ready

Transcript

The product owner and the developers get work ready for sprints in an activity called Product Backlog Refinement. Product backlog refinement, sometimes called backlog grooming in reference to keeping the backlog clean and orderly, is a meeting that is held near the end of one sprint to ensure the product backlog is ready the next sprint. During a product backlog refinement meeting, the team and product owner discuss the top items on the product back log. The team is given a chance to ask many of the questions that would normally arise during sprint planning. Perhaps questions like, what should we do if the user enters invalid data here? Are all users allowed to access this part of this system? What happens if? If those questions were asked for the first time during sprint planning and too many could not be answered, it might be necessary to put a high-priority product backlog item aside and not work on it during the sprint. By asking these questions before the Sprint Planning Meeting, the product owner is given time to figure out answers he or she may not prepared to answer immediately. In fact, sometimes the backlog refinement meeting ends with more questions than answers, and that's OK. Remember that the whole point of doing backlog confinement is to alert the product owner to high-priority items that are not well understood so that they can be made clearer in time for the sprint planning meeting. Backlog refignment, in that sense, is really a checkpoint rather than an effort to fully resolve issues. I like to hold the product backlog refinement meetings two or three days before the end of the current sprint. This gives the Product Owner sufficient time to act on any issues that are identified. Some teams find that doing shorter meetings every week rather than once per sprint is more suited to their cadence. And that is, of course, fine. Many teams will have the entire team participate. There are two big advantages to doing so. First, everyone hears the product owner's answers. Second, it allows the teams to estimate product backlog items as they are discussed. The drawback to having everyone participate is that more person hours are spent on refinement. My personal view is, that having half or slightly more than half of the team participate, along with the product owner, and ideally the scrum master, is sufficient. With half the of team present, not as many questions will be asked. And that's a shame. But I suspect that with half, or so, of a team president, they still think of 80 or 90% of their questions. The big advantage to this is that in almost every sprint, there will be a person or two who is frantically busy with only two or three days left in the sprint. If that person has to attend a refinement meeting, it may mean they need to work late one evening or that a bit less functionality is delivered in this sprint Experiment with both approaches and see what works best for your team. Some teams need to be cautioned about spending excessive time refining their product backlogs. A general rule of thumb is that no more than 10% of a team's total time available within a sprint should be spent on backlog refinement. That includes the meeting itself, as well as analysis and other work that may be spawned from a refignment meeting.

Scrum Master

Strengthen your Scrum Master practice with guidance on facilitation, team coaching, Scrum events, sustainable pace, common mistakes, and helping teams become more effective.

Should You Become a Scrum Master: Before You Say Yes, Consider This

Transcript

The most important, perhaps the only reason to become a Scrum Master is that it's the right job for your skills, personality,
and interests.
But there's one skill that's especially hard to learn that might help you decide whether you have what it takes to be a scrum master.
Hi, I'm Mike Cohn and I am the author of three best-selling books on Agile and Scum.
I help teams succeed with Agil and want to help too.
And I want here to share with you the one question to ask yourself if you're thinking about becoming a scum Master.
The best scrum masters excel at certain soft skills, listening, conflict resolution, humility, and a desire to help others.
I've written a blog about the seven questions you should ask yourself if you're considering a career as a scrummaster.
Follow the link above to get the full list.
But by far the hardest thing to learn is how to influence without authority.
I find this especially true for those who transition to Scrum Master from roles that do have authority, such as project manager and tech lead.
One of my favorite ways of influencing is by asking questions.
For example, if a team is trying to make a decision or has just made a decisions that they're explaining to me, I might ask,
what was the second best option you considered?
I may follow that up with, why did you prefer the option that you chose?
These questions can help bring out any dissenting opinions that still exist on the team.
If you enjoy leading this way, count that as a point in your favor for a career as Scrum Master.
Don't rule out being a Scum Master, though, just because you're in the habit of saying, because I told you so.
In my earliest leadership roles, I fell into the trap of that unfortunate style.
You can overcome it.
It just takes a little time and training.

New Scrum Master: 4 Tips to Avoid Traps

Transcript

Beginning an assignment as a scrum master is exciting, but there are four traps into which I often see new scrums fall.
The first is thinking one size fits all.
I recommend new teams or scrummasters begin by the book.
Do Agile in some known, proven way.
That may be following the Scrum Guide, a trusted book on Agil, or what you learned in a class.
However, over time, it is a critical success factor that the team owns its process.
The way to do that is by experimenting with small adjustments to whatever agile framework you use.
Keep the experiments that work, toss away those that don't.
The best way to avoid a one-size-fits-all mindset is to look for good ideas in all the various agile frameworks.
Start with Scrum, Kanban, XP, Safe, or whatever you want, but remember to inspect and adapt, mix and match, to make the process the team's own.
A second trap I see new Scum Masters fall into is thinking they alone are experts at Sc rum.
A scrum master may have been a team's only expert in the early days of Scrum, but Scum and Agile are pretty prevalent today.
Almost every team will have at least one person with solid Sc rum experience.
Rely on these folks.
If you're new to the team and they aren't, ask them to share with you what has and has not worked in A third trap is falling back into the activities of
your prior role.
I see this all the time.
One scrum master, Tice, told me that he reverted to his programming responsibilities because he was not initially comfortable with everything expected
of him as a scrummaster.
He said it felt good to do something he knew he did well.
If you've been promoted to Scrum Master and told to continue doing your old job, then you need to do so.
But avoid falling back into old habits merely because they're comfortable or to improve your feeling of self-worth.
A final trap is not becoming an expert on your product.
During a meeting, I was embarrassed for Annika when stakeholders asked her how certain features worked and she couldn't answer.
She'd anticipated the product owner being present at the meeting but something came up and the Product Owner could not attend.
Annica was left alone to discuss recent changes to the system with stakeholders.
No one was expecting her to know the product as well as the Product Owner, but her inability to demonstrate the latest features hurt her credibility.
You don't want to be a scrum master who doesn't know how to use the product you're helping a team develop.
A new role can be intimidating at first, but by avoiding these four traps, you can help your team succeed with Agile.
By the way, if you want get beyond just avoiding traps and really excel in your scrumm master role, consider participating in one of our Certified Scrum
Master or Advanced Certify Scum Master courses.
I've put links in the description.

3 Rights Every Effective Scrum Master Needs

Transcript

As a Scrum Master, you have certain rights and responsibilities.
In this video, I'm going to share three rights you need to be successful.
The first right of a scrum master is to have access to stakeholders and decision makers.
Lack of access isn't a common problem, but it occasionally comes up.
I worked in a call center systems project in which the developers and Scrum Master were not allowed to talk to the stakeholders.
The theory was that the call-center agents, who were all nurses, were far too busy to talked to developers, and the Scum Master.
That busyness was why they needed new software.
But without being able to learn their needs firsthand, we were making some bad decisions.
Everything had to funnel through our product owner.
That was not a scalable solution with over 100 developers on the project.
The developers basically resorted to stalking the nurses in the lunchroom because that was the only time that they could meet.
when a nurse was on his or her break.
That project was ultimately successful, but it probably could have gone faster if both the programmers and the Scrum Master had been given more access
to stakeholders and decision makers.
A second right of the scrum master is to be able to experiment with new ideas.
I love the fact that the majority of world now does two-week sprints.
But I think we've lost something as we moved away from four-week sprint.
Here's what we've lost.
The ability to experiment as frequently as we used to in the early days of Scrum with its longer sprints.
To see what I mean, consider a team in those early-days of scrum.
They would be doing a four-week sprint.
And imagine they have two options of how to achieve a goal.
One is the tried-and-true way.
Second is a possibly better way, but it's unproven.
The new way may not work, but if it does, it'll be better.
And with four-week sprints, teams very often would choose to try the riskier, breakthrough, innovative way, because if didn't work they would have just
spent three or four days on the experiment.
There would still be plenty of time to recover, to switch back to the safe approach.
Now we've moved towards shorter sprints and a lot of organizations have turned Scrum into a check the boxes process for determining if you finished all
the items you said you would.
If you did, you're successful.
But if haven't, failed.
And as that's happened, teams have moved away from feeling safe with experimentation.
Innovation recedes.
And so I'm mentioning this to you because I think it's important that we, as scrum masters, fight to establish experimentation as part of the company culture.
I am not talking about taking wild gambles or about experimentation during the final sprint of a major project.
But there are plenty of times during a project when it's worth trying an innovative breakthrough approach that may not work.
It's a worth a gamble sometimes instead of always using the tried and true approach.
Scrum Masters also need the right to address issues openly.
Part of your role as a Scum Master is to bring up problems and issues that need to be addressed.
If your company has a shoot the messenger culture, it'll be hard for you to continue bringing up issues when you're criticized and maybe even personally
attacked every time you do.
Do you have these rights in your organization?
Did you to argue to earn them?
Are there any additional rights you think you need as a Scrum Master?
Let me know in the comments.
I appreciate every comment.
If this video has been useful, click the Like button.
And if you're new to the channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching, and I'll see you next time.

7 Mistakes Every Scrum Master Makes, and What to Do About Them

Transcript

Is your scrum team not doing as well as you know it can?
From letting work roll forward from sprint to sprint, to taking the scrumb guide as gospel, many of the thousands of scrummasters I've worked with make
the same mistakes.
In this video, I'm going to share seven mistakes you'll definitely make as a scrhum master and what you can do about them.
Hi, i'm Mike Cohn, and I am the author of three bestselling books on Agile and Scrum.
I help teams succeed with Agil.
Let's dive right in with the first of seven mistakes scrummasters commonly make, and that is sharing your opinion too readily.
As a scrummaster, you want your team to own the problems and their solutions.
When you add your own opinion to readily, sometimes you shut down that conversation.
I definitely suffer from this problem.
Here are two easy things you can do that will help.
First, on your way into a meeting, tell yourself you will not share your opinion until one, perhaps two people have shared theirs.
No matter how good you think your idea is, commit to keeping your pie hole closed until some specific number of others have spoken first.
Second, when you ask a question, something like, how can we solve this problem?
Give your team time to think before you jump in with a solution.
All too often, I see Scrum Masters ask the team a hard question and team members do what they should.
They think about it.
But while they're thinking and before they can respond, the Scrum Master says, OK, maybe we should do this, or I guess we'll come back to that issue next meeting.
Silence can be uncomfortable.
When you ask a question, it can feel like everyone is staring at you waiting for an answer.
They may be staring at you, but they're thinking, just like you asked them to do.
Try counting silently to 10 before you say anything.
After 10 seconds, consider asking people to share what they are thinking or ask a follow-up question that may get them closer to a solution.
A second common scrum master mistake is telling the team what to do more than selling them on ideas.
Over time, good scrummasters change how they interact with their teams.
With a team that is new to Scrum, you may very well need to tell them to certain things.
You'll tell their sprint cannot be longer than a month.
No, they can't skip daily scrums or sprint retrospectives.
A team isn't very agile when you're having to tell them what to do.
But until they've gained some experience with Scrum, they may well rebel against things whose value they haven't yet learned.
With experience, teams become more independent, so that instead of telling them, you can sell them on ideas.
You can, for example, suggest they automate more tests or even begin automating at all.
You can try to sell them on the benefits of shortening their sprints.
Teams are truly becoming agile when you can switch from telling to selling.
And as a team progresses, you step back further.
Instead of selling them what you think are good ideas, You encourage and facilitate their discussions and pursuit of improvements they come up with.
A third common mistake by new Scrum Masters is running the daily Sc rum.
The daily scrum is a simple meeting.
Team members show up, discuss their progress, plans, and problems.
It helps team members synchronize their work.
Because it happens every day and has such a single agenda that is consistent from day to day, you don't need to run it.
Oh, sure, I'll run the dailies from the first few times for a new team.
I will announce that we're starting the meeting, then I call on one team member, ask them to share their update with everyone,
and then call the next person.
Finally, announce we are done.
But I want out of doing that as quickly as possible.
It's boring for me and boring the team, but it's not needed.
You want to get people to the point at which they show up and whomever wants to go first just begins.
Maybe team members report in a defined order, maybe the current speaker names the next speaker, or any other process.
The key is to get out of running the meeting yourself as soon as you can.
When the scrum master runs the daily scrumm, the meaning begins to feel as though it's for the Scrum Master.
the Meeting exists for team.
when they run it, it feels that way.
Still on the topic of the daily scrum, that meeting is also the source of a fourth mistake you may make as a new scrumbaster,
skipping daily scrums or retrospectives.
Just as new scrum teams may question the usefulness of daily scrums and retrospectives, so may new Scrum Masters.
But here's why skipping daily Scums or retrospective is the fourth mistake of new Scrum Masters The various aspects of Scum have all evolved to support
one another.
It may seem harmless to perhaps do daily scrums only two or three days a week, and when a team has sufficient experience,
I'll actually be open to hearing their argument for this.
I rarely agree, but as a scrum master, i'm open.
But early on, do scrumb by the book.
That includes doing a retrospective at the end of each sprint and doing it daily, well, every day.
While I suggest doing Scrum by the book when you and the team aren't new to Sc rum, you don't want to do that forever.
And this is the fifth mistake many Scum Masters make.
Taking the Scram Guide is gospel.
It's just a PDF.
As you in the Team progress, your experience should let you identify changes you want make, and it's possible some of those may go against what's written
in The Scam Guide.
That's fine.
Be careful deviating from it, but consider it.
The next common mistake, number six on our list, is thinking that everything is a user story.
User stories are great, I love them.
I wrote a whole book about user stories, but not everything on your product backlog needs to be a users story, so if you've encouraged your team to always
write as a type of user I want so that Stop.
Sometimes a simple statement is enough.
For example, upgrade the Linux server works great as a product backlog item.
The last common mistake is one of the worst, and that's letting work roll forward from one sprint to the next.
It's unrealistic to insist a team finish everything they start every sprint.
If you do, most teams will respond by very conservatively planning their sprints so they can finish.
But when a teams consistently fails to finish, the end of a sprint becomes an arbitrary meaningless date.
It arrives and team members just move work forward into the next sprint, no big deal, they think.
You want your team to instead think of the end of a sprint as significant.
Each time they finish what they said they would, they gain a little more trust from the business stakeholders.
That trust translates into an improved relationship.
To solve the problem of letting work carry forward, you need to break the team's habit of overcommitting.
Have them commit to what seems ridiculously easy in the next sprint, and then add to it later if it becomes clear they'll finish.
In this way, they'll feel what it's like to over deliver rather than to continually under deliver on what they said.
What other mistakes have you made or seen Scrum Masters make?
Let me know in the comments.
I read every comment and I plan to make new videos about some of the problems you mentioned.
This video is part of a three-part series.
Be sure to check out the seven mistakes product owners and teams make by clicking the links.
Don't forget to subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching, and I'll see you next time.

Scrum Explained — Roles, Events, Artifacts, and Sprints

Transcript

So we're going to talk about how to get agile with Scrum, how do you bring more agility into your organization.
I grabbed this quote out of this article, because I like this quoted, I think it gives us a good feel for what Scum is about.
Nobody is doing Sc rum in 86. What happened is a couple of Japanese researchers wanted to find out what was working well in product development,
not software development.
They went around and they studied successful companies.
They labeled what they saw, Scrum.
So that's where the name Scum came into things.
These authors wrote that the relay race approach to product development.
Now most of us are software people.
What's another word we use for relay-race approach?
What do you think they're talking about there?
We're software people, right?
What's the big nasty process?
Waterfall, all right.
Talk about waterfall.
So the waterfall approach may conflict with the goals of maximum speed and flexibility.
They say instead what we want is a holistic or rugby approach.
There's where this word scrum's going to come in.
It's part of the game rugby.
And they say we have this rugby approached where a team tries to go the distance as a unit, passing the ball back and forth,
and that may better serve today's competitive requirements.
Focus on that last phrase for a second.
Today's competitive requirements.
Remember when I told you this was written?
1986. They were saying waterfall doesn't work.
It's 1986 and waterfalls too slow for us.
We need something better.
What are we doing thinking 26 years later that waterfall might even possibly work?
Today's competitive requirements, 2012, 2013's, competitive requirement, we absolutely need something that is going to lead to faster and more flexible products.
This is where Scrum is gonna come in.
So Scum gets its name from rugby in the middle there.
And fortunately, I played rugby one drunken day during university.
So I can explain what a scrum is all about from that one drunken day.
We used to play American football every Saturday when I was in university.
The guys in my dorm, we'd get together, play America football, every saturday.
One Saturday we had a guy from London who said, no, now we're playing rugby next week.
And we said okay, you have to teach us how.
He did, he taught us to how to it.
I'm not sure all of his rules were the official rules.
which explains why it was a drunken Saturday.
One of his rules was the mandatory beer break every five minutes.
So every 5 minutes, we'd run over the sideline, have a beer, and come back and start up again.
And the thing I remember from him teaching us how to play, my job, I lined up over here on the right side.
I was in the front of the line of three people.
Had my left arm out.
Steve, our guy from London, was over on here the left side with his right arm.
In between us was third guy.
We were actually holding him up.
He didn't have his feet on ground.
And our job was to push forward, the guy without his feet on the ground, his job is to kick the ball.
The ball was rolled in between us like a puck would be dropped in a hockey game.
And so this was this metaphor for what software development was all about.
It was just this idea of kind of a chaotic environment, everybody with their own special responsibilities though, but a very common purpose.
We were locked together, we had our arms around each other.
The guy in the middle, for example, if he took his arms away, he'd fall down on the ground.
So we had our arms together pushing for a common purpose.
This is where this metaphor came from.
I work with a lot of different companies in the US and Europe.
And one of the companies I've worked with off and on for the last 24 years has been Apple.
I want to just share a little quote from Apple here, actually from an article about Apple, this is from article in Time Magazine,
a news magazine in US.
The author in here wrote that Apple employees talk incessantly about what they call deep collaboration.
cross-pollination or concurrent engineering.
Essentially means that products don't pass from team to team.
There aren't discrete sequential development stages.
They said instead it's simultaneous and organic.
Products get worked on in parallel by all departments at once.
Design, hardware, software, and endless rounds of interdisciplinary design review.
If you ask Apple what they're doing, they call it their own thing, the Apple process.
But this is very much Scrum.
This is what Scum is doing here.
So, Sc rum is about these lack of handoffs, it's about working together, interdisciplinary design, all working deep collaboration.
I just want to list a couple of the companies that Scrum has been used in.
I'm not going to read all those.
You can take a look at these.
By the way, this presentation is on my website.
This presentation in fully available in PowerPoint and Keynote format for you to grab and make your own.
So you've got to go back and introduce Agile or Scum to your organization.
And you can use this representation.
The slide was really useful 10 years ago when I first started putting a lot of this together, because people then were wondering,
well, who's using Sc rum?
It's kind of a dumb slide now, just about everybody's using Scrum, right?
We can make thousands of companies on a list like this for people who are using scrum, so it's not that unique anymore.
Scum's also been used in just every type of application, video games, Department of Defense in the U.S., government applications,
commercial applications websites.
federally regulated banks.
In fact, used by the main bank in the US, our Federal Reserve.
It's used in medical devices, so Scrum is used on just about anything.
A couple of the characteristics of Scum.
Scums focused on having what are called self-organizing teams.
Self-organizing team means that we do not have one person, typically called a tech leader, something like that, who gets to assign out all the tasks.
Why don't you do this?
You do that.
You did the other.
Oh, and I'll do the fun thing.
We don' have that person on a Scrum project.
On a scrum project, the team self- organizes.
They're given a challenge.
Build this.
we need it by the end of the year.
And the team figures out how to do that collaboratively.
They work together.
Hey, I was thinking of doing this.
Well, so was I.
Why don't we work on it together?
So the teams together figures who's the appropriate person to work something.
There's not one person who gets to delegate that task assignment out.
Another characteristic of Scrum is that the product or project is built in a series of what are called sprints.
Each sprint is anywhere from one to four weeks, no longer in a month.
Some teams do calendar month sprints.
Those are very rare.
Most common, two weeks.
So teams will work in these little two-week increments, and they'll build some part of the product each two week.
Every two we get to see what the team has worked on, give feedback on it or get feedback, show it to customers.
And we use that information to inform what to do next.
Do customers like what we build?
Scrum uses something called a product backlog.
So this is a term we'll hear during a session on the product back log, the end of the day today.
The last session will be on product the backlog, and something call user stories.
You've heard much about agile, you might have come across this term, user story.
There's just a way of capturing requirements.
I was saying that the Product Backlog is it prioritized, features list.
It's a list of things we want, prioritised by somebody we call product owner.
One of nice things, I think, but also a dangerous thing about Scum, is it doesn't prescribe any engineering practices.
Scrum doesn' t say you have to do test-driven development.
Doesn't say that you need to pair a program.
It doesn t have automated testing.
In fact, it does not say it has to test at all.
All right, Scum doesn''t say anything about the engineering practice.
The engineering practises are left where they should be for the team to figure out.
Now, all those things I just listed, I think, are all good things.
Scrum doesn't say you have to have version control.
I've never met a good Scum team that didn't.
But that's up to the Team to Figure Out.
What's nice about this, what this means, is that Sc rum is a general purpose project management framework.
Scrum can be used for all sorts of things, not just software.
In fact, if you think back a few minutes where I said it originated, it originated in product development, Not even software development.
Scum started to take off when it hit the software world, because software has such a need for speed and flexibility.
But, scrum can used anywhere.
One of my favorite examples is every year there are examples of people who plan their weddings with scrums.
Think about that.
Normally, things like pick spouse are already done.
But the rest of the product backlog has things, like picked the venue, picked a caterer, create the guest list, pick the music,
all that type of stuff.
So people will use Scrum to manage all sorts of projects.
That wouldn't make any sense to plan a wedding if you had test-driven development.
How do you do that?
One of the things that is nice about Scrum 2 is it's fairly straightforward.
It's very simple.
There's no 200-page rule book on Scum.
And there's not this massive list of rules.
You've got to do this, you've gotta do that, and you gotta this.
The few rules that we do have in Sc rum are what are called generative rules, Generative rules.
They're there not so much because we care about the actual following of the rule, as we about care the behavior that following that rule generates.
So one of things you might have heard about Scrum is we have a daily stand up or daily Scum meeting.
Teams come together and talk once a day for 10 to 15 minutes.
I don't really care that we get together.
I really don' care we have those 15 minutes of discussion.
What I care about is the discussion it creates.
So we've learned that having teams talk frequently is a great thing.
One of the easy ways to generate that behavior, that's what we want, is to put in place this rule.
Get together once a day and talk.
It's not the rule that you care as much as the behavior that it create.
And I mentioned that Scrum is one of the Agile processes, lots of different other Agil processes.
Feature-driven development, adaptive, Kanban, extreme programming, Lean, DSDM, Crystal.
I don't know if I've already mentioned one.
Lots of other agile processes Scum is the most popular.
Recent surveys showed about 70% of people doing Agiles were doing Sc rum.
So Sc Rum by far the more popular Now here's where Scrum is the most successful.
This is a graph showing the mapping of on the horizontal axis how uncertain our technology is.
And maybe you're doing your one millionth Java application.
You're pretty close to certainty.
Maybe you are doing you first closure application, the way over on the right now.
We've never done that, we've ever built anything like this.
On the vertical axis what we're showing is how far from agreement we are on requirements.
Do we know what were building?
We are building a simple address book.
There's bunches of these out there.
We know the requirements.
we can copy them from other products.
That would be low on the vertical axis.
Are we doing something novel, something that has never been done before?
or at least not by us.
We'd be high up on that vertical axis.
So what we're looking at here, if you map these two, we can see the projects that have a lot of technical uncertainty, a lack of agreement on the requirement
side is going to be in the top right there.
Right?
Probably nothing's going to work there, right?
You've got a lot of technical uncertainty.
You're not even sure what you're building yet.
The best thing to do is get some certainty around one of those two things.
Before you build the world's biggest, scariest, most novel closure application, get experience with the language, all right,
or prototype something so you know what it is you are building.
Move out of the anarchy region in one direction.
Let's go down to the bottom.
Down in the left bottom there we've simple.
This is right in a simple address book.
Done it before.
Same technology.
You can be successful with other processes here.
Scrum can't be okay, but it's not going to get you huge benefits there.
Where Scum is particularly helpful is what are called the complicated and complex regions in there, where we have fair amounts of both technical uncertainty.
This can tough.
I don't know how we're going do this.
And I'm not exactly sure what we're building.
We've got a vision, we are headed out here, but we have to see what our customers say.
Those type of projects, when there's a fair amount of uncertainty, that's where Scrum is going to have its biggest benefits for us.
That's what most of our projects are too, especially in the software world.
So let's look at what Scrum is all about.
And by the way, if you have questions at any point, just raise your hand or signal me in some way.
I'd like to take questions as we go.
We keep kind of scanning back and forth.
You've got this weird, long, skinny room.
So I keep trying to see if we have any comments or questions.
If we do, please raise you hand.
So let's see what Scrum looks like.
Let's build up a Scum process diagram here.
We're going to start out with something called our product backlog.
This is that prioritized features list.
Now suppose we're gonna build an e-commerce website.
I've got a couple of features I want to add to our site.
we've had a basic site up.
Where no Amazon yet, but we got to basic sight going.
And we'd like to ad to this return, gift wrap, and cancel.
Those are the features we want next.
Our product owner prioritizes those features for us.
The team is going to make progress against those features in sprints.
These are the one to four week time periods I mentioned.
At the start of a sprint, the team has to figure out, what are we going do?
And so the teams gets together and has a meeting to discuss the product owner's priorities.
And they select some amount of work off the Product Backlog.
In this case, I've only selected one item.
A team will almost always grab more than one.
For graphical simplicity, I'm just grabbing one item here.
Makes the picture easier.
So in this sprint, our team has decided we will deliver returns.
People can return a purchased item.
I don't like this book.
Sending it back.
All right.
Hope I didn't read it first.
To do this, we have what we call a sprint planning meeting.
The sprint planting meeting is where the team selects the amount of work to do.
In the sprint plan meeting, the teams creates what is called their sprint backlog.
A sprint backlog is a list of tasks necessary to deliver the product backlog.
Now here's something I wish we hadn't done in Strom.
I really wish that we had done this.
We've overloaded the word backlog, product backlog, sprint back log.
There's two, okay?
There are two.
Product backlog big visible features.
Look at the things up there.
Cancel, gift wrapping.
All right, return an item.
Those type of things, big visible things.
Customers might see those.
The sprint backlog is tasks.
It's going to be things like design the UI, all right?
Code, test, create some test data, automate this, have a review meeting with the customer about such and such, those type things those will be our task list,
our sprint back log.
At the end of the sprint, the team comes out with something we call potentially shippable product increment.
Basically, what we're talking about here is finished, done, tested, working code.
Some feature is done.
And we put the word potentially there to indicate that we do not need to ship this thing.
We may not release this at the end of the sprint, the ended the couple of weeks, but we could if we wanted to.
It's high enough quality that could.
So what were after here something that's, high quality, potentially shippable.
One of the things that appealed to me about Scrum when I first started to learn about this is that Sc rum takes essentially a two-faced approach to change.
Scum says no change in the sprint.
No change in the sprint.
What we're trying to do there is allow the team time to focus.
So the Team doesn't have to be always looking over their shoulder going, things are going to change.
I shouldn't make this big change on the code.
They're going change direction on me.
And I know I'm about to get interrupted.
Right?
So we want to create an environment where the teams can focus, but we know change happens.
We have accommodate that change, so we let that happen at the level of the product backlog.
Meaning, if our product owner comes up with new ideas, hey, let's take vouchers.
Let's offer voucher on our e-commerce website.
That comes in as a new feature idea, new product backlog item, and the product back log is sorted putting vouches in where it belongs.
So change happens outside the sprint.
We lock the Sprint down, letting the team focus on what it is they're building that Sprints.
One last thing I want to toss in up here, me in the top middle, I'm going to talk in our daily standup.
Daily stand up, this is where the team gets together, 10 to 15 minutes a day.
It's limited, no more than 15 minute, and they talk about it.
To synchronization, it's not a status meeting.
Status meeting always sounds, well first it sounds boring, second it sound one directional.
I will give my status report to the project manager.
You won't listen while I give my report.
And then while you give your report, I won'l listen.
That's a status meeting.
This isn't a statistics meeting, this is a synchronization meeting This is team members talking to each other.
Here's what I'm doing.
What are you working on?
Anybody stuck?
We go through things like that, trying to keep the project on track.
So that's it.
There's nothing else to scrum but what's shown up here.
By the way, somebody asked me this morning why I was qualified to talk about Scrum.
I didn't want to start with my bio-slide or anything this mornin' because we're time-pressed, so I don't wanna bore you with background.
But somebody did ask why i was qualifed to talked about scrum.
So, here's why.
i have a scrumb tattoo.
l have that picture on the wall on me.
so if I'm tattooed with scrumm, I feel qualified talk it.
Those of you close enough can tell that is a fake scrum tattoo.
At the end of our session today, help yourself.
I got a bunch of scrumb tattoos up here.
So if you're at all bought into this, grab some scrumm tattoos on the way out.
And I don't want to fly them home to the US, so take as many of those as you want.
Oh, I hate going back to animated slides.
But I just want pause here in case there are any questions on that, because this is kind of the whole framework in cases brings up any any question anybody
has right now.
OK.
Let's get through our animation here.
I want to talk about sprints, these one to four week time boxes where the team is making progress on the project.
By far the most common is a two week iteration.
My recommendation here is to find a link that works for you and stick with it.
Do not bounce around.
Don't go two weeks, one week, four weeks.
Three, two, to two.
One, for two don't bounce.
Around find the link.
That works.
For you.
And stick.
With it A lot of factors influence our sprint length.
Sometimes it's things like how long our product owner or business can go without changing their minds.
All right?
Sometimes, it is how quickly we need to deliver things to the market.
So think about pick a length that works for you.
It's not a life sentence.
You can change it a few months from now.
If it isn't working for ya, change by all means.
But don't bounce.
Don't balance around.
That rhythm is beneficial.
I don't like four-week sprints.
That's our maximum.
Calendar month is our max.
We end on the 18th.
Very few people do that.
Some people will do a four week sprint.
Every four weeks, we start a new cycle.
I Don't Like Four-Week Sprints One of the reasons I dont like 4-week sprint is it leads to thinking like this.
Oh, We got 4 weeks.
Let's use the first week for analysis.
Design the second week.
Code the third week, and we'll test the fourth week And that's not what we want to do on a Scrum project.
On a Scrum project, what would like to is to have a little bit of everything happening all the time.
There should always be some design going on, always some coding going.
Now in different amounts, we're not going to be doing most of our coding the last day.
At least I hope not.
But we wanted to balance that out.
We're in the analysis phase of the sprint.
And when we go to a really short sprint cycle, teams figure that.
You've only got a week.
You're not going to have a day of analysis, a design, and a coding.
So teams will figure that out with the shorter sprint lengths.
Longer sprints tend to get tempting to introduce phases into our sprint.
It's not a good thing.
Talked about no changes.
No changes in a sprint.
This slide is just kind of repeating that.
What we're trying to do here is to create an environment where the team is allowed to focus.
I remember it was about two weeks ago.
Before I left on this trip, I'd left the office.
I went home, and I was still trying to get some writing done.
All right, books.
And so I still try to do some riding done at home.
But it was starting to close to dinner time, And I could hear my wife banging around in the kitchen.
Dinner's getting ready.
So I don't want to start on the new article I have due, because it's almost dinnertime.
Don't wanna get my head into the article.
and so i replied to some email.
Read a couple documents.
Okay, play a game too.
And dinner should be done by now.
It's only 45 minutes, you know, they're banging around.
My wife's a good cook, but it's not like she cooks things that take hours to cook.
So I was like, dinner's got to be ready by know.
And so I go ask her, what time are we eating?
And she said, oh, not for another hour.
Our daughters had longer dance practice or something, so they weren't going to home at the normal time.
What had happened here is I'd let all that time escape because I kind of feeling this, you know, constant, oh, I'm about to be interrupted for dinner,
and so I didn't get productive.
I just kind let that time slip away.
So we're trying to create an environment where the team does not feel like they're about be to interrupted.
You've got two weeks, so i will not change my mind on you.
Go build gift wrapping or vouchers or whatever it is we've chosen to do in that sprint.
We try to leave the teamwork alone, let them focus, create that environment for them.
The Scrum framework is made up of three things.
We've got roles, and we have three roles on a Scum project.
And we've ceremonies, activities that happen on our Sc rum project, And artifacts.
So what I'd like to do is to dive into these roles and ceremonies and artifacts Let's start with our three rolls.
The first role on the Scurm project is that of product owner.
Our product owner is our key business representative, kind of the key stakeholder.
This is the person who is often funding the project or who represents the users to us on the product.
Product owners are responsible for the Product Backlog, for making sure the Project Backload is in the right order.
product owners also responsible from making what I refer to as scope schedule trade-off decisions.
Scope schedule trade-off decisions.
Here's what I mean.
We're sitting here in early June.
And we're thinking about it.
Should we release in September with that much functionality?
We can have that by September.
Or we could have much by October.
September, October, September October And so our product owner makes that scope versus schedule of trade off decision.
When would be the right time to release?
Early with not as many features, later with more.
So they're the one who makes those type of decisions for us.
One of the nice things about Scrum We don't need to decide that today.
Some of us do.
But others of can wait until maybe August.
And in August we'll decide, OK, we're pulling the trigger in September.
It's going to be September release.
Or we might get to August and go, yeah, our competitor didn't release their product.
Let's skip September, We'll go to October, and we really have a bunch of features in there for our customers.
So often we don' have to make that decision now.
At the end of the sprint, the product owner is shown by the team what they built.
And the Product Owner accepts or rejects each of product backlog items.
The Product owner can look at it and say, I love what you did with return.
That's fantastic.
Vouchers, we got to go back.
We got make some changes to vouchers.
So the Project owner accepts and reject the work of team at the ends of each sprint.
Now, I often think of the team as a race car.
That makes sense.
The team's job is to go as fast as they can.
So the teams a racing car, the product owner is the driver of their racecar.
They're the one aiming the car at the right goal.
We have another role on a Scrum project called a scrum master.
You might have heard about this role.
It's got a weird name.
Scum Master.
Now we've got this scrumm master role, I think of the scrm master as the mechanic for the car.
The scrmm master's job is to have that car as tuned up, as ready to go as possible.
So the Scrum Master helps the team go as quickly as they can, but not necessarily in the right direction.
That's the Product Owner's job, to get the Team aimed in right directions.
So we have Product Owners, Scum Master, and Team.
Often the one who is supposed to know Scrum the best, they're the ones that helps the team use Scum to be successful.
They're one that might make decisions like how long our sprint should be.
When I first started hiring Scrum Masters, I started doing this in 1995. We didn't have the title Scum Master.
So I needed to hire people to effectively do this job.
I just called them project managers back then, but they were a very different type of project manager.
And I told them their job was to be bulldozer and shield.
Bulldozer and shield.
They were a bulldozier.
Any problem in the team's way, get it out of the way.
That's your job.
You're a shield, you're there to protect the Team from any sort of outside distraction.
Later we started to think about the metaphor of coach for Scrum Master.
So I also think of a Scum Master as a coach.
Somebody there helping the teams on to their best performance.
And we think a about a Coach on a sports team.
Scrum Masters are a coaches.
There to help the Teams be the best they can be.
The third role is team.
Team.
Only three roles we have on a Scrum project.
Product owner, Scum master, and team, typical team size five to nine people.
I hate putting a number up there, though.
If I have to do it, if I didn't, you would ask me that.
How big should a team be or can it be?
Five to 9. For me, that does include the product owner and Scumbaster.
Five the nine.
But I don't like putting the number here, I like instead how Amazon does it.
Amazon talks about their teams as being what they call a two pizza team.
A team they can feed with two pizzas is the right size.
And I like that as a way to think about our team size, by the way, if you're hiring, that's me and one small tester.
Some days, a very small tester.
So as silly as that is, I think it's the right way to think about our team sizes, right?
And I'm not picking on any food allergies.
I've got my own.
But if you have a big team, you're not going to remember what people can eat and don't eat or like to eat, things like that.
If you've an eight-person team you know how many pizzas to order.
And you remember you got two people who are vegetarian.
All right, if got a 23- person team How many vegetarians do we have again?
And is he still gluten-free?
I mean, it's too hard.
It's to hard, right?
So if ordering lunch for the team is hard the teams too big.
I think that's the Amazon lesson.
And 5 to 9 a real good sweet spot for our Scrum teams.
Scum teams are meant to be cross-functional.
They're meant have everybody we need to go from idea to implementation.
Everybody we need from idea to implementation, we can take a product backlog item and fully implement it.
Meaning that team will have programmers and testers, maybe database people, and maybe UI designers.
UI's not important though, at least that's what I heard this morning right now.
Some teams it is, some teams is not.
Now you're doing more of an API team or something.
But we're going to have everybody on that Team necessary to go from Idea to Implementation.
I'd like most of those individuals to be full time.
that I've got the word should up there.
I know in today's world, we're not always going to have everybody full time.
But the more we can do that, the better off we are going be.
Self-organizing, we touched on this.
We said there is no one person, no tech lead, who gets to assign out all the tasks.
And then the last one, I mean, barely worth touching on here.
Memberships should change between sprints.
It's just too confusing for teams if you're getting new team members in the middle of the sprint.
So we try to put any team member switches should happen at the spring boundaries.
So those are our three roles on a Scrum project.
Let's touch on the four ceremonies of Scum.
Four ceremonies.
We've got one called Sprint Planning.
One called sprint review, another one called a sprint retrospective, and then a daily Scrum.
So let's start with our planning meeting.
The other three meetings in Scum are very short.
Very short, this one long and painful.
This is going to be a few hours.
Some teams will take a whole day to do this if they have a long sprint, complex project perhaps.
Most teams have got this done in two to three hours, but some teams'll spend longer.
Everybody attends the team, the scrum master, their product, or the whole team is going to be there.
That's going be a consistent theme across all four of these meetings.
The agenda is for the teams to talk about the top of the product backlog.
Remember the Product Backlog, our Prioritized Features List.
We don't talk but the Whole Thing.
The whole product backlog, there may be stuff on there we're never going to do.
There may stuff further down in that prioritized list.
We're not going do for six months.
But we are going come together and talk about the top items.
What might we do this sprint?
What's a little bit beyond this?
Maybe we can get it in.
So the team will talk the about top of the product back log.
They select what to do.
That is a really important bullet point.
The team selects what do do, the product owner does not tell the team.
No, the team selects how much they can do.
Teams are empowered to select the amount they could do, now they should be motivated, they shouldn't go, we get to choose,
okay, you know we'll just do that much.
The team should do as much as they, but it's up to them, nobody gets to say you have to do eight items or you do one fourth of the backlog.
The reason why we do this meeting is to feel like that what we are going to do has been talked about in enough detail that we understand it well enough
to have a chance of succeeding with it.
We come out of this with two things.
I mentioned the sprint backlog.
Sprint backlogs can be a list of tasks.
Spring goal, just kind of a one-sentence summary.
It gives us a once-entence-summary we can use to describe to outsiders, your boss's boss wants to know what you're working on.
That becomes our sprint goal.
A one sentence summary of what we're doing.
The way this works is we come together, the whole team, product owner, scrum master, and team members, And the team looks at the top of the product backlog,
They read that backlog item and they say, OK, what do we have to do?
They create the list of tasks.
Most teams will estimate those tasks, so that's going to take six hours, that can take four hours.
Mostly breaking things down into the kind of four to 10 hour range, most tasks They commit to one item, they grab a second item.
They break it into tasks, estimate the hours.
Commit to it.
The grab 1 third.
And they keep breaking these things down.
Now this is called a sprint planning meeting, but I think the meeting is a little bit misnamed.
Because it's not just a planning meetings, it is also a design meeting.
the team is doing technical design in this meeting the Team is Doing Product Design in This Meeting.
See what I mean here.
We're in this meeting, and the team says, how should we handle this error?
What should do if the user types in that?
The product owner says wow, I'd want you to do this, we've got to make sure this doesn't happen.
That's product design.
It's also technical design, when the time is making their list of tasks, they're talking about things like, wow should this in the middle tier?
No, no, we got to do this in the UI.
It's got be more responsive than that.
Let's do in this the JavaScript.
And so this is a technical design, a product design and a planning meeting all three together.
One of the reasons it takes a long time.
That's also the reason I don't get too frustrated when it's taking a lot of time because it is us there designing the project.
Designing the feature at a high level at the technical and product level.
It's our sprint planning meeting.
Longest, only real painful meeting on Scrum.
The shortest meeting of Scum, the daily Sc rum.
Here is where we get together once a day.
for 15 minutes maximum, not guaranteed minimums, 15 is maximum.
And we talk about how things are going.
This is a chance for team members to synchronize their effort.
It is not a problem-solving meeting.
We're not there to solve issues, we're there just to discuss things.
Now it's very common for the team to hang around afterwards, maybe half the time, and solve a But we don't mandate that the whole team has to stay there
to solve some problem that came up.
We just kind of raise issues, discuss things.
All right.
All I came across is, so we're just a little bug yesterday, but I got it fixed.
I recommend everybody change this parameter to your JVM.
Something like that might get mentioned.
Others are like, I'm really stuck on this.
Can somebody pair with me for a half hour today?
I just need to talk it through with somebody to figure out what's going on.
So we talk through issues like in this meeting.
The meeting is...
meant to be for team members only.
All right, now we allow others to talk, but it's meant, or we'll allow other to attend, But it is meant only for the team to members talk during this meeting.
And you might be wondering why I got those weird chickens up on the screens.
Let me explain the weird chicken up there.
There's an old joke in the Scrum world.
You gotta know this old jokes if you're gonna be anywhere near Scum.
The old is this, there's a chicken and a pig walking down the street.
When the chicken decides, let's start a restaurant.
Let's start a restaurant.
What do you think, pig?
And the pig says, that is an intriguing idea.
I'm a very entrepreneurial type of hog.
And I am sick of working for the farmer.
Let us do it.
But the pigs says what are we going to call the business?
What are going call to the restaurant?
The chicken says let's call restaurant ham and eggs.
The pig said no thanks, I would be committed.
You would only be involved.
Not the funniest old joke.
Not the funniest old joke, but a very common joke in the scrum world.
And it is meant to point out the difference between that chicken who just lays an egg or two, and the pig who lays down his life to be part of the breakfast.
Now, nobody likes to call a chicken or a pig, so I'm gonna beg your permission to let me refer to people as chickens and pigs for the next 60 seconds or so.
Because here's the idea.
The idea is that team members are committed.
They're pigs.
Is a pig?
The Scrum Master is committed.
There's debate.
Sometimes there's a debate about the product owner.
Is the Product Owner committed?
Are they a Pig?
Or are they just involved, or are just a chicken?
Well, here's the answer.
The early days of Scum, the 90s, Product Owners were chickens, and we were happy to have that.
But the 1990s model of Product owner was somebody who showed up, said, Here's what I want, I'll see you in a month.
And they came back in the month and they told us if they liked it or not.
What we've learned is it's a much better model to have a committed product owner.
Somebody who is a full-on team member, somebody who's there not necessarily every day, but somebody is there at least mentally with the team during the process.
So, today's world of the product owners are pigs, they are committed team members, and they're allowed to talk in the daily scrum.
But, your CEO, I'm generalizing here, assuming your C.E.O.
is not also one of your best programmers, Your CEO shows up at the Daily Scrum.
We tell your CEO, ooh, sorry.
Please be quiet for a few minutes.
Will finish our meeting.
And then we'd love to hear any questions you've got for us.
But let us get around the room and do our Daily scrum first.
In going around, the we answer three questions.
Each team member answers three question.
What did you do yesterday?
What are you going to do today?
And is there anything in your way?
I touched earlier that these are not status reports.
These are team members sharing information with each other.
Let's look at the other two meetings.
We've got a sprint review and a Sprint Retrospective.
Similar meetings, very different in terms of what happens, but similar meetings in this sense.
is about inspecting and adapting on the product.
We look at the products, we inspect the project, and we adapt.
we make changes.
Customers aren't going to like this.
Oh, wow, customers love this new UI we've added on this part of the application.
Let's go do more of that.
So we expect and adapt on a product The retrospective, We inspect and adopt on that process.
We talk about how Scrum's working for us, and we make changes to the process.
So the review, we inspect and adapt on the product.
It is a demo.
The team demonstrates what they've built.
Now, this takes very different forms in different companies.
In some companies, were demonstrating to product owner.
And other cases, the project owner is demonstrating outside stakeholders.
Typically going to be up to an hour long meeting.
I don't want this to go much longer than that.
It's a hard one to predict because if you're doing longer sprints, you are doing stuff that's very UI intensive.
You can have a longer sprint review than a team that is building a commercial API into something.
Everybody's got an opinion on colors and user interfaces.
So those type of meetings will take longer.
So this is the review, we're getting feedback.
We're looking for things we should change.
In the retrospective, were looking things for we change in the process.
Were talking about how is Scrum working for us?
And we might decide Scum's fantastic, but not those four week sprints.
Let's go down to two week sprint.
Nah, I think three week is better.
Lets go to three weeks, let's start with that.
Or I thinks Scums doing okay for but our product backlog items aren't detailed enough.
We're coming into the sprint with just something that says cancel an order.
That's not enough detail.
We need a little more detail before we start.
Let's find a way to add detail to our product backlog items.
Or maybe the other way around, we've got too much detail in our backlog.
So in a retrospective, were looking at ways to improve the process.
My favorite way The retrospective is just in what we call a start-stop-continue meeting.
We have the team come together and say, what should we start doing?
What should stop doing, and what shall we continue?
So not very touchy-feely here.
I don't really care.
Ooh, how do we feel?
No, no.
What are we going to change?
We're very action-oriented.
What are we going to start doing?
What we're going stop doing.
So we are focused on things very directly actionable that we can change in the sprint.
Lots of other ways to do a sprint retrospective.
This is just my preferred way to this.
Let's look at our artifacts.
Product backlog.
The product backlog, I mentioned this earlier, is the requirements list on a project.
It's prioritized by somebody called our product owner.
And the idea with the product backlog is that each item in a product back, I always kind of think of it as an Excel spreadsheet when we bring one up.
Each item and the project backlog should be valuable to our users or customers.
Each item should be valuable to our users or customers.
Now, if you've heard of something called user stories, a couple of these are in the form of a user story.
Probably the second, third, and fourth I would say qualify as essentially user's stories.
User stories are short, simple statements told from the perspective of the user.
As a traveler, I want to be able to book a room in this hotel.
As a traveler, I want to be able to specify the type of bed in my hotel room, something like that.
These are short, simple statements that a user might have for our system, in that case, the travel system.
In this case I'm showing a product backlog along with an estimate.
Next artifact is something called a sprint goal.
Sprint goal, just a short summary of what we're trying to do in that sprint.
One or two sentences.
And again, this is where I said earlier, This might be for your boss's boss.
You park, you get in the elevator, You push the nine button, and your bosses boss gets in, And your Boss's Boss says, What are you working on this sprint?
Well, your boss doesn't want to hear your whole sprint backlog.
Oh, I got to code this.
I've got design this, oh, we got a UI review on this and they don't hear that.
They don' even want hear all of the product backlog items.
they want a short one or two sentence summary.
Something like this Well this sprint we're working on basic shopping cart functionality.
Things like add review and update quantities.
A couple weeks later, bad timing, you get in the elevator with the boss's boss again.
And the bosses boss wants to know what you're working on now.
Well, he got another sprint goal.
You say, well, this time we're workin' on the checkout process.
Things like paying for an order, picking, shipping methods, things like that.
So it's a short one or two sentence summary that we can use for outsiders, outsiders of the sprint.
Next artifact.
Oh, I actually want to stick with managing the backlog here for a minute because I want show you a sample one.
The sprint backlog is always meant to be an up-to-date reflection of what we have to do.
meaning it's never complete.
We're going to do a sprint planning meeting, and we're gonna write the sprint backlog.
But we are not going think of everything.
In fact, I don't even want you to think everything, but I want to you think fairly hard, come up with all this easy stuff you can.
Don't stay in there forever thinking harder and harder, making that meeting longer than it needs to be.
Do a good job, think the stuff that you and then let the Sprint Backlog evolve.
New tasks will show up, you'll re-estimate things.
That's harder than I thought, that's good because this one is easier than thought.
So anybody can add to the sprint backlog once the sprints starts.
Any team member who discovers something.
So the key point here is that work emerges.
This whole idea of emergence is a very common thing with Scrum.
The product backlog emerges, we don't have the whole thing.
the Sprint Backlog emerges we, don' have everything identified on there.
So here's a sample sprint backlog.
We walk out of the sprint planning meeting.
Let's say we're doing one this morning.
You'll notice that coding the user interface, about half done.
Took that down from eight hours to four hours.
Middle tier went from 16 hours, to 12 hours We finished up the online help system.
Our tech writer had a good day yesterday.
Tech writer didn't work 12-hours, but did get to cross out a 12 hour task.
Had a real good productive day, and our techwriter finished that whole task Wednesday, watch what's going to happen on Wednesday.
Especially the bottom there, I added a task This is where we discovered a new task.
I forgot error logging.
We didn't think about that during the planning meeting, so we added it on Wednesday.
The other thing to notice there on wednesday is look at the top row.
Coding the user interface got harder.
I worked on it all day yesterday and it went backwards.
It's going to be harder than I thought.
Back to eight hours.
So the idea here is that the sprint backlog just represents our best guess at any point in time of what we have to do and how hard it's gonna be to that thing.
And then Thursday and Friday.
Sprint backlog looking something like this.
Another artifact out of the scrum process is something called a burndown chart.
This here is a sprint burn-down chart.
This is real one.
It's a team outside of San Francisco, California.
And you can see up there in the top left, the very first point is around 780 hours.
These guys were doing a 20-day sprint.
Those are dates on the bottom.
I should have changed those to be more European-style dates.
Just didn't think about it.
Wasn't looking at it The first day of that sprint, they had 790 hours of work.
The second day, They had more work They had a productive day.
They worked all day on Monday.
But when they added things up on Tuesday, they had noticed two things.
New tasks.
Things like error logging on that earlier screen.
Oops, new task.
And tasks they have identified got bigger.
So those two thing conspired the first couple days to send their backlog up.
Look in there at about 16, 17 days into the sprint, you'll see a big drop.
The dropped 200 hours.
Now that's a good day!
Well, except they dropped the 200 hours, they didn't actually make 200-hours of progress.
They dropped a product backlog item out of the sprint.
That moved them a whole lot closer to their goal.
So with the Sprint Backlog, all we get to see here, the sprint burndown chart, is how far the team is from the goal?
I don't know if that was a good or a bad thing, we just see where it is.
And they made progress there, but not in a great way.
Here's a sample of making a sprint burndown chart.
We add up the work.
Get a new dot, we put that dot on the chart.
The next day we add up the work there.
Put a dot new on a burn down chart, so each day, day by day were putting these new dots onto the burn-down chart this is something I would expect Scrum
Masters to be doing the Scum Master will do this in a minute or so a day.
A lot of tools will this do in an automated manner.
Not a big fan of the tools, they get in the way for other reasons but a tool does make this part of Scram a whole lot easier.
But hopefully adding numbers up isn't the hardest part in doing Scrom.
That'd be nice if it was.
Scrum Scales.
I've worked on a 560 person Scum Team.
And I've consulted two, three, 1,000 person Scrum projects the first time I said that, I say team.
No one is on a 560 person scrum team, right?
Imagine 5 60 people standing around in a circle trying to get a daily Scum done in 15 minutes.
All right, the point with that is that Scums scales up by having teams of teams, all right.
We don't get one big team we have teams teams.
So we're still going to keep our Scrumb teams in that seven to nine range, maybe a little bit bigger, Don't go too big.
Remember, we're going to cut the pizza slices too thin.
But maybe a little bit bigger when you have a 500 person project.
You're gonna have 10, 11 person teams more than the six person team just because of the hassle factor of having that many teams.
So a number of things will influence how we scale this up.
One of key things in scaling up is a meeting.
If you've heard about Scrum, you might have heard of this meeting, It's got a very catchy name.
I don't think this meeting is as important as its name is catchy.
So here's the meeting.
The idea is to do what is called a scrum of scrums meeting, picture each of those blocks of team members down there doing a daily scrump,
the little 15 minute meeting right now.
Imagine this is something like Microsoft office.
This makes Microsoft Word.
So I've got three teams working on Word, but you know what?
Word is one product.
I want to have one person from each of the Word teams come together and talk about overall Word issues.
All right, so we got 3 teams on working Word but let's pick one from those Word team, have them get together maybe twice a week,
and have another meeting.
We'll call it a Scrum of Scum of Scrums.
A third level would be a scrum of scrums.
And these are coordination meetings that we use to coordinate across the multiple teams on a larger project.
This is just one of the things we do to scale ScrumUp.
I think a more important thing we to do scale ScrumUp is this.
We call this a community of practice.
What I'm showing here are just our three Scrum teams.
What want to do is I want have conversation cut across our Scum teams, face it, I need the programmers talking to each other.
So we set up this thing called a community of practice, which is a group of like-minded or like skilled individuals.
And so I went to programmers, talking each to other, this might just be a shared discussion list, a little shared email list.
Maybe it's a share email in a monthly meeting.
Maybe it's a weekly lunch that the testers have.
The DBAs, our UI designers, are scrum masters as well.
the point here is to have ways to communication cut across our scrumm teams.
These communities of practice help us do that.
I'm not going to focus too much on this, just here's a list of books that are on Scrum in a significant way.
I've got a book on estimating and planning Scum projects.
We've had sessions on that later today.
Clinton Keith has a great book, on agile game development with Sc rum.
This is actually the best book to go into all the technical practices.
So if you're a programmer, tester, really looking to understand Scrom, let me skip testers for a second.
If you are a program, you really want to learn Scram and the practical practices, real good book.
I know Esther Derby is here tomorrow.
Agile testing.
This is why I said skip testers for a moment.
Here's the right book for testors.
Agile Testing by Lisa Crispin.
Coaching Agiles Teams by Elisa Adkins.
This is a book on all the soft skills for Scrum Masters.
All the ways to coach your team to the best performance they can.
Essential Scum is coming out next month.
Succeeding with Agile is my book.
Don't buy that book first.
That's kind of a second book on Scrum.
It goes into all the specifics.
Not a good starting point, but a great second on Scrum.
And then User Stories, I don't know if they have that out there, they might, is about the product backlog.
As I mentioned earlier, this presentation is totally available for you.
It's up there in PowerPoint in Keynote format.
Please take it, make it your own, use it to convert your companies, your friends, user groups, whatever you want.
Um, it's been translated into 23 languages, so go ahead and grab the, uh, kanji version and impress your boss with your,
you know, multilingual skills.
Flash up the Romanian version, just go, whoops, I was working on my Romanian over the weekend.
This is up there on my website, which is mountaingoatsoftware.com.
You'll find presentations up here, including this one in that format, plus a ton of other presentations.
They just asked that I put this in here.
I've got classes coming up on Scrum here three and six months from now.
And there's my contact information.
I'm around all day today.
So I am fair game any time for other questions.
And I've got a lot of other sessions on Agile.
Hopefully this one kind of piqued your interest.
Again, grab some Scrum tattoos because I don't want to have to fly them home to the U.S.
Any questions before we wrap up?
Get you guys on your way to next session a few minutes early.
One is based on the product backlog.
I know you have a separate session on it, but my understanding of it is more higher level user stories.
But let's say you had bigger tasks, such as if it's an existing software, so you need to do some major refactoring or not visible.
Right.
First question is how do you get those into the project backlog?
Okay.
If you have a small team and you also have running soft system so you get all this immediate bug fixes and all these things that will affect the team,
how can you best...
OK, two real good questions.
So the first question is, what do we do about stuff that's not really kind of new feature oriented in the product backlog?
Refactoring, cleaning things up, things like installing a new version of Windows or new Linux servers, all that type of stuff.
The product back log is meant to represent anything we need to do to get out a successful product.
Those type things do go on to the project backlog as well.
I think if we went back to the example product backlog I had up there, I'll just flash back there while I'm talking, the sample product back log I have
up here had at the bottom of it an item that said to improve exception handling, a purely technical thing, this would be some sort of refactoring thing.
We could change that into a user story that was user focused if want.
As a users I'd like errors handled in a more appropriate manner so I don't see a bunch of Java jumped on top of the screen or something like that.
So I do think those type of things are totally appropriate on a product backlog.
Sometimes we do have an issue with the product owner, having to convince them that those are worthwhile things.
Some teams will get around that by somewhat agreeing with their product.
Look, we're just going to keep a certain amount of our time for ourselves, for technical cleanup things, other times I'll meet teams that'll say,
We have a hard time convincing our product to allow us time refactoring.
All right, so here's my advice on how to get your product owner to allow you time for refactoring if they're not letting you do that.
Go to your project owner and make the same arguments about refractoring that you made when you convinced your products owner that need time to compile
your code.
probably didn't have that discussion, did you, right?
It's just part of doing a good job.
I have to compile, assuming I'm a compiled language, I gotta compile my code, so that's not the product owner's business.
That's me doing good a job, me writing good code is just me doin' a god job my product doner doesn't get to tell me about that.
Now when I something that gonna put me out of commission for three weeks while I refactor a huge chunk, okay, now we gotta have a conversation.
But all those little things that are just about doin a God job that I not gonna going to have a discussion with.
In terms of how do we get a team to protect the team's time if they're working on a new version or a big new set of features,
and they are also doing support on the current version that's out there, here's how I think about this.
I'll grab my water bottle here.
The first thing that you pour into the sprint is corporate overhead.
It takes a certain amount of time to be a good employee here, So I got a pouring corporate overhead.
The next thing is planable time.
That's how much time the team has that's their own.
Then I have unplanned time, unplan time goes to tasks I don't identify, tasks that get bigger than I thought, now both of those are kind of my fault,
but they also go to interruptions, servers down, Mike, please go fix it.
So I have to leave some room for plan of unplanned time up here.
Now let's hypothesize two teams here, one team is two people in a garage making their first iPad game.
Not a lot of corporate overhead, right?
Corporate overhead for them is, hey, you order the pizza today, all right.
Lot of planable time, not a lots of interruptions.
So they have a lotta time that's their own.
Now, hypothesize another company in a big bureaucracy doing second level tech support on their shipping product.
They have lot less time it's there own So when they go to plan their sprint, they will have less time available.
When we think about things like, and I think we've got one coming up here shortly, when we thing about thing like their burndown chart,
what I'm saying here is they would not start up as high vertically.
They wouldn't have as many hours at the start on that first day.
So, okay.
Thank you guys very much.

Daily Scrum Explained: A Better Way to Run It

Transcript

You're probably doing your daily scrums wrong.
If you're asking each team member to give an update on their progress, plans, and problems, there is a better way.
Hi, I'm Mike Cohn, the author of three best-selling books on Agile and Scrum.
I help teams succeed with Agil.
And I want to help you too.
Today I am going to tell you how to get team members more engaged in their daily scrums, how to learn more about each other's work,
and how more easily to notice if a product backlog item is going off the rails and needs attention.
Most daily scrums are conducted person by person, often still with the three traditional but no longer required questions of the daily Scrum.
What they did yesterday, what they'll do today, or what if anything is in the way.
After each person gives their update, the next person give their full update.
This is a very natural way to do a meeting.
One by one each says what they have to say.
A problem with this approach is that each speaks only once.
After I give my update I'm done.
I may not say anything else the entire rest of the meeting, In fact, a rule of no problem solving during the daily scrum encourages me to remain silent
after giving my update.
There's no rule that says you have to do it this way.
For most teams, I found a better approach is to go backlog item by backlog.
The scrumm master, or whoever is facilitating the meeting, calls out a first product backlog and asks who worked on this item yesterday.
Anyone who did states what they did yesterday, The facilitator then says, great, and who will work on it today?
Anyone who plans to work in that item today shares what they plan to accomplish.
Finally, the scrum master or facilitators asks, is anything holding anyone back on this item?
Team members answer, then the facilitater repeats this process on the next product backlog item.
I want to highlight a couple of benefits to this approach.
First, team members are likely to talk more than once.
Suppose I'm heavily involved in one product backlog item, but also doing a few little things on a second item.
I will talk twice during the meeting as each item is discussed.
In the traditional person-by-person approach, I would give the same update, But I do it all at once Second, it's much easier to understand which backlog
items are being worked on.
Imagine a team that has brought 10 items into their sprint.
The team should be working on perhaps two to four of those at any time.
If you run the meeting item by item and team members give updates on all 10 item in the sprint, that's a problem.
It's too much work in process.
Doing the meeting item by item makes this much more obvious than if you do the meaning person by person.
Third, it's easier to gauge what work will be completed in the sprint.
If three or four people each give an update on a given item, that item will probably be finished in this sprint, or at least the team is trying to finish it.
On the other hand, if no one mentions a particular item and you're nearing the end of the Sprint, you can start to think that one item won't be finish.
Fourth, the number of people who talk about any item indicates the degree to which team members are collaborating.
If only one team member comments on each item, there isn't a lot of collaboration occurring.
This can help the Scrum Master notice a problem sooner.
I think doing daily Scrum meetings person by person is a legacy of the old status meetings many team members will have participated in during their pre-Agile days.
In those meetings, a manager would ask each person to provide an update.
And so when teams move to Agile, they start by doing Daily Scums the same way.
It's a natural way to do the meeting.
And it can be very efficient.
Each person can provide their complete update all at once.
So for some teams, going person by person may be best.
But in my experience, a lot of teams benefit from going item by item.
I suggest mixing it up.
Do this sprint item-by-item, then next sprint person- by-person.
See how it goes.
You might find one approach is best for you.
Or you might find it's good to keep Daily Scrums fresh by changing the approach now and then.
How do you conduct Daily Scrums?
Is it one of these approaches?
Let me know in the comments how you do Daily scrums and what you think is best.
I read and appreciate every comment.
Also, if this video has been useful, click the like button.
And if you're new to this channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agile.

The Daily Scrum: It's Not a Status Meeting for the Scrum Master

Transcript

It's not a status meeting, it's a synchronization meeting.
The daily scrum is designed for team members to synchronize their effort.
You don't want two designers working on the same screen without each knowing about it.
Similarly, someone better be working a critical task if the sprint ends tomorrow.
But if a meeting is for the team to members synchronized their work with one another, what does the scrumm master do?
Should the Scrum Master even attend?
Hi, I'm Mike Cohn, and I am the author of three best-selling books on Agile and Scrum.
I help teams succeed with Agil, And I want to help you too.
Yes, i do think the Scum Master should attend.
i know the scrum guide says they should only attend if working on Sprint backlog items, but all the best teams I've worked with have had Scumm Masters
who attended their daily scrums.
The meeting is not, however, for the Scrum Master.
That's why it's not a status meeting.
If it were a Status Meeting, we'd see the scrum master call on each person, probably ask about their progress plans and problems,
and take notes so they could follow up the next day to be sure everything got done.
Wait, we do see that happen a lot.
Those scrummasters need to let go and let their teams conduct their own daily scrums.
The meeting is for the team.
Let them decide how to run it.
Sure, if the Team is new to Scrum, a good scrummaster will coach the teams on how run an effective daily Scum.
They'll coach them to avoid problem solving, to keep updates brief, focus on what was accomplished rather than on everything they spent time on,
and so on.
As the team learns how to conduct its own meeting, the Scrum Master can and should fade out of leading the meeting.
But why then do I want the scrum master to participate?
Because it's the best place to hear about impediments.
In daily scrums, developers are expected to communicate anything slowing them down.
Scum Masters will be expected help resolve those impediment.
So, scrumm masters should be there to here about them.
Also, participating in daily scrums shows a scrum master's support for the team.
I prefer that over a Scrum Master with the attitude of being too busy to participate in something the rest of the teams expected to do.
A good Scum Master will remember, though, that the daily Sc rum exists for team members to share their progress and synchronize effort.
Do your daily Scrum meetings feel like a team synchronizing their effort?
Or do they feel more like status meetings conducted for the benefit of the Scum Master?
Please let me know in the comments.
And if this video has been useful, click the like button.
If you're new to the channel, subscribe so you don't miss out on future tips to help you succeed with Agile.

Help! My Team Hates the Retrospective!

Transcript

I've learned not to go to the market when I'm hungry.
If I do, I buy too much.
When hungry, everything looks too tasty, and I'd buy more than I can possibly eat.
Agile teams often behave similarly in retrospectives, especially when beginning their agile journeys.
During a retrospective, team members identify so many promising opportunities for improvement that they decide to tackle every one of them.
These teams would be far better off improving at one, two, or maybe three items.
If team member's attempt to improve at more than that, their efforts will be too diffused.
On the other hand, and as much as I like focus, I don't want to go so far as to say a team needs to select a single improvement opportunity.
Many improvements a Team may attempt do not require time from every Team member every Sprint.
For example, the team may agree to focus on writing more and better automated unit tests.
Since unit test are generally written by the programmers on a team, this fantastic improvement won't require the attention of everyone on the Team.
That will leave room for a second improvement idea, especially if it's one that requires minimal effort from those already focused on their first.
Additionally, some improvements are worth keeping in mind for multiple sprints.
Writing better unit tests is again a good example.
Suppose the team achieves its goal of doing this.
That's great, but it doesn't mean the teams will do it again in the next sprint.
Some improvements take time to become ingrained as habits.
Writing better unit tests could then be something a team wants to retain focus on for multiple sprints.
I coach teams to maintain a continuous in their retrospectives.
The continuous contains items the team has improved at, but that aren't quite habits yet.
So writing better units tests, could be placed on the continuous after one or a few sprint, just to keep it visible a bit longer as a goal.
Once team members feel that writing better unit tests has become a habit they won't forget, it can be removed from the Continuous.
You don't want the continuous to bulge with items from long ago.
So pick one to three new improvement ideas.
The fewer the better, but up to 3 can also be okay.
Supplement this with a short list of things team member are continuing to improve at that aren't yet habits and so warrant a bit of visibility on a continuous.
By the way, I'm Mike Cohn.
I am a co-founder of the Scrum Alliance and Agile Alliance.
So that I may better help you, please consider leaving a comment about how your team is doing with its retrospectives.
How many items does the team pick to improve at?
Do they usually succeed at improving multiple things at the same time?
And since one of my own improvement goals is always to make videos you find helpful, let me know in the comments if there are topics you'd like me to cover.
If this video has been useful, click the Like button.
And if you're new to the channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching and I'll see you next time.

Leading a Self-Organizing Team

Transcript

Thank you for being here.
We're going to talk about leading a self-organizing team, trying to dispel the myth that project managers, scrum masters,
and such with self organizing teams do nothing more than buy pizza and get out of the way.
There's definitely more to do on a Self-Organizing Team.
My name is Mike Cohn.
Hope to get a chance to talking with you more through the rest of NDC.
Here's our agenda, we're gonna talk about self-organization and something called subtle control.
We're going to talk something about called containers, differences, and exchanges, how those can be used to influence self organization.
And then we'll talk influencing how the team evolves.
Teams are not static things that stay in one place, they evolve.
So we will talk how to how influence that evolution.
Let's start out with what self organisation is.
In my mind, self organisation is a response to a challenge.
Someone external to the team throws a challenge out to them and they respond to that challenge.
Self-organization does not mean that the teams get to pick that.
They don't choose the goal they're going to pursue.
The team is given that goal.
A question posed to a list of scrum trainers a little bit ago that kind of bothered me because most of the scrumm trainers got it wrong.
The question was, does a product owner have the right to tell a team what the product needs and when?
And over half the scrum trainers who responded said no.
The product owner, that chief stakeholder, gets to tell the team one of the three things, what I want, when I wanted, how much it's going to cost,
something like that.
They don't get to specify multiple things.
So a product owners does not get say, I need this, by that date.
And that answer was wrong.
A product on a Scrum team or a key stakeholder on an Agile project does get the tell team more than that, I don't have any doubt about this.
I know this, because one of the very first Scrum projects ever was a project done at Fuji Xerox in the early 80s.
And this project, the product owner on the project went to the team and said, I need a new photocopier.
Fuji made photocoopiers.
Said, i need to new photo copier that works at today's state of art, sells for half the price of current model, and is available in two years.
And the article on this describes the team as kind of grumbling and moaning about this, saying, can't be done.
No way, no way.
And then eventually, they said, what if we tried this?
What if did this.
Yeah, yeah, if you did that, that would work.
We've used this new toner that's coming out.
Oh no, now that won't work, OK, but what we did with this And article talks about it and says, at that point, the product owner essentially had won.
The team had come to own the problem.
So self-organization is a response to a problem, right?
We self-organized already today.
You guys have already self organized at least once.
One thing you did is you self organizing into this room.
Our host here at NDC set up a challenge for you, where to sit.
And we had to self organize.
They could have done it differently.
It would have been nice if they'd given us kind of round tables, but then they can't fit as many people in here.
But that would've been a different self organization challenge.
The gave us a little bit of a weird challenge that they've got these nice seats in the middle but no screen.
So we have to optimize on whether you wanted to look at me or whether you want to look at the slides.
So we had a self-organization problem.
Not much of a problem, but we did have one this morning.
Self-Organization, a response to a challenge.
Managers, product owners, scrum masters, leaders in the organization help influence, determine what that challenge is going to be.
Now when we think about a team, teams are absolutely what are called a complex adaptive system, or CAS, a Complex Adaptive System.
And if we look at a definition for a Complex Adaptative System, it's a dynamic network of many agents.
acting in parallel and acting and reacting to each other.
Hopefully, that sounds like a typical team.
If we think about a seven-person team, it's a dynamic network of agents.
They're acting, reacting, to one another.
On a complex adaptive system, control is dispersed and decentralized.
We don't have all decisions being made by the one big brain.
All right, that type of decision making is dispersed.
So when we look at some examples of complex adaptive systems, we'd see some of these.
We'd things like ant hives and bee colonies.
Actually, I got those the other way around.
Ant colonies and beehives.
Right, would look those.
I think of Complex Adaptive Systems, something like a group queuing up to go into a concert or a theater.
Remember I was at a Jimmy Buffett concert last year.
Some of you probably know Jimmy Buffett, Margaritaville Singer.
And there were two distinct clumps of people.
There were some of us who were lined up to get in to good seats.
It was all open seating.
So some us were line up in good seating, the others were aligned up at the tequila bar.
Complex adaptive system, right?
And it was just kind of a structuring of ourselves.
No organization to it other than what you preferred.
Teams are definitely complex adaptive systems, especially agile teams, where we have very little high-level leadership.
The team is given a challenge.
They don't have a hierarchy of leaders.
Now, when we a project like this, one of the things I want to think about is that control, exerting control or influence over such a group is not evil.
Right?
Control is not evil.
Our hosts at NDC today, I do not think they were evil by putting the chairs in here this way.
They thought about how many people they had signed up, they thought the room, the best way, and they structured the tables in the chair in best combination
of ways.
If only 18 people signed up for NDC, we might have had big comfy recliners and tables, round tables.
But they look at it and they did their best to influence us in a good way.
So exerting influence or control over a group is not an evil thing.
When I get on the highway and drive, I have to stay on a particular side of the road.
I don't find that evil.
I find it somewhat helpful for keeping alive.
So control is not bad.
We often kind of rebel against it, and we think it is, but it's not.
It's okay to have rules and incentives added by managers, leaders, product owners.
project managers, whatever you want to think about.
It's okay for these individuals to add influence onto us in the rules or such that they place.
We do have to be careful as leaders in an organization that we don't go too far.
Now, sometimes I feel a little bit alone in this thinking, so I want to share a couple of thoughts to show that I'm not alone with this thing.
This is a great book called The Biology of Business.
It's a collection of essays, one of the essays by a guy named Philip Anderson.
Here's what he had to say.
He said, self-organization does not mean that workers, instead of managers, engineer an organization design.
it does NOT mean letting people do whatever they want do.
Says instead it means that management commits to guiding the evolution of behaviors.
Think about that, evolution behaviors that emerges from interaction of independent agents instead of specifying in advance what effective behavior is.
So management here somewhat leaves the team to figure out what affective behavior.
They set up the goals and they leave the teams to find out the best way to achieve those goals.
Let me look at one other quote, actually two other quotes here.
This next one I want to share with you is from the very first article on Scrum.
First article in Scum, one of the leading Agile processes, about 70% of people doing Agiles do Sc rum.
Here's a quote from their very article article that, and the authors here wrote, although project teams are largely on their own,
they are not uncontrolled.
Said management establishes enough checkpoints to prevent instability, ambiguity, intention from turning into chaos.
Ken Schwaber, who's kind of the godfather of Scrum, has talked about Scum as being kind the act of controlling chaos, right?
You're just on the edge of crossing over and do chaotic activity.
So at the same time, management avoids the kind rigid control that impairs creativity and spontaneity.
We want to have just enough control, that we don't go into either direction.
we dont get too rigid, too much control.
It's from an early Agile book, book in 1990. They wrote, to be sure, control is still exercised, but it is subtle and much of it indirect.
So agile teams, self-organizing teams are still under control.
They're under influence.
But it's subtle and indirect.
It's not us forcing them to do things.
You must do this.
I say this, you have to this this So it subtle an indirect control, subtle, and direct influence So what we're not talking about here is being deceptive
or sneaky.
This thing is driving me crazy.
Its staying on one ear and not on the other.
So we're not talking about being deceptive or misleading to the team.
We're talking not about lying to them.
It was no lie to you that our host from NDC set the chairs up in here, right?
We know they did it for our benefit.
So the control that we are going to exert is maybe not something that were going too to broadcast.
But we aren't going necessarily to hide from a team that some of it may be going on.
That all sounds philosophical.
Here's what I mean about this.
I may have a team that I do not think is working well together, and I put another person on that team because they bring a different decision-making style
to that.
I think that's going to help the team.
If the other team comes to me and says, hey, why did you put this other person?
I don't necessarily want to tell them, oh, because I like your decision-making style, and they have a different one.
Because that's going to undermine the impact that person is going have.
So I may not broadcast why all of the interventions I take with the team are there.
Oh, I'm putting them there to change your You will not.
That'll just reinforce their behavior, and they'll fight me on that.
So I may not broadcast why I do those things, but I don't feel like I'm being sneaky or deceptive.
And what I mean by that is three years later, they come to me and say, hey, why'd you put that person on our team?
Oh, you had a different decision-making style than I thought was helpful.
You guys were very quick to decide.
I wanted to add somebody who was a little bit more deliberate in their decision making style, so I added whoever to your team.
I'll be happy to tell them a couple years later.
But I'm not just going to broadcast it.
If I broadcast, it's going kind of defeat the purpose, in some cases.
So I am not talking about being sneaky or deceptive here.
I don't ever want to feel like I've lied to my team or sneaking around behind their backs.
And doing things, I intervene with the team for their own good.
but I may not broadcast the reasons in advance.
We'll talk about this idea of containers, differences, and exchanges.
The idea here is that for self-organization to occur, there are three things that are necessary.
The three thing that is necessary are a container, some differences, and some exchanges.
These ideas here are based on the PhD research and other writings from a woman named Glenda E.
Young.
who studied self-organization.
And so she says that we need to have a container.
Now, a contain can be lots of different things.
A container can a physical boundary.
Our room today is a containers.
The container could be more of a conceptual boundary, the project that were on.
Container can be semi-physical.
It can the campus we're on.
We are in the Oslo campus of our company, right?
There's also a part of the company in Beijing.
So it might be physical, it may be more just kind of conceptual.
I am part the American team.
Right?
I'm working in Oslow, but I one of Americans.
That might a different container that we are on, so any person will maybe in a handful or more containers on a project.
But there has to be something that bounds us.
Think about me telling you about people going to the Jimmy Buffett concert.
They go to this music concert, right?
They had to in the same physical place.
That was their container for self-organization to occur.
We have to have in this room for a self organization.
There's got to something we have that bound us together.
The next thing that we need, we needed differences.
If we were all the How we organized, how we self-organized wouldn't really matter.
So we have to have some differences amongst us.
Now, any time we're talking about humans, that's fairly pretty much a given we are going to differences.
The differences can come in all sorts of ways.
They can be technical differences, can mean knowledge differences knowledge of the technology, knowledge the domain, it could be the experience,
could our gender, our power in the organization, educational level, years of experience.
Our network within the organization, all those types of things will differ.
As humans, we're going to have plenty of differences, but we need those in order for self-organization to occur.
We also need what she called transforming exchanges.
A transforming exchange is where one or more of these agents, in our case humans generally, I don't mean that as a joke.
Sometimes the agents can be groups.
The QA department talks to the programming department.
So when agents talk, there have to be transforming exchanges.
I go talk to my chief architect, and my Chief Architect tells me a good way to design a solution.
That was a transforming exchange.
That was a transforming exchange, a good one.
So any sort of exchange here where something is going to influence what you do next, knowledge, information, motivation,
I go talk to my product owner and my project owner tells me about an amazing site visit she just had with a client.
I leave motivated.
I'm excited about this project, I cannot wait for this to get out in people's hands.
So that's a transforming exchange.
Containers, differences, exchanges.
Three things that influence how we self-organize.
Now if those things influence we can use them.
We can us them to influence a team self organizes.
And we're going to want to use these in good ways.
So one of the things that we can do is we an introduce or remove containers.
We can enlarge a container, shrink a We can influence the differences.
And I gave an example of where I was introducing a difference on a team.
I said I had a particular decision-making style.
When I give the example, they rushed to decide.
All right, I have some teams that I work with who rushed decide, that don't talk about things, in my opinion, thoroughly enough.
They're very quick to decided.
So I might want to slow that down.
Introduce a different on that team by bringing somebody onto that teams who makes decisions in a diffrent way.
A little bit more deliberate, maybe too deliberate.
Maybe that's the right balance.
So I'm introducing a difference there.
An exchange.
I may introduce, have people talk to each other.
who aren't talking today.
I introduce a new exchange into the team, right?
And introducing that new change, that team may self-organize a slightly different way.
Notice I use the word may there.
What we're talking about here is intervening with the teams.
Intervene with a team.
Introduce a container or ask for a change to occur.
I'm intervening with the team.
I do not know how that will result.
Right, I put a new intervention in with a team, but I don't know if they will respond.
For example, if I may ask a person to start pair programming, and I've done that a lot, then I have a pretty good idea of how a pair will react to pair programing.
But I really don' know what this person will do.
They may respond in a predictable way, they may not.
So we have to take a series of educated guesses as we make these interventions with our team We're trying to help a team get better and better in terms
of how they self-organize.
We are not doing this just for our fun, we are trying help the team be better.
But any one intervention I'm taking a little bit of an educated guess as to how that team will respond to my intervention.
I am going to do an exercise here shortly where I will ask you to think about how you might intervene with a few teams.
Before I do that, I want to show a couple more things that we can do as part of these containers, differences and exchanges.
So here we go.
With containers, I can enlarge or shrink the team.
I could make the teams bigger or smaller.
This team is not working well together, let's make it a little bit smaller, all right?
Let's let the six-person team figure out how to work together.
Then I'll add two people back, the eight people not getting along, it's not workin' out.
Maybe I need to make the team bigger.
Maybe it's a seven-person team, I want to add two people.
So changing the size of the teams will, of course, change how they work together.
I can shrink the responsibility boundaries.
Here's real example.
And their definition of done included handed off to the sysadmin group.
The siss admin group would deploy the software.
And they were giving the softwares to sss admins in a state that was not very deployable.
Right, the system administrators had too much work figuring out how to actually deploy this.
It was too manual, it was very hard for the systems administrators to do.
across a couple of thousand servers.
So we expanded the scope of responsibility for that team.
I told them their job was not to just hand it to the system administrators, their jobs was to get it deployed with the System Administrators help.
And so I increased the scale of their responsibilities, not just have it ready to be deployed, but actually deployed.
Changed how they self-organized.
They now had a larger scope for responsibility.
Change team membership, maybe not even changing size.
Just take one person out, add another person.
That will certainly change how we self-organize.
Create new teams or groups, introduce a new group, split a team into two, things like that will be examples of changing our containers.
Let's look at changing differences, some of the things we can do here.
Talk to a team and have them, encourage them or ask them to make their decisions a different way.
Some teams feel like they have to have consensus on every decision.
We all have Maybe that works out great for some teams, maybe not for others.
So with a team that is struggling with this, Maybe I can encourage them to use a different decision-making style.
Look, do we really have to agree on everything?
Maybe we can just do a typical kind of thumbs up, thumbs down, thumb's neutral type of thing.
As long as nobody is saying thumbs-down, we'll go with his decision.
There's other techniques called things like fists of five and things this.
Maybe, I could go to an approach where we don't quite require consensus.
Getting some sort of discussion going there in a different way.
I'm a big fan of having a fierce debate about things.
Let's come, have a first debate, figure it out, and then we'll agree, we will move on.
Not everybody on the team may have to support that.
Maybe I have another team who is doing the opposite and I want to push them to have consensus.
Do not make a decision unless everyone of you agree.
One of the things I probably spend half my life doing when I'm consulting is asking questions.
What could go wrong if we chose this?
What other three decisions did we rule out?
Why is this decision better than that one?
what was your second best decision?
So I will ask a lot of questions like that.
Early in my career, when I was learning how to be a manager, I actually wanted to become proficient at asking these types of question.
What I started to do, is go into meetings, and I would actually track on my fingers how many times I made a statement versus how may times i asked a question,
Making sure I asked more questions than I made statements in those meetings.
So asking hard questions of a team will bring out whether they agree or disagree.
Now it won't stay on either ear.
One of the things that you can do is to try to bring the differences among team members by asking those hard question.
Last one, our exchanges.
We need transforming exchanges Here's something I did that a lot of people would think was very non-agile.
And those of you who know me know I'm very agile.
I kind of live and breathe to help agile teams.
Here is something that I do that people accuse me of having done that was non agile I had a Scrum team and I told them that I wanted all of their key architectural
decisions to be reviewed by an architect who was not really over their team.
He was just kind of architect in the company, senior guy in company but he wasn't like responsible for their teams.
And I said I want all your decisions run by Todd.
I want you to take all of your decisions to him and make sure he approves of all your big architectural decisions.
Then I went over to Todd and I talked to them and explained what I was doing.
I said, I'm going to have this team run all their architectural decision by you.
And I'd like you look out for them making big mistakes, but mostly I wanted you be here as somebody scary.
I want this team to have to worry about, uh oh, we have go present this to Todd.
And that would make them think through their decisions more thoroughly.
They would be more prepared, they wouldn't rush to decide, and they would more thorough, which is something I wanted out of this time.
I told Todd, I said I don't really want you to overrule them very often.
Of course do so if you think they're about to make a big mistake.
But I say the biggest thing I just want to do is ask them some of those hard questions.
Intimidate them.
Make sure they come to you prepared.
But if they're giving you good answers and you can tell they've thought about it, that's probably good enough.
So here I was, I kind of slowed this team down.
A non-agile thing to do.
I made them go get approval on their big architectural decisions.
But I did it for their good, to get better results out of what they were doing.
So I would still support what I do there, even though it may look like a non agile thing.
It was an exchange that I introduced.
Introduced a new exchange into this.
Sometimes you can look at this and say, who's talking that shouldn't be?
Who do we have not talking?
And we can introduce new exchanges into the mix.
What I'd like to do is do a little exercise here where you get a chance to intervene with some teams.
Oh my god, this thing is going to kill me.
Here's what I'd like you to do.
Here is an example.
So suppose you are a scrum master or coach for an agile team.
The next couple slides, these are what are on the handout.
They describe some teams that are having some troubles.
What I would like to you do, I'll let you self-organize into a couple of groups, those next to, and discuss these problems.
We'll do the first one here together, then I will let pick one or two to each talk about.
I want you figure out how you would intervene with this team and whether that intervention is a change in container, difference,
or exchange.
So here's an example.
Let's talk about number one here.
We've got a team that has four programmers, two testers, database engineer, and you.
The programmers and testors are not working well together.
Programmers work in isolation until two days are left in the iteration.
Then they throw the code over the wall to the testters.
Anybody have an idea of what you might change here and whether that's a change in container, difference, or exchange?
What might you change, here?
I'm sure some people have been in this situation.
Yes?
OK, so get the programmers and testers integrated better.
Change the container.
One way we might do that, maybe they're not sitting close enough to each other.
Maybe I need to set programmer, tester, programmer tester like a dinner party or something.
Get them more integrated in their container that way.
Other thoughts on things we may do?
Yes, thank you.
What would that be, a change in container, difference or exchange?
The container, yeah.
Yeah, when we change the responsibilities, it changes the container.
So now the programmers are not responsible for write good code, they're responsible to write high quality code.
Esther?
Well, first, I want to know more about what's going on.
Of course.
But the example that was just given in changing the responsibility is also dampening the difference.
It's saying you don't have these distinct roles between I am a tester and you're a developer.
That's an excellent point.
Thank you.
All of these, we're going to want to know more information.
We're just going have to make some guesses with half a page of information on these things.
But you're absolutely right.
Very often, if not always, when we change one of the things, there will be ancillary effects.
I change the container, I have an influence, as Esther pointed out, on terms of the differences here.
I'm no longer a programmer and tester, but I am a team member when we make that type of change.
So, when you go through these, think about which one you think is primarily is.
One of things you can think of is if you see something that is, okay, it's primarily a container but also see the impact on differences and exchanges,
Sometimes we can look at that, and that tells us, to some extent, the magnitude of the impact there.
If you're changing something that sounds pretty much like one of these, maybe only a minor intervention.
You're doing something if you make a change that's going to impact all three, much more likely a stronger intervention, you have to decide.
Are you trying to make strong intervention or are you just trying make minor interventions with your team?
So here's what I'd like you to do.
Let's take, I don't know, six, seven minutes, or maybe 10 minutes.
I'll look at our timing here.
But form up into some groups, just a couple of you next to each other, and talk about one, maybe two of the other situations on there.
We'll get back together in a few minutes and share these and see if we can have some answers for at least one or two more of these others.
So talk with us for a minute in your groups.
Got it figured out?
Working together there.
OK.
Let's start up again, see how we do here.
I know we're all shy, but let's see if we can at least talk about one or two of these.
Do we have a group that will volunteer to tell me what possible interventions you came up with for one of this problems?
We have group who will help us out in one our discussions.
Thank you.
Which one did you guys talk Number two, this is failing to deliver potentially shippable code.
What might you do there?
One suggestion would be to have the product owner sit closer to the developers.
OK.
So they would know better if the feature is actually done.
Have the project owner set closer the team?
What do you think we're changing there, is that primarily a container, difference, or exchange?
Well, it's a Container Analytics change.
Yeah.
Yeah, so we're changing the container.
We're bringing the product owner closer in with the team.
Or introducing a new exchange.
Were having the project owner talking with a team more frequently.
All right.
So we've got some new exchanges going on there.
Right.
What about another one?
Anybody talk about three, four, five or six?
Let's get one more.
Get another comment or two.
I appreciate your comments on that one.
Thank you.
One more?
Yes.
Number five, oh yeah, yeah.
OK, so introduce something like planning poker is a different way to estimate.
Planning poker's a consensus-based approach to estimating.
Everybody holds up a card all at once.
Some people will be talking about, I think, in the next section I'm doing after lunch.
So we might do that to help avoid the influence that Jeff is having by being so domineering.
This is actually a real one I worked with.
That is one of the things we did there.
Thank you for that.
And again, a lot of these The way I use this is a lot of times when I'm consulting to companies, I've seen a problem before,
and I go, OK, what did I do before?
And I remember what I might have done with a previous company, did it work, does this situation seem similar, now I know what to do.
So I'll use it that way.
But if I don't know to what do, if i'm seeing something that I haven't seen, or I am trying to think through possible solutions,
thinking through the containers, differences, exchanges that exist in that company I find helpful as a thinking tool.
OK, what containers are here?
What containers could I change?
Who's talking that, who's not talking maybe should be?
what exchanges could i introduce?
And so I'll think about it that way.
So sometimes I use this as a thinking tool with some of the teams I work with when I try to find interventions, way to influence them.
I want to shift and talk about kind of the second main topic here, which is how to influence how a team evolves.
So teams have what's called a self-organizing path.
The way a time is self organized today is different than how they are going to be self organize tomorrow when a teams moves along this path,
right?
Self organization is not something you can put on a Gantt chart.
right inside okay we're done self-organizing check that off right it constantly happens a team self organizes constantly so we have to be aware of of directing
the team guiding the teen to better and better levels of fitness with their environment Self-organization proceeds from the premise that effective organization
is evolved, not designed.
It aims to create an environment in which successful divisions of labor and routines not only emerge, but also self-adjust.
in response to environmental changes.
So we adjust to our environment.
He says this happens because management sets up an environment and encourages rapid evolution toward a higher fitness, not because manager has mastered
the art of planning and monitoring workflows.
Again, management's job, leadership's, job is to set up and environment where this can happen, where the team is able to rapidly evolve,
rapidly adjust, to their environment, we don't pre-plan it.
So team evolution, if we think about evolution.
Evolution is a result of three things.
Variation, selection, and retention.
And let's not think of a team first.
Let's think something easier like a giraffe.
A giraffe has a random mutation that leads to a longer neck.
That is variation.
We randomly varied, right?
Selection means that that random variation actually turned out to be a good thing.
That giraffe could survive where others couldn't.
Retention is where evolution has that giraffe species continue to have that long neck.
The mutation is passed along to descendants.
So for evolution to occur, we need variation.
We're going to need changes to happen.
And we're gonna have to have a way to select among those.
and we have the best to be retained.
Variation, selection, and retention.
Anderson, in one of his articles, wrote about seven levers for influencing.
How a team evolves and so I want to touch on some of these these levers here The first one is select the external environment Things that you can do to
influence how a team evolves is you could adjust their external environment.
This is very similar in some ways to the containers we had of the earlier discussion.
That's more than just the physical environment, sometimes we can adjust the business we're in or the definition of business were in.
I remember the first time I went to work with Yahoo, this was back in 2003 or 2004. Yahoo.
Think about how you think of Yahoo?
I think about how you would define Yahoo, and I go out there 2003 2004 and they tell me we're a media company like a Media company right and you know they
were they, were in the process of gradually moving headquarters and all key employees down to southern california They're,
gonna be in hollywood all right we are a, media, company, we create media for the web You're not a.
Media you're you, know kind of second rate search engine at this point, right?
You're a technology company.
And I think this is part of what Yahoo has struggled with over the last eight, nine years, figuring out their identity.
But they went for years where they had this CEO who said, we're media company, and so we can think about the external environment.
Now, a lot of us cannot influence that, but I want to just touch on this one in case some of this can.
Some of our companies are innovators.
Others are fast followers.
What type of influence do we have on how we view our company?
Second thing that we can do, and hopefully more of us have influence over this, is define what is good performance.
What is acceptable, what good is performance in your company, right?
What messages do you send if you cancel training?
Anytime there's a crisis, we cancel the training.
Think about the type message that sends.
It sends a message we value the short term over the long term.
I had a boss, many of us have had boss like this.
This boss thrived on chaos, and he loved it when employees rose to the occasion during chaos and put out fires, even if they were the ones who caused the fires.
And so we've often had bosses like that who love that firefighting capability.
So that just encourages employees to create fires so they can be the one to put them out.
So what do you define, what to you as a leader define as good performance?
What are you rewarding as performance, right?
The things that we reward, the things we praise and talk about in the company, those will be the thing that teams move towards.
So I wanna make sure teams are moving in their right direction.
Manage meaning, What becomes meaningful in your organization, all right.
What type of stories are told in a company?
What type of stories get passed around?
Those stories, again, influence what people value and what they respond to.
I live in Boulder, Colorado.
I got invited into a, what to me would have been a fantastic client.
They're about five miles from my house, they're a medium sized division of a very large company, and we're going to be an absolutely fantastic clients.
And I go there and I'm spending the entire day giving them some advice and they are kind of interviewing me to see if they want me hang around for the
long term, do a long-term engagement with them.
Man do they have problems.
This is going to be a great client to have.
And I get to the end of the day and I've heard about this new general manager they've got, and the guy sounds, yeah, I'm not real wild about the stuff
I heard.
But I got to end the of day, but I already decided I don't want to work with these guys because it's going be hopeless.
I won't be able to help them.
I get to this, I'm supposed to have a meeting at four o'clock with the general manager and I go meet with human resources director because the GM is too
busy to meet me, he's going to be late and the human resource guy is just kind of babysitting me for a little while and he starts telling me stories about
this general manage and how great he is and one of the reasons he so great is because he goes out in the parking lot at five o clock every day,
typical US quitting time and counts the cars.
And he wants to, this human resource guy is trying to impress me because this GM counts the cars and isn't that great?
He's making people work late by counting the cards.
And I just wanted to kind of shock the guy and I said, oh, that's fantastic.
He goes out there at five o'clock and he counts their cars.
Then what does he do?
Come in and find anybody who's working too late and sends them home?
And this human resource guy, no, he wants him here late.
What type of culture is this setting up when you know your boss is out counting the cars at 5 o'clock?
It's a horrible thing.
I had another company I worked at.
where we actually had a story that was getting passed around that I thought was fantastic.
The company was a small company that public and was finally going to be profitable.
Maybe.
Maybe they were going to make a profit this quarter.
It depended if we could keep costs in check.
As long as we kept costs down, this company was going make money.
And it was gonna be real close.
The company's either gonna make little bit or lose a little.
But that first quarter in which you cross over and you're now profitable is huge.
right and whether we make a thousand dollars or lose a $1000 that is a huge difference and it is it's going to be really close and so we have this all
company meeting and the CEO stands up in front of the the whole company and is stressing the importance of keeping cost down Right?
Don't buy office supplies.
You can buy them three weeks from now if you need them.
Do not buy off of supplies, don't book any business travel.
We're trying to be profitable.
And then here's the key part of what he told us.
He said, while this meeting is going on, I have the janitors going to every bathroom in our building.
They are taking out the nice, comfortable two-ply toilet paper and removing it and putting in cheaper one- ply toiletpaper.
I'm sure this cost him more money than it saved by going to cheaper toilet paper.
But I remember him saying, he said, that I want everybody in here thinking about profitability at least one time a day.
Really interesting message, but he got his point across.
And the company did achieve their profitability.
So what becomes meaningful in your company?
What type of stories get passed around?
Another thing we can do to help evolve Pick people.
Now we're back a little bit into the container difference exchange thing, talking about some of the people involved.
So think about who we want on the team.
give you one other story about somebody put on a team one time i had a teen that was uh...
uh they were doing too well and i put a person on the team of the program on that team who's not one of a better programmers i don't know what it was about
this guy's name was mark uh but he was like blue i considered him like glue he would he wouldn't keep the teen together and had to know if fighting they've
been put together to an acquisition and this uh this one per mark he just had great personality he with the one that uh that people were always going over
to his house after work and on the weekends and things like that.
I looked back on teams that he had been on, I'd worked with this company for a handful of years, and nobody ever left when Mark was on that team.
He just had a personality that kept people together, just a real friendly guy.
So I put him on a team and he said, what is my job on this team?
I said basically to be the glue, i want you to keep this theme together.
We have this thing that's coming together from an acquisition, they hate each other.
And you're just such a nice guy.
People always get along with you.
And your job is to help make sure this team stays together through the rest of this project.
So we think about who we're putting together on a team.
One of the questions we often get is, should a team have the right to decide who's on them?
I'm okay with teams deciding, with companies deciding to give that power to a theme, but it's not something I normally do.
I normal do not let teams have to right decide, who are team members.
Much more of a fan of keeping this as part of management's responsibilities, because this is one of primary ways that leadership in an organization gets
to influence self organization.
So, I'm not a big fan of abdicating that, giving that to teams, but I have done that on teams that I would put pretty far up the maturity level.
A couple other things that we can do to influence self-organization.
Reconfigure the network refers to having different paths of communication, different types of conversation occurring, and to introduce or remove flows.
I want to show an example of what I'm thinking about here.
Imagine you have a team in two locations.
You have a team here, and you have team back home where I live in Denver.
So half your team in Oslo, half of your time in denver.
A very common way to structure that team would be as shown here.
We would have, a, team, in, Denver, we would, have the team and Oslow and they would just coordinate their work.
But they, would essentially separate teams.
Now, there's some danger to that.
There's a little bit of possibility of us and them mentality creeping in here.
So there is some dangerous here, so another possible way of constructing that team, assuming we have the right skill sets in each city,
would be to do this.
We'd have what we call a deliberately distributed team.
Have half the team here in Denver, another team that's half here half in denver.
so have two teams that are equally distributed.
So I know our common reaction is to look at this and say, I'll do the top one.
I have an intact team in Oslo, an in-tact team Denver.
But sometimes that leads to problems.
And sometimes the way to get around that problem is do do bottom picture here.
So we reconfigure the network.
We have different paths of communication.
All right?
I tend to think of this a little bit this way.
If we do that top Not a lot of day-to-day hassle.
I don't got to get on the phone at a weird time of the day.
Not lot a hassle on that top one, but a big risk of a blow up.
We can have some us versus them problems.
we can some miscommunication.
Of course, we do design by contract, But the two teams go in different directions.
And then they find out they've gone later.
They find that they have gone in a different direction and things aren't working.
So very little day to day hassle, big chance of later problems The bottom picture, a lot of day-to-day hassle, but not a big chance of any long-term problems.
So I kind of think of that bottom one as a little bit like an insurance policy.
I can do that.
Bottom one, I'm going to be paying insurance premiums every day, every time I get on the phone at a weird time.
And paying little insurance to keep us in the right direction.
But I don't have the big blow up.
I'm not advocating either one.
I am not saying one is better than the other.
As much as I look at that top one and think by default that's how it will structure teams, I often do it the bottom way for various reasons on a given team.
So we can reconfigure the network in a slightly different way.
Another thing we can do to influence our evolutionary path is to create what are called vicarious selection systems.
Now, think about it this way.
Imagine you're thinking about Agile, you are thinking of doing some Scrum, but you also think of Kanban, and you've also got some people in your company
who love waterfall.
Here's the best way to resolve that dispute.
Have a bunch of teams use Waterfall, have a BUNCH of Teams use Scrum, Have them develop products for the next few years,
and at the end of let's say a 5 year period, let us figure out which of those sub companies made more money.
That's a very lengthy process to figure that out, a lengthy and a expensive experiment.
So we don't want to do an experiment like that, it's too expensive.
What we want is to set up vicarious, alternative selection systems.
Alternative selection system are ones that can help us find out what ideas are good ones.
One of the best examples of a vicaerious selection is Google.
You've probably heard that Google has their 20% policy.
Every employee at Google gets to spend 20 percent of their time on whatever project or initiative they want.
Now imagine you're a Google manager or Google VP and you see a lot of your developers flocking to work on a particular project.
That's a pretty good indicator that project is going to be successful.
People want this.
My programmers and testers want to work on this, people want work to on projects that will be successfully.
And that they would use themselves.
Google's audiences, a lot of it is their own people.
They're representative of their audience.
So when they see people flocking to those type of projects, that is an indicator of that might be a good idea.
So what type of things can we set up in our companies to be vicarious selection systems?
Retrospectives can help with this.
Seems we'll start to identify the problem sooner.
Last one I want to touch on here is energize the system, pump energy into the systems.
It is amazing when you visit a team that is energized how much more they are getting done than a time that it is not energized about their process.
So one of the things we want do is to make sure a teen has a clear elevating goal.
I had a reference to a book called Teamwork, I think down there at the bottom.
Another reference here is to make sure a team has an igniting purpose.
This comes from a Book by Wenda Gratton at London Business School.
And a Team with an Igniting Purpose will outperform a Teams that doesn't.
So part of our jobs as leaders is help teams find what ignites their passion.
Now, this doesn't always think of something like this.
I always thing of somebody like Steve Jobs, you know, giving great keynote talks and getting his Apple employees so motivated.
It doesn' have to be somebody as passionate and inspiring as Steve jobs.
As an example, let's take somebody who's nowhere near as inspiring Steve job.
Let's think about somebody A very successful business guy, but I don't think of him as giving the same kind of impassioned speeches as Steve Jobs would do.
Now let's flashback.
1993, Bill Gates says, we're not interested in the internet.
A little bit later, he realizes they need to be interested in the internet.
And you probably have heard about a memo that he sent out.
It wasn't even an email.
A memo he circulated around Microsoft in 1995, it was called the Internet Tidal Wave Memo, where he got all of Microsoft riled up about the web.
Okay, this might have been Bill Gates' shining moment.
Here was his big passionate speech.
The internet is a tidal wave, it changes the rules.
It's an incredible opportunity as well as an incredibly challenge.
I'm looking forward to your input on how we can improve our strategy.
is not very inspiring.
Doesn't exactly say a whole lot.
Any CEO I've worked with or worked for could have written that same memo.
But that was the one that got Microsoft turned around and focused on the internet.
So it doesn't have to be some amazing speech by a guy in a black turtleneck.
It can just be something that gets us all excited about whatever it is.
I don't consider this to be a particularly fiery memo, but this turned Microsoft around on the spot.
So seven things we can do there to influence how a team moves through their evolutionary self-organizing path.
Thank you all very much.

5 Ways to Improve Your Scrum Team (Without Culture Change)

Transcript

If you've worked on a Scrum team for any length of time, you probably heard or maybe said things like, We could be so much better if only leadership understood Agile.
Or, we'd get more done if the culture here was different.
And you're not wrong.
It's true that culture matters.
But it's also true if you wait for the organization to change before improving how your team works, you might be waiting a long time.
Now, what I'm about to share isn't a fix for every problem your teams might face.
Think of it as a set of simple, practical shifts you can try right away.
The benefit is they don't require buy-in from leadership or months of effort.
They're small levers your team can pull now, and they can start making a noticeable difference quickly.
In over 20 years of working with Scrum teams, I've seen significant gains happen inside the team's own bubble through actions they control without needing permission.
Here are five practical ways you can get started.
Power up your retrospectives.
Retrospectives can easily drift into management should territory, especially when the wider organization isn't fully on board with Scrum.
The problem is, when you do that, you give up you agency before you've even tested what's possible.
A simple shift is to focus only on actions the team can take themselves.
One team I worked with kept a running list of past action items in a shared document, and they reviewed it at the start of every retro.
Seeing those completed items reminded them that change was possible and already happening.
Something you can try is ending each retro with just one improvement the team commits to finishing before the next sprint review.
And make it visible so everyone can see the problem you want to solve or improvement you wanna make and that you're working as a team to make happen.
A team without a shared, inspiring purpose is really just a work group.
When you've got a purpose that's both motivational and actionable, it pulls people together and sharpens every improvement effort.
My next tip is to make sure you and your team have that shared purpose and vision.
That purpose can take different forms.
For example, one company I worked with served expectant mothers and their parents.
Their vision, your parenting partner, aligned every team around helping women achieve healthier, less stressful pregnancies.
It was short, memorable, and drove decisions across the organization.
Another team I coached working in bioinformatics rallied around the question, what if all medical treatment could be personalized to a patient's DNA?
That question fueled creativity and kept them focused on breakthrough possibilities.
And sometimes the purpose is a challenge.
A SaaS product team set a goal to double activation rates in three months.
Bold enough to inspire, yet concrete enough, to guide backlog priorities.
Their energy spread across departments, amplifying results.
a practical step in this situation is to work with your product owner to frame a sprint or release goal as a Challenge the whole team wants to win.
Here's a trap I see all the time.
Teams debate endlessly about the right way to do scrum.
Instead of theorizing, agree to test a new approach for two sprints before deciding.
My grandmother used to say, take two bites before you decide you don't like something.
The same applies here.
One sprint often feels too different to judge it fairly.
I saw this when a team tried two week sprints after a year or two of four week sprint.
The first sprint felt chaotic.
the second was smoother and that's when they could really decide and they chose to keep two weeks sprint.
An easy way to put this into action is to hold off on debating changes after the first print.
Wait until the 2nd and then decide.
When one person, often a scrum master or tech lead, assigns all the tasks, it sends an unspoken signal, decisions come from above.
That kills ownership, and it makes it harder for people to believe they can influence how the work gets done.
I worked with a team where all work was allocated by the tech lead on day one.
By day seven, priorities had shifted, but the plan stayed fixed.
Bottlenecks piled up, people were idle, and frustration grew.
When that team moved to self-selection of work, it flowed faster.
And something more important happened.
The team began making process tweaks on their own.
Instead of what's left on your list, a question you could start asking in daily scrums is, what should we tackle next?
That tiny shift keeps the focus on the team's sprint goal.
Scrum's no changes in a sprint rule is there to protect the sprint goal, but real life brings urgent requests.
The answer isn't to pretend interruptions will never happen, it's to plan for them.
Maria, a scrum master I worked with, negotiated a small buffer with stakeholders each sprint.
That made buffer use visible, sometimes just a simple progress bar.
that visibility kept conversations factual and prevented scope creep.
One simple experiment you could run here is to size your buffer based on past interruptions and make its usage visible so everyone understands the trade-offs.
Even if the wider organization isn't living and breathing agile, your team can create a pocket of high-trust collaboration and continuous improvement.
One team I worked with created their own vision, swarmed on work to meet sprinkles, and kept a transparent, well-maintained backlog.
They couldn't change the company overnight, but their results got noticed and other teams asked how they did it.
When teams perform in this way over time, stakeholders tend to notice.
Other teams may follow your example, and culture change can begin from the inside out.
These kinds of improvements can put your team on a really strong path.
And if you want to take things even further, making sure everyone is aligned around the same version of Scrum, we can help.
Working on Scum Team is a live online course designed to help good teams become even better.
Instead of sending one role at a time to separate training, teammates can train together so everyone hears the same message,
practices the the exercises, and leaves with a unified approach you can apply the very next sprint.
You'll leave this class with shared agreed upon definition of roles, responsibilities, done.
hands-on experience in planning, estimating, and refining backlogs.
A common language for tackling challenges without finger pointing or stalling.
You don't need to wait for a company-wide agile transformation to get stronger as a team.
you can start right where you are with the people you work with every day.
If you want to take a good Scrum team and make it great, aligned, confident, ready to deliver, this course will help you get there.
Check out the link in the description to learn more.

How to Run Effective Sprint Reviews and Unlock Game-Changing Feedback

Transcript

During the iteration review, the team demonstrates what they built.
But an iteration is more than just a demo.
In this video, let's look at a good agenda for effective iteration reviews.
First, welcome everyone to the meeting and share any rules or guidelines for it.
For example, it may be necessary to remind people to be polite and that it's fair to criticize the implementation of a feature,
but not to insult those who built it Participants can say a feature is unnecessary or worthless, but should not say that was a stupid decision.
In other cases, you may want to ask participants to refrain from sharing their opinions on a future until that feature has been fully demonstrated.
The second step in the agenda is to say what will and will not be demonstrated.
An Agile team does not need to demonstrate everything it did during the iteration.
The goal of an iteration review is collect feedback.
If no feedback is needed on something, save everyone some time and don't show that thing.
I like to prepare a list of all the product backlog items that were brought into an iteration.
For each item, I'll show its estimate, whether or not it will be demonstrated, and a brief comment on its status.
It's smart to email this list to everyone the afternoon before the iteration review.
Participants can then use it to decide whether they should attend.
The third item in the agenda is to demo the new functionality.
This is the heart of the iteration review, and it may be the only part of agenda you're currently doing.
During this portion of review proceed down the list of items from the prior step.
Keep in mind that the purpose of this review is solicit feedback.
There's no hard rule about who gives the demo.
I prefer to have team members demonstrate items they've worked on.
This gives multiple people a chance to demo and show off their work during one iteration review.
However, if you anticipate a difficult review or harsh critiques, consider having the product owner demo those features.
Experiment to find the plan that works best for your team.
The fourth item on the agenda is to discuss any problems or opportunities that arose during the iteration.
If stakeholders were slow to respond to emails during iteration, now is the time to inform them how this affected the team.
if a team member was out sick for a week and that might affect the overall delivery, discuss that.
Next, the product owner should share which items are currently at the top of the Product Backlog.
Unless things change, these will be the items the team works on immediately.
If stakeholders believe anything they saw during their review affects priorities, this is their chance to convince the project owner to make a change.
Or if the team has completed more or less than anticipated, this is the time to discuss adjusting plans for an upcoming release.
I generally caution product owners against making any immediate prioritization decisions based on stakeholder feedback during the review.
There are reasons for this for many.
The product owner may need time think about what was said in the reviews, or the product donor may want to get estimates from the teams about changes that
were requested, and so on.
Instead of making choices then and there, the product owner solicits opinions during the iteration review and then decides on priorities after the meeting.
As a final step, thank everyone for participating.
Consider thanking the entire team for the work of the Iteration.
consider occasionally praising a team member or two who performed exceptionally well during ITERATION.
Remind everyone when and where the next review will be held.
After the meeting is over, be sure someone adds any new items to the product backlog.

2 Big Reasons Why Sustainable Pace Is So Important to Agile Teams

Transcript

Overtime is the first refuge of bad management.
When teams get behind, as they often do, even with Agile, managers search their bag of tricks for a solution.
All too often, the solution they pick is that solution that was used on them before they became managers.
Obertime.
It didn't work then, and it won't now.
Hi, I'm Mike Cohn and I am the author of three bestselling books on Agil and Scrum.
I help teams succeed with agile and want to help you too.
When a team falls behind schedule, there are many things besides overtime that a manager could try.
They could add people to the team, they could drop a few requirements, that is not drop them but do a simpler version of some.
Managers could extend the deadline.
Why then do managers so often reach for overtime as the solution?
Because it's easy.
Buy team members some pizza and Red Bull, sit back and watch the problem evaporate.
Well, maybe.
Other solutions are harder to enact.
You normally can't add people as quickly as you can buy a pizza.
Dropping requirements takes stakeholder participation.
By the time they agree, the project is either further behind, out of time, or both.
By contrast, asking or worse, telling a team to work overtime is easy and it sometimes works for a short while.
Kent Beck, inventor of the extreme programming agile methodology, has a great approach to overtime.
He says, overtime, is a symptom of a serious problem on the project.
The XP rule is simple.
You can't work a second week of overtime For one week, fine, crank and put in some extra hours.
If you come in on Monday and say, to meet our goals, we'll have to work late again, then you already have a problem that can't be solved by working more
hours One of my clients had to learn this lesson the hard way.
With a major deadline four weeks away, the CTO mandated overtime from everyone on the project.
And for the first week, it worked.
Velocity across all teams was up 22% over the average.
With results like that, he kept the mandatory overtime going.
The second week didn't go as well.
But velocity across all teams on the project was still up 2%. That's better than it would have been without overtime, but not by much.
people were starting to burn out, and in weeks three and four, velocity was down by 16 and 20 percent below the average without overtime.
During this four-week period, the teams actually delivered less with overtime than they would have if they'd worked at a consistent,
sustainable pace.
Even better would've been just one week of overtime to get that little extra surge of progress without burning people out.
There's nothing wrong with an occasional week-long surge of overtime when truly necessary.
In fact, a friend of mine claims that periods like that have been his favorite over his 30-plus years in the software industry.
He loves the team camaraderie and the trust that gets built when everyone comes together to achieve something.
I can't argue with him.
The problem is when overtime becomes the first tool managers reach for, and they see it as the solution to every problem.
Overtime leads to stress, which leads Here's a comparison of four successive projects undertaken at the same company.
Each project was adding functionality to the product, so the complexity is reasonably consistent across all four projects.
The red bars show the number of hours each project is estimated to take.
The blue bars show the number of hours of overtime worked on each project.
Projects 1, 2, and 4 had significant overtime, ranging from 22% on project 1 to 40% project 2. The yellow dots indicate how many defects were found in
each projects.
Look at the numbers of defects in the projects with overtime and compare those to the amount of defect in project 3, which had no overtime.
Overtime stress defects.
It's a predictable cycle many of us have seen time and time again.
An agile team seeks to break the cycle by working at a sustainable pace.
This is where a scrum's term sprint gets in the way.
Sounds like we're supposed to be burned out after a sprint.
We're not.
A bonus of working at a sustainable pace is that a team can choose to surge with up to a week of overtime if they want.
It can help.
And sometimes there are reasons to do it.
Your investors need a demo next week that will determine if the invest more money in the company or the companies will be fined if not in compliance with
a new law ASAP.
Is your team working overtime?
Let me know in the comments how it's going for them.
And if your has broken the overtime habit, use the comment section to let us know how.
I read and appreciate every comment.
This video is part of a series on how to work as an agile team.
Be sure to check out the rest of the videos by clicking the onscreen links.
Don't forget to click the Like button.
And if you're new to this channel, click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching, and I'll see you next time, unless you are working overtime.

User Stories

Learn how to write, refine, split, and map user stories that help agile teams understand customer needs and deliver valuable outcomes.

User Stories Explained: What They Are, How to Write Them, and Why They Work

Transcript

Let's talk about user stories.
User stories are here as a requirements technique on projects.
Generally, agile projects, but I think user stores work well even on traditional projects so we don't have to just do this on agile.
Use your stories here to help with a requirement challenge.
In a software project, those who want some software Need to communicate with those who are going to build the software.
And in that communication, there are a couple of problems.
A couple things that can go wrong.
Want to touch on these things, that need to be in place.
The first is that the balance of power has to exist.
I don't want to have a situation where the business is dominant.
or the development team is dominant.
There has to be a balance of power between the business and the developments side.
If either side is dominate, we end up with some problems.
if the Business is all powerful, they walk into the developers and say things like, I need this, i need it by this date,
make it so.
Now that may sound fun if we're the business, we might think that sounds fun, but here among friends we can say that's clearly not the right way to get
the best product built.
It's not going to be good to walk in and say, make it so, I need this, so.
So we don't want to necessarily be in a position where the businesses gets to dictate everything.
On the other hand, sometimes we see organizations where the developers are dominant.
In those situations, what we say is the developer is replacing the language of the business with their own.
We make the businesses speak our language.
Will build whatever you want, but you have to fill out this complicated use case template.
Fill this out and that will tell us what to build for you.
If you don't fill this, out we won't build you the right thing.
So when we do that, when, we force the business to speak technology's language, We lose the opportunity to hear from them in their own words,
because they're having to translate things into our templates and our language.
And so we lose an opportunity hear, from the, business.
so the first thing that can go wrong is this balance.
Second challenge or second thing that can go wrong is the question of resource allocation.
Resource allocation has to be a shared problem.
Businesses often, perhaps even almost always, want more than they can get in a given time.
I need this.
I can't give you all that by September.
Businesses often want more than we can give them.
This is a resource challenge.
How can we best use our resources to give the best amount?
Well, I want there to be a balance here as well.
Resource allocation, the shortage of scarce resources, cannot entirely be the development team's problem.
It can't be entirely the business's problem either.
We need some balance here.
If we make the development team entirely responsible for solving the problem of scarce resources, the developers will often make bad trade-off decisions.
Our programmers may look at something and think, well, OK, negative data is never going to get here.
I don't need to code defensively.
Negative data can't possibly make it to this part of the code.
And then, of course, we know negative date does get there.
Now, I don't know that that's a bad decision.
It might have been an OK decision, but the point is it shouldn't have a decision that the programmer makes on their own.
That should be more or less a combination, a joint decision programmers shouldn get to decide where we take shortcuts.
Similarly, if we make the problem entirely the businesses, We see a different set of problems.
If we make the problem of scarce resource entirely the business's problem, this is where we see the great big spec document,
great, big specification come in.
Think about it this way.
As software developers, we like to make fun of the 300 page specification.
But no business person ever said, hey, I want some software.
I'd like to write a 300 page document.
They don't like that document any more than we do.
We're the ones that make them write that.
we tell them, we will build whatever you want.
But you better not change your mind.
If you change our mind, We will make it expensive for you.
So get it right.
And we introduce the great big specification document, and we make then fill that out.
This leads to, essentially, the waterfall process.
If you're familiar with the water fall process, it's essentially do all the analysis, do the design, all of the coding, put the whole system into operations.
Well, that's the hypothetical waterfall.
Here's a real-world waterfall that we see.
I like Donald Reinertsen calls it the fuzzy front end.
We got the Fuzzy Front End, then we got some sort of construction phase, and then the last phase of the waterfall process,
the rapid de-scoping phase.
Just rapidly drop all the things we're never going to have time for.
Rapid de-scoping.
That's what we see in the real world.
This is clearly not the right way to build software.
Third problem, our depressing start to the session, third problem.
Imperfect schedules.
If you know this, but I've written a book on estimating and planning.
But I'm going to say that estimatin' and planin' software projects is notoriously difficult.
Very difficult, right?
If we can't perfectly predict the schedule, it makes it very hard to have discussions about what should be in, what'll be,
in what won't be.
It's very to hard have those trade-off decisions, that kind of what if analysis, if we cant predict a schedule.
All right, very difficult So what do we do about all these things?
We make decisions based on the information we have, but we do it often.
And rather than one all-encompassing set of decisions, we spread decision-making throughout the project.
We avoid making one big set decisions upfront.
Here it is.
It's all documented.
This to me is where stories come in.
Stories are gonna help us do those things.
Story are going to help overcome those problems that we just listed.
Let's see what stories are.
To start with, let me grab something over here.
What stories are?
Ron Jeffries is one of the three guys who originated the extreme programming process.
Extreme programming is on of agile processes and user stories come to the rest of Agile world including Scrum and other processes from extreme programing.
Ron has written about something he calls the three C's.
Three Cs of a user story.
The first C is the card.
I've got these little index cards here.
And so when we think about user stories, we thing about writing them on these cards.I love these things.
i like that I can take these into meetings, I could spread them around on a table,I can turn them sideways or up on their end if I want.
So maybe a card this way means bug.
A couple months later, we get together for a different meeting.
Maybe a card turned this way means something the company CEO announced at the annual users meeting, right?
I like that I can rip them up.
I like that these things do not feel as permanent.
Things go into a software system, they feel permanent and we don't ever want to delete it.
So I love these thing as a tool and I was very opposed to these at first.
When I first started doing ads, when I came across stories and product backlogs, I'm a Software Guy.
I am not going to use these.
My grandmother wrote recipes on these.
Your guys' grandmothers do that, too?
Does that happen here?
My grandma wrote recipe on this.
I'm not going to put software features on here.
That's silly.
And so we built systems for this, and then later I had the first team I worked with that was using cards.
Wow.
Very powerful technique.
There's something about being able to have your hands on it that makes it more powerful.
We interact with it differently.
So Ron wrote about three C's, the card, and the conversation.
The conversation is this, a programmer grabs a card ready to go work on this.
Programmer grabs the tester.
And the programmer and tester walk over and talk to someone called our product owner or key stakeholder.
We say, hey, product owners, tell us more.
What is this story about?
What do you want?
How should it look?
And so the conversation, probably the most important part of the three C's I'm going to build up here.
I'll add one more C.
Conversation, the probably most In that conversation, the card serves a couple of purposes.
The card to me serves as a reminder or a promise to have the conversation.
Think of how powerful that promise is.
It is a promised from the team to the product owner.
We will come talk to you before we start.
That promise what frees the Product Owner up to not write every last detail down on here.
If the Team might start this thing, before they have a conversation with the product owner.
As the Product Owner, I'm going to feel compelled to not just write this little bit on a card, but to write a specification document and staple it too here.
Because the team might get started on there.
I better write a full-on spec and put it with this.
So the promise to have a conversation.
Now, the card is not a requirement.
Don't think of the user story as a requirements.
Think of a user's story is a pointer to the requirement, kind of programming term.
The requirement might be elaborated in a conversation.
The product owner talks to me and tells me what I need to know.
Maybe it's a workflow diagram, a little Vizio diagram.
Stapled to this.
Maybe its a math algorithm.
Do it this way, here's the mathematical prototype.
May be it a UI design, stapled to here.
So I think of the card not as a requirement, but as pointer to the requirement.
One more C.
Find my mouse.
Behind me, there we go.
Third C, conversation.
We go to the product owner, we talk, or confirmation, I'm sorry.
I was getting backed up.
Confirmation.
The third C here, confirmation.
This is the acceptance criteria that we use to judge when a story is done.
When I was 17, I as in the last year of what we call high school.
I don't know if you guys call it, what is it?
Is it gymnasium here?
Gymnasia?
So I'm 17. In the year before I go to university, and I had a literature teacher.
And she said, write a paper on Macbeth.
We'd been reading MacBeth in class.
She says, Write a Paper on McBath.
Boom, my hand goes up.
How long does it have to be?
And I asked Ms.
Nelson, my teacher, Ms Nelson.
I said, how long does it have to be?
And she just ignored the question and just kept lecturing.
And, I waited a few seconds.
Ms, Nelson you didn't answer my question.
How long will this paper have be.
She said I'm not going to answer that.
OK.
how does need to if I want a good grade?
I figured I'd try it a different way.
It needs to longer than if you want to a bad grade.
Ms.
Nelson, how long would it be if you wrote it?
Oh, it would be the right length then.
I don't know how I got her to give in, but she finally gave in.
And she said, Mike, just make it five pages.
Just make a five-pages.
You can tell I'm bitter about this all these years later.
I contend that that was part of her job was to convey her expectations to me.
That fact that, that paper had to be five pages were part her acceptance criteria.
Right, if I had turned in a half a page on Macbeth, and let's suppose for a moment it was brilliant, it wouldn't have been,
but let suppose it brilliant half page MacBeth.
No way was I gonna get a good grade.
Supposing it 50 pages on McBath.
No way would that have been brilliant either.
If I had turned in 50 pages, she might have written down a couple of good thoughts in here, cut out the junk next time.
Give me a bad grade on that too, F.
So she had an expectation.
She should have shared it with us.
Our product owners have expectations.
That's what we're after here with confirmation.
How will I judge this story when you're done with it?
It's our acceptance test.
Macbeth paper has to be five pages.
User story has be such and such.
Let's see a a few example stories.
As a user, I want to reserve a hotel room.
This would be from a travel website.
I don't reserve hotel rooms.
As the user I went to cancel a reservation.
Let's see one more.
as a vacation traveler I can see photos of the hotels.
Now, notice I did something different here.
The first one and second one were as a user.
This third one, as vacation traveler.
We embed the type of user in the story so that it can provide some context.
As a vacation travelers, not as business traveler, right?
I'm here this week as the business travelers.
I didn't spend any time looking at what hotel to stay at.
And I asked the conference organizers, I said, where should I stay?
They said which hotel?
And booked the reservation.
My family came over here.
We were here two years ago.
And we spent about five weeks in Norway.
we had this grand plan, see Norway, right?
And then you start to plan it.
It's like, OK, let's see the middle of Norway So we did here to Bergen, Lillehammer, Trondheim and back, and so we're arguing about next year,
do we go north or do go south?
So, we are arguing that for next years holiday.
But when we planned that trip, We came here two years ago.
We actually tried to come here three years, but my wife got so caught up in trying to make sure we picked the right hotels and the cities.
How can you see?
We had the plan to see Norway, and you couldn't.
And so she spent so much time picking out hotels.
She did a great job.
But a vacation traveler is going to look at photos of hotels, right?
I'm a business traveler.
OK, I am teaching at the conference center here.
Oh, there's a hotel connected.
I'll stay there.
All right, didn't look photos.
Of it I just stayed over there, all right.
One more story.
As a frequent flyer, I can rebook a past trip.
I flew over here on Friday, so it was May 31st or something.
Why in the world would I want to rebook a trip from Denver to Oslo on May 31, 2012? Does that make any sense?
Rebooked a past trip.
Does it make sense.
Sometimes the story doesn't make since until we add what is called a so that clause.
Let me add one here.
So that I save time booking trips I take often.
I love coming here, I'm fortunate enough to be able to come over to also four times a year.
But I would love it though if I could go onto a website and say, Give me the usual, please.
And it booked me Denver to Chicago, Chicago to London, London to Oslo, Oslow to Frankfurt, Frankfurt to Denver.
I'd love it if it could book that for me with one click.
All right?
I'm a frequent flyer.
Rebook a past trip?
Yeah.
Not the same date.
Of course not the date, right.
I consider the sew that clause to be optional here.
You'll notice I didn't have it on the other ones.
As a user, I want to reserve a hotel room.
I don't really need a sew-that clause there.
There's only two ways I can think of to end that sentence, and only one of them is moral, right?
So I don't really need to sew that clause there.
I consider it optional.
But from these four stories, you can kind of infer the template I like for writing stories.
Like to write them this way.
As a type of user, I want or I need or can, or am forced to, something like that.
And then optionally, so that and some reason.
The sew-that clause is sometimes very helpful in telling us why somebody wanted something.
Oh, that's why you want it.
OK, can give that a completely different way, in fact, we already support that in the system.
So the sow that clause to me a little bit optional.
Now in these stories, where are the details?
These things are short.
We only have this little tiny card.
Where do the detail go?
Let's think about this story about I can cancel a reservation.
I'd have a lot of questions.
I walk over and talk to my product owner and I've got questions Does the user get a full refund or a partial refund when they cancel?
Is the refund policy the same at this Radisson as the Radison by the airport?
How about the radison buy the old airport, right?
is it the Same cancellation policy at all Radisons right how far ahead does the User have to cancel their reservation?
I don't have A lot Of questions So our question is, what do we do with all the answers?
A couple of things.
One thing we can do, with those answers, is we use them to write what are called conditions of satisfaction.
Conditions of Satisfaction are essentially test cases, high level test case.
What I like to do is I take a user story, I can cancel a reservation, and then quite literally turn it over and on the back write our high-level acceptance test.
All right, let's think about my English literature teacher a moment ago.
Write a paper on Macbeth, on the back must be five pages, all right?
So the bag of the card has the acceptance criteria for this.
So in this example, we might have acceptance criterion like these.
Verify that a premium member, somebody who joins our website, can cancel the same day without a fee.
They verify that non-premium members are charged a free, Verify that we send an email out and verify that the hotel's notified that they have a room available again.
Those would be my essentially acceptance tests.
Okay, I use the phrase acceptance test.
So why am I using this weird phrase up here, condition of satisfaction?
Here's what I found.
If I walk into my product owner's office and I say, hey, product donor, tell me your acceptance tasks.
Who do they tell to me to go talk to instead?
Tester.
They say, go talk to a tester.
So I'm a busy product owner.
You're here to talk about tests?
Get out of here.
Go talk a to tester, right?
And I don't want to to test her.
Well, that doesn't sound right.
I Don't mind talking to the testers, but I want get the conditions of satisfaction.
Want to get high level answers straight from my product owners, not a tester.
The product owner is the one who, a couple of weeks from now, at a sprint review or iteration review, is going to sit in judgment of this user story and say,
it's done, or it is not, go change it.
So I want to know their acceptance criteria.
What I found is by using a slightly different phrase, hey productowner, tell me your conditions of satisfaction.
I get better results.
So a slightly different phrase.
Sometimes the words that we've used for years have loaded meaning.
Find that especially with things like beta test.
Beta test means such different things to all sorts of different people.
It's kind of a hard phrase these days.
I go to my product under a different phase.
Tell me your conditions of satisfaction.
What do you need to see to be satisfied with this?
The end of the sprint, I mentioned that we do an iteration or sprint review.
One of ways to know that you're writing those conditions of satisfaction at the right level is this.
Think of them as the script for the Sprint Review.
Two weeks from now, three weeks, whatever it is, you are going to demo this user story to your product owner.
Those conditions on the back are the Script.
Those are the things I'm going to want you to show your product owner.
You're going walk through, you're gonna show them.
That's why when I do this I actually quite literally with cards I will draw that little box here.
I don't draw a bullet, I draw little check box.
Then when i'm giving my product under the sprint review, i check it off.
Okay we've shown you this, we're showing you.
This that becomes the script for the Sprint Review.
These are essentially high-level tests.
i just use a different phrase.
So I'm going to back up here.
We said we're talking about detail.
How do we add detail?
We go have a conversation, product owner starts laying on us a bunch of detail, one way to capture that detail tests on the back.
Another way add to detail is to use smaller stories.
So we have story here, I can cancel a reservation.
I ask my product owner what that means.
I get a lot of detail out of my project owner and I decide to write smaller stories.
In this case I might write the stories as a premium site member I can cancel a reservation up to the last minute.
As a non-premium member, I cancel but I'm charged 10%. As the site visitor I am given an email when I canceled, things like that.
So I could write small stories, that's the other way to get at additional detail.
I want to point out something that I think is pretty subtle, but I thing is very important.
Look at the user stories up there.
Premium member can cancel, non-premium members charged.
I'm going to back up a slide.
So here are those conditions of satisfaction on the back.
They're the same, OK?
These two techniques are essentially two sides of the coin, right?
We can write smaller stories.
I can right conditions of satisfaction on the back.
Both techniques or the say.
The effect is different.
And I end up with more stories, or I put tests on back of this story, but the technique being different, we get the same result.
It's a way to add detail.
Now you don't need today to decide which of these approaches you like.
You like this approach.
you Like writing tests on the back.
Meanwhile, you got a co-worker back in the office reading a book about Agile, and your co worker decides that he or she likes writing smaller stories instead.
And now you've got problem.
If you liked one approach, your coworker likes the other.
Not really a problem, You're going to use both.
When you have a great big user story, the natural thing to do will be to turn it into smaller story.
When you have a story that you've turned pretty small, the natural thing to do will be turn it over and write tests on the back.
So we're going to use both of these approaches, okay?
You'll use of both these approach, which is what this slide is saying here.
You're gonna use to both approaches.
It's gonna be a natural think.
I pointed out here to make sure you're aware of it, but you are going do both things that will happen naturally.
Okay?
I want your product backlog to look like an iceberg.
I don't want your backlog to look like an iceberg.
Now, what I'm talking about here is I want small things at the top of your back log.
Small, detailed things.
Those are coming into the next sprinter iteration.
They have to be small enough we can do them in the couple weeks.
But we've got other things we're not going to do for a while.
We might not do it for six months or a year.
I wanted those to big, vague.
All right, we had a travel site up there a minute ago.
Let's think about a Travel Site.
Let's think about orbits.
I've never worked with orbits, I haven't worked for three travel sites.
Haven't work with orbit, so I'll use them as an example here.
Let us think of about this.
A guarantee that orbits has a product backlog item.
They have something that says, as a traveler I would like to book a cabin on a cruise ship.
Orbitz doesn't support cruise ships.
But somewhere, they have a requirements document or a backlog that says, do cruise ship, but they've been in business for 10 years or whatever and still
never got to that.
It would have been a waste for them to write that as a very detailed set of user stories.
The right thing for then to do, if they haven't done it yet, just leave it alone, great, big, huge user story at the bottom of their backlog.
Someday, orbits will finish all their other higher priority travel site stuff, and they'll be sitting around and this story will have moved from the bottom
to the top.
And they will be, hey, let's do it.
Let's finally do cruise ships.
We've done everything else.
But until it moves to top, It's a waste of time to invest in that backlog item.
I don't want to add detail to it when it's not important.
So if we think about a real world iceberg, not our product backlog iceberg.
Think about real-world iceberg floating out there in the North Atlantic.
Helicopter flies over and lifts off the top of the iceberg for some reason.
What happens to the remaining part of iceberg?
What's it going to do?
It's going to float up, thank you, it's gonna float.
There's less weight pressing it down, and it floats up.
I like that as a metaphor for our backlog here.
It points out a couple of things.
New things are becoming visible at the bottom.
The iceberg floats, new things become visible.
We've got a flat spot at top of the backlog, we have to do something about that.
Here's what we're going do.
We're going to take things that are in the middle of the backlog and break them into smaller pieces so that we now have a suitable set of small things
at the top of our backlog.
This is something that Agile teams call grooming the backlog.
Grooming the Backlog refers to keeping the backward in good shape.
We groom the backpack.
All right, we make sure that every sprint or every iteration we're spending a little bit of time Keeping the backlog in good shape so that we end up at
the next sprint planning meeting walking in and we've got small things at The top ready to do we don't want to walk into the Next sprint planting meeting
and have those great big things in the bottom.
All right, then we say what do?
We do and somebody says cruise ships.
Oh Gee, you know, what we have to for a cruise ship.
What's it gonna be like?
How are we gonna do this?
so we to have a little bit of this grooming going on to keep the back log in Good shape And thinking about your product backlog iceberg,
I want to introduce a couple of terms here.
The first term, epic.
Epic just means great, big one.
Typically means bigger than a sprint, bigger that fits in one iteration.
This is going to take us more than in a few weeks to do.
Now, over here in this part of the world, a lot of times people, teams will call this a saga instead.
I'm fine with that.
Saga, Epic, whatever.
Just means big.
The other term I want to introduce here is theme.
A theme is a group of related items.
So suppose we're sitting around in orbits and we decide, hey, let's do cruise ships.
And so we take our cruise ship story, it's a great big one, I mean epic, All right, I rip my epic up, and I write a bunch of smaller stories that all have
to do with cruise ships.
So we write all those.
We do all that work.
we get a whole bunch stories written.
And then somebody walks in and says, oh, great idea.
Let's change how we do hotels.
Really do this instead.
What's not do the cruise ship stuff?
Well, darn it.
I just spent all the time writing all of those stories.
Well here's what we're going to We're going to take those cruise ship stories, put a rubber band around them, and then we're gonna put them back in our
shoe box or wherever we keep our stories.
And we want to treat that as essentially one thing.
All right, it's got a rubband around it.
It's really only one think.
I don't got to look in here at all the things.
Now I'm just gonna write on top of this theme, I mean, to write cruise ships.
So a theme is a group of related.
Think of it as a staple or a Rubber Band around a Group of Stories.
An epic, one big one.
two terms that we use.
Now I want to give you an example.
As an examples from one of my clients, these guys are in two cities in the US, one city in India.
They make software for large retailers, so big stores.
So here's one their stories.
as the vice president of marketing at a store, I wanted to review the performance of historical promotional campaigns so that I can identify and repeat
profitable ones.
Basically, the story here is saying I'm the vice president of marketing.
How should I spend my ad budget?
I don't want to know how to spend by ad-budget.
I asked the team how big was this.
And I said, I want know your estimate.
That's too hard.
But if I were to ask you to estimate this, would you come back with an estimate in hours, days, weeks, months, or years?
So what type of unit pops to mind?
Because even if you had to do that, just seat of the pants type thing, and they said oh, many, OK, this is clearly an epic.
This is going to take lots of weeks.
Clearly an Epic.
So let's split it up.
I asked the team to split up, here's what they did.
As the VP of Marketing, the top one, I want to select the time frame to use when reviewing the past promotional campaigns.
The bottom one, I want to select the type of campaign.
Radio, direct mail, email marketing, television marketing.
This is a good split between our stories here.
The top one was selecting the date range, the bottom was the selecting type.
What's nice about this is these stories were independent.
We'd like to have stories that are independent, right?
I could do the top or the the one.
I can do these in either order.
Suppose we did the first.
If we did the top one first, the team could select a time frame to use.
They could say, show me the summer season, or show just Easter, Or show June for the last five years.
But they would get June, for all types of advertising.
Radio, television, email, print.
If they did other order, if they do the bottom one, first.
The team can say show only email advertising, But they'd get it back through the dawn of time.
So these stories are independent.
We could do them in either order.
It's a good split.
I asked the team, how big were these?
I said, are these epics?
Bottom one is.
Bottom is still pretty big.
so we split the bottom one up.
Here's how we've split, the Bottom story.
As VP of Marketing, I can see information on direct mailing, another one about television ads, and another about email ads.
This is an example of this story starting out at the top of the backlog, moving up, Eventually, something like TV ads would get to the top of the backlog.
At that point, we'd turn it over and write its conditions of satisfaction on there.
Conditions of Satisfaction for a television ad story would be things like, I want to know how many people watched it last night.
I wanna know, how may of them were in this income bracket.
How many of them were 18 to 25 years old?
That's our target audience.
I'd want to know things like that about our television.
Very different than what I want know about email ad.
Email ad, I wanna know click through rate, bounce back rate.
Things like.
Different conditions of satisfaction.
So let's talk about writing user stories.
Let's see if we can yell some of these out.
I want you to think about this and see you can help me out here.
Suppose we have a login user story, right?
We have story that is about logging into the system.
We want to see we could write some these together.
Help me figure out a couple stories.
And here's some examples.
As a registered user, I'm required to log in so that I can access the system.
That, of course, is our base story.
A forgetful user.
I could request a password reminder so I that can log-in even if I forget my password.
Anybody have any other examples?
What else might we write as a story related to logging in?
Anybody think of any examples, you'll have to totally format it into this syntax if you don't want, but any A new user, right?
So we could write a new users story.
As a user I can register on this website so that I have an accountant come back and have it remember things about my usage.
Any others?
Oh, good.
Good.
As a user logging in for the fifth time, I get a discount.
I just did something.
We changed our email marketing system.
Use this thing to send out emails.
And they sent me something because I sent my first email campaign with them.
So I've logged in many times, but I send the first campaign.
They sent something, right?
So, like that one, we get reward to somebody.
Let's get one or two more.
What else do we have?
You're the hacker.
So that's a great example.
That's the great examples.
We're talking about user stories, right?
That is an example of an abuser story.
Right?
Abuser.
Now we don't want to write abusing stories but we want think about them.
All right, we wanna think of them so that we make sure we prevent those things, all right.
And so sometimes it is useful to think things like what does a hacker want, and that can lead us to writing stories like As the chief security officer
of this company, I want all passwords to be eight letters long, minimum eight-letters long non-dictionary words.
Got to include a digit or something like that in there.
Or as a user, i am required to change my password every 90 days.
As a use,r I'm locked out after three failed attempts.
We can write stories like.
And those might originate from the idea of, oh, we got to careful of hackers on here.
The way I like to write stories is in something we call a story writing workshop.
In a storytelling workshop, we bring the whole team together.
Yep, I want the programmers there.
Yep I what the testers there, analysts, designers, database people, scrum master, product owner, bring the whole team together.
Not going to do this every sprint.
My recommendation is to this about every three months.
What I'd like to is set a goal, a target out there on the horizon.
Three months from now we will have this set of functionality done.
We're going move there every two weeks or so.
But I wanna longer term goal.
And we get together and we write stories about where I wanted to be in three month.
Three months later, we write another goal about where we want to be two, three, four months, later.
So we keep setting these kind of goals out there every few months.
We get together, not every sprint, but every three months or so, and we right a bunch of stories about what we wanted done.
What do I want to do on a cruise ship?
I'm going to book a berth on cruise ships.
I wanna be able to see a floor plan so I know if I am close to the pool.
Want to be to request what deck I on.
All those type of things will be part of our cruise-ship stories.
Now when you do a story writing workshop, you need two things to successful.
Two things.
The first thing you need is you a bounding scope.
I always hated that phrase, think outside the box.
That phrase always bugged me and I never knew why.
If I read an article about it a couple years ago, and it was talking about creativity, it said creativity comes from thinking inside the Creativity comes
from thinking inside the box.
I gave you a question a moment ago, I said, hey, help me write user stories for logging in.
Imagine I had yelled out instead, Hey, somebody yell out a user story.
That would have been harder.
Writing a new user's story for anything in the world would've been hard than when I constrained it.
Write a story about this, because that puts your mind into a particular area.
So this article, and I totally agree with this, said that creativity comes from thinking inside of a boundary, inside a box.
So the think outside the box thing is never necessarily was the right way to go.
The first thing you need to be successful is a bounding scope.
Second thing we need be to successful with Story Writing Workshop is some sort of graphical arrangement.
I like doing it in just a simple hierarchy.
There's all sorts of ways to do this.
You can do mind maps, all sort things.
Just going to over the simplest here, a hierarchy, We think about on our travel site, who are our users?
Well, frequent flyers.
They're one type of user.
What are some of the things they want?
Now, I want to do this within our bounding scope.
Now what are the some things that they what?
Those are probably epics.
And then time permitting, we take those and break those down into smaller stories.
So we have to have some sort of graphical arrangement in the story writing workshop.
Otherwise, what happens is you end up with a big pile of cards all over the table and somebody yelling out, did we already write stories for this?
You have no idea.
So something that gives you some presentation of this.
I think stories are a great technique.
I want to talk about why.
Going to end with why here.
One of the things that stories do for us is they shift our focus from writing to talking.
We are not with Agile trying to get away from documentation.
The Agiles Manifesto has this great statement where it says, we value working software over comprehensive documentation,
a lot of people misinterpret that and think, oh, Agil's against documentation Absolutely not.
But on Agile, we are trying to create a shift from documents to discussion.
Write less, talk more.
That's a generalization some projects need to write more to.
but in general, as an industry, We should be talking more, writing a little bit less.
And stories are meant to help us do this.
Now there's this thing, I call it the Grand Myth.
The Grand myth is this, that if we write the requirements down, the user is going to get what they want.
And that's not true.
If we write requirements down, at best, the user is going to get what was written down.
Which may or may not be what they wanted.
My company bought another company a few years ago.
And one of the guys we got as part of that acquisition was an amazing product manager.
I don't want to call him product owner, because he wasn't agile yet.
An amazing project manager, and he had written a wonderful specification document for his team.
So we buy this company, I've got a number of teams there, And I'm going to convert them all to agile over time, but I can't convert all agile day one.
And this one team has a great spec, wonderful specification document.
And it's about a two-month project, so I'm not going to convert them to Agile.
I am just going let them go.
It's an amazing document written by this wonderful product manager.
The product manger is going be busy.
For the next couple of months, I need him traveling around the world, merging our two product lines.
He's the guy who's going figure out what features from which projects are going end up in the consolidated product.
So I will have him travelling around figuring that out.
But it doesn't matter.
They've got a great document, great IEEE, the system shall this, this system, shall that document.
The team starts off on that project, they run it for two months.
The end of two month, the product manager and I are back in their city to see what they've done.
They give us a demo.
they got everything that was in his document.
At the end to that meeting, I remember what he said, because I got up and had to get it out of my head, so I wrote it on the wall,
exactly what it said.
He said you built what I asked for, but it's not what i need.
Now, he owned up to his responsibility for this.
His attitude was essentially, you nailed it.
This is exactly what I had in my document.
What in the world was I thinking?
This was a system for doctors years ago, and he's like, no doctor will ever use this, what was thinking, this is crazy.
No doctor ever touch this?
Now I don't know where we would have figured that out if we had built this project in an agile manner with stories.
Now it took us eight weeks till we got to the end of the project, maybe we could have figure it out after two weeks, but probably not.
Maybe after four weeks.
That's pretty likely.
Maybe, after, four, weeks I'm using twos, because we probably would have done two week sprints.
Certainly after six weeks, I think by then, at a minimum, he would've looked at it and said, wow.
I should probably go show this to some doctors.
This is not looking like something they'd use.
So I don't know where, but probably before the eight weeks we would figure that out.
Stories are going to help us get to the point where we're talking more, writing a little bit less.
We're not quite as reliant on the written word.
One of the reasons I want to be less reliant on the written word is how imprecise words are.
Words are horribly imprcise.
I went to a restaurant in Denver for lunch and this was on their menu.
It said entree or main dish.
Main dish comes with soup or salad and bread.
This is a microbrewery.
They make their own beer there, they've got these big vats of their beer, and they make a really good French onion soup.
And so I wanted the French onions soup with my lunch instead of the salad that day, but I was kind of hungry.
I don't think I'd had breakfast.
So I'm a little bit hungry and I looked at that and said, well, I still want some bread too.
and i wasn't sure how to parse that sentence, right?
Was it soup or salad and bread no matter what, or did you only get the bread if you ordered the Now, I've been to a lot of restaurants,
so I was pretty sure how things worked.
But I'm looking at it, and I realize I am not 100% sure.
And as I look at this, the waitress walks over, puts some bread on the table, And said, can I take your order?
I pretty when I ordered the soup, she wasn't going to take the bread away.
No bread for you.
But there's nothing wrong with that sentence up there, apart from having a French word in it.
But whoops.
Apart from that, there is nothing really wrong that sense.
That sense is perfectly grammatically correct.
Right?
But it's still impossible to know the exact meaning of the sentence.
And I want to show you a couple other examples of words being imprecise.
I've just got a few other slides to share you guys here.
These are both from the same specification document.
And this is actually a really good document, I feel bad for picking on this document because these are probably the only two things in the document I could
pick on.
It was a good really document but this was the bioinformatics system, really hard core medical stuff and there was requirement in there that said the user
can enter a name, it can be 127 characters.
This was a Windows Explorer-like part of the interface.
You were naming folders of genetic data.
So think about Windows explorer.
And it said it can be 127 characters.
I looked at that and I said, well, that's a weird requirement.
Wonder if that is a maximum.
Now most of us will look at and go, of course that a is maximum number.
But this was weird system.
There were requirements on this system where you had to enter names of things that had be 32 characters made up only of letters A,
C, G, and T.
That's a weird requirement, right?
I don't remember enough from my old genetics class, and for me, it would have been high school.
But there's reasons for that to do with DNA and stuff.
It was wacky requirements.
So when I saw this can be 127, I actually had to go ask.
I said, can it be 128? No, no, that's the maximum.
OK, good.
Another requirement on this thing, the system should prominently display an error message.
Should, what does that mean?
Promotively display what that means.
These are all things that we would have to discuss.
A couple other reasons why I think stories are good.
One of the things that is true about stories is they're understandable.
OK, we're in a little session right now.
We're on a one-hour session about Stories.
But we were talking about some of vagaries of them, how to write them and things like that.
we don't have to teach customers how read them.
Customers can read these things.
They'll instantly know what they mean.
As a user, I can book a cabin on the cruise ship.
they'll know that means without any training.
There's a very famous study.
It's called Scripts and Memory for Text.
And what this study did is they dumped a bunch of facts on people, brought a group together like this, just told them a much of fact,
tested them for recall.
They brought another group of individuals together, and they told him some stories.
Embedded in the stories were the same facts.
The tested that group for a recall, which group do you think had better recall?
Second group, stories, right?
I think back, and I remember when I was a little kid, we started school in the US at about five.
I don't remember anything from being five, but I remembered my second year of school.
Remember when was six.
And I can't anything I particularly learned in that class.
If that was the class where I learned how to spell or the alphabet or how add, I dunno what I've learned there.
But I totally, clearly remember sitting in a classroom and the teacher reading us Charlie and The Chocolate Factory before lunch each day.
I remember the stories from that class, but I don't remember anything else.
I mean, I'm sure I remembered how to spell or whatever I learned there, But I didn't have any conscious memories of it.
Stories are memorable.
Now I am not going to say our user stories are as memorable as Charlie and the Chocolate Factory.
It would be nice if they were.
But when we read our stories, they are more likely to stick in our heads I think than little statements, the system shall this,
this system, shall that.
Those just pass right through.
These other things, because they're in first person, we start to relate to them.
have a little bit better recollection of them.
Story support and encourage.
I think that's important.
And encourage iterative development.
This is because of how easy it is to move between a epic, a big story, small story.
Rubber band the small stories back up into a collection of stories called a theme.
Because of how easy it is to move from high level to low level of detail, it makes it easy for us to work on an iterative manner,
to iterate through the project, build a little bit of something at a time.
I was writing the book on user stories a few years ago.
One of the things that blew my mind about stories, I went back, and I had my publisher help me out.
We did some research on what had been the best-selling requirements books of last 20 years, what have been best selling requirements of all time.
And so I read all these old books on requirements planning.
No requirements technique before stories had really come along and ever said, Hey, if it's big, make it smaller, because it is too big for the team to do.
Think about all the stuff you might have learned about traditional requirements gathering.
None of it ever said, hey, it it a big nasty scary hard to-do requirement, you should split it up.
That was never part of that.
So stories were the first requirements technique to come along that were really about a way to document requirements, in a sense,
and plan the project.
And so stories solve two purposes.
They're kind of pointers to requirements, like I said.
But they're also about planning the project.
Serve dual duty.
Very important, I find.
There was a study done at Stanford University in California in 1990, long ago.
It was an interesting study.
The professor who did the study was interested in the question, do we design top down or bottom up?
Top down, or, bottom, up.
Answer to me is kind of obvious, both, right?
But she wanted to solve the problem.
You know, being a researcher, she want proof, not just an opinion of both.
So she brought in elevator designers, and she posed a problem to them.
Your designing the bank of elevators for a building.
The building is this big, it gets this much freight, has this many people working in the building, how many elevates do we need,
which routing algorithm should we use?
And so she videotaped them talking through the problems.
As after she was done, she reviewed the videotapes and documented, were they thinking top down or bottom up?
And she documented where they had breakthroughs, where had epiphanies.
And what she discovered is that we designed, not top-down or, bottom-up, but what was she called, opportunistically.
All right, we design top, down until we get stuck.
Then we go bottom, up for a while, then we top , down, and we bounce back and forth opportunisticly.
Well, stories, again, help us do this because of how good stories are at helping us go between big and small.
Epic down to smaller story, rubber banded back together into theme.
Stories help as go back and forth from high and low levels of detail.
Last real benefit on stories I want to touch on here is that stories support what is called participatory design.
There's two schools of thought on design, the first school of thoughts is what's called empirical design and empirical designs we treat our users like
lab rats.
We bring them into the room.
We watch them through the one-way mirror.
Maybe we record their keystrokes.
we study them, we poke and prod them.
Some of this can be good stuff.
I'm not down on that.
Where we go wrong, though, is that then we, the all-knowing software professionals, make decisions for them We've studied you.
That's where we go wrong.
The other school of thought is called participatory design.
In participative design, we engage the users in the process.
And stories help us do this because of how easy it is for our users to participate in a process, right?
We bring them in, say, hey, write some stories.
I don't train users on how to do this.
I bring them into the room, I write on a whiteboard, as a blank I want blank, so that blank.
And I say, let's fill that bank in.
What do you guys want?
What type of users exist?
what type subpopulations exist in our user community?
We fill in the blanks.
Users become active participants, or can be active participant.
Want to look at one example here.
of kind of an IEEE 830 style requirement.
Is there something up there?
Oh, something went wrong on that slide.
This slide is supposed to have a kind of an IEEE 830-style spec.
I remember enough of it, so I'll ask you to just kind go along with me on this.
Suppose we had a specification that said something like this, we're building a real-world product, not a piece of software,
real world, tangible product.
What I want you think about is, where does your brain go, as I give you a couple requirements?
The product shall have a steel body, the product will have four wheels, The products will a rubber tire mounted to each wheel,
and the products shall a multi-speed transmission.
Where's your head going?
Now you know I'm setting you up for something here, but just go, where are you mentally going with that set of requirements?
Right?
It's the thing we interact with most frequently that fits those things.
Right.
That is a list of system attributes.
The system shall this, the system show that.
Let's see what we would do differently if we had user stories instead.
Keeping in mind that what user's stories focus on is what the user desires of the systems, not the systematic attributes,
so here are a couple of user story.
As a user, I want to mow my lawn quickly and easily.
I want to be comfortable while mowing my lawn.
And so we realize that we're building something completely different.
So the goal here is to focus on the user's goals, not the attributes of the system.
This is something that user stories help us do.
Last thing I'm going to share with you guys.
Don't forget the purpose.
The user story is not a requirement.
So the text we write on the card is less important than the conversations that we have.
excuse me, a pointer to a requirement.
It's a point to do a conversation, it's pointer an Excel document showing me some sample calculations.
There's the pointer a Vizio workflow diagram, something like that.
So the conversation is more important than the card.
The card's point or to that conversation.
I'm going to end there.
I've got classes coming up.
They just told me to announce this.
So I do classes here every couple of months.
Here's my contact information.
And I love talking about this stuff.
But I should have mentioned at the beginning, all the slides from all of the talks I have done today are on my website.
You should go to mountaingoatsoftware.com.
All the presentations are up there, plus over 100 other presentations I'd given over the years.
so you can download all sorts of stuff from up here.
Thank you guys very much.

What Is a User Story in Agile? (Examples + Template)

Transcript

Ever built something only to find out it's not what your user wanted?
Yeah, been there.
What if there were a simple way to make sure you're on the same page with your customer?
Enter user stories.
They're small, they're powerful, and they put your users front and center.
Whether you are agile, hybrid, or still figuring it out, user Stories work across the board.
they help teams stay focused on value, what users actually need, not just what we assume they might need.
But despite their usability and popularity, user stories are surprisingly misunderstood by teams and product owners.
Let's fix that.
Join me as we do a deep dive reset on user Stories.
User Stories are short, simple descriptions of a feature or functionality told from a user's point of view.
Their main purpose?
To make sure that what we build truly meets user needs.
A user story isn't a full specification.
It's a placeholder for a conversation, a starting point for collaboration between team members and stakeholders.
User stories solve a requirements problem.
How do we make sure that people building a product or service understand what users actually want?
User stories help ensure clear, human-centered communication, not just a dump of technical details.
They help bridge the communication gap between the people who need a product or service and those who build it.
User stories follow this classic format.
As a who, I want what, so that why.
This structure keeps the focus on user needs and the value delivered.
So who's actually responsible for writing user stories?
Short answer, the product owner.
They're the one who owns the backlog.
And it's their job to make sure each item on the back log is clear, valuable, and aligned with the project vision.
But here's the thing, it's not a solo mission.
Good user stories are a team effort.
Anyone can suggest a story.
The best stories often are created collaboratively.
Even if the product owner writes the initial story, the team should be involved in refining it.
That means developers, designers, testers, everyone who helps bring that story to life.
Sometimes the best stories come out of a whiteboard session or a quick chat where someone goes, wait, what happens if the user does this instead?
And boom, a vague story turns into a crystal clear one with real value.
The point is user stories are not just a documentation tool.
They're a tool for collaboration, shared understanding, starting point for great conversations that lead to great products and services.
Ron Jeffries, one of the originators of extreme programming, came up with the concept of three Cs to describe what it means to write a good user story.
The first C is card.
Back in the day, we wrote stories on index cards.
I still love to do that when I can.
Why cards?
They're tactile.
You can move them, group them flip them or even tear them up.
They feel less permanent than documents in a software system.
And they serve as a physical reminder to have a conversation.
Today, most user stories exist in tools and that's okay.
But be sure to not treat them as permanent inflexible or standalone spec just because they exist software.
Remember, a user story isn't the requirement, it's a pointer to the requirements.
The second of the three Cs is conversations.
Conversations are the heart of a User Story process.
conversations happen when the team is ready to work on a story.
A team member may say, tell us more about this story, or what does success look like?
Or what if the user runs into issue X?
Every user story contains a promise to have this conversation before development begins.
Without this promise, product owners might feel they need to write full specs upfront, which defeats the purpose of stories.
I want to mention an important point here.
Just because a product owner says they want something doesn't mean the team has to create it.
The team isn't Wesley from The Princess Bride who says, as you wish, to every request.
It's part of the team's job to push back and ask questions, and even to suggest different ways to accomplish a goal.
That's all part the conversation part a story.
If you'd like to hear more about this, it's a part another video called Nine Lessons from the Princess Bride.
You can get to it in the link above or in description.
Okay, back to the three Cs.
The third C is confirmation.
Confirmation means the acceptance criteria.
How we'll confirm the story is done and done right.
These come naturally from the questions teams ask during the conversation.
Acceptance criteria provide clarity.
A story must do this.
It must not do that.
And if X happens, we expect Y.
I recorded a separate video that dives deep into acceptance criteria and how the team and product owner arrive at them together.
You can access it through the link above or in the description.
Let's walk through a few examples of user stories centered around something we're all familiar with, logging into a website or app.
We'll start with a really basic story.
As a registered user, I'm required to log in so that I can access this system.
That's our foundational login story, but what other stories might relate to logging in?
Let's think through a few different user perspectives.
How about this one?
As the forgetful user I could request a password reminder so I that can log-in even if I've forgotten my password.
That covers the password recovery scenario every product needs to support.
What about someone who's never logged in before, maybe a first-time user?
That story could be, as a new user, I can register an account so that I could log in and save my preferences for next time.
Notice how each story frames a different user need or context.
Now, here's a fun one.
This is based on something that happened to me recently.
As a returning user logging in for the nth time, I receive a reward so that I feel recognized and encouraged to continue using the product.
The story is about adding a premium feature or even just an on-screen acknowledgement so the user knows they're valued.
The story says this happens on the nth time, because at the time the story is written, it's not important if this is the third,
the fifth, or the twentieth time they log in.
That can be determined closer to implementation.
These kinds of stories, basic, edge-case, and even delightful ones, can all help shape a better experience through thoughtful,
user-centered design.
I want to talk next about a special kind of story.
But first, are you looking for a little inspiration for writing your own stories?
You can download 200 real-world user story examples that I wrote on an early Agile project.
Some are good, some are awful.
I have notes throughout to explain what I'd do differently if I were writing those stories today.
It's totally free.
Just hit the link here and in the description to level up your story game.
Okay, let's talk about stories to help make your system more secure.
To improve the security of a system, think like a bad guy.
Seriously, when you're writing stories, don't just think about what should happen.
Think about you want to prevent.
That's where abuser stories come in.
They're like user stories but written with the bad guys in mind.
I worked with a company that let homeowners rent their homes to strangers.
Thinking about bad guys, burglars in this case, led us to write, as a homeowner, I do not want possible renters to know that my home is available,
that is unoccupied, tonight so that I don't get robbed.
If we hadn't thought about burghers, we might have let someone search for homes that are vacant tonight with expensive stereos and large TVs.
We don't write stories for abusers, but thinking about abusors can help you write the stories that prevent abuse.
You might have noticed user stories are short, really short.
Just one sentence usually.
So that raises a good question.
Where do all the details go?
That's the topic of the next video in this user story reset series.
Watch it by clicking the link shown here or in the description.

How to Add Details to User Stories

Transcript

User stories are short.
As a who, I want what, so that why.
That's just one sentence.
So where do all the details go?
Where do we put all of the logic, the edge cases, and the rules that are typical in a requirements document?
There is a time and a process for handling details on Agile projects, and I'm going to tell you about both in this video.
By the way, my name is Mike Cohn, I am the author of three best-selling books on agile and Scrum, including one called User Stories Applied.
I help teams succeed.
Details matter on agile projects, but instead of cramming all the details into the story itself, we capture details in two main places.
And we captured details as close to the time that we're implementing as possible.
Before we get into how we capturing the detail, I want to talk about when we captures those details.
The short answer is as closed to time when the team will work on it as possibly.
Usually that means product back or refinement meetings.
Product backlog refinement meetings are typically held weekly or bi-weekly.
Most teams aim to spend no more than 10% of their total iteration time on refignment activities, including meetings and related discussions.
While many teams prefer to hold a formal product backlog or refirement meeting near the end of the sprint, typically two or three days before it ends,
other teams may choose shorter, more frequent sessions throughout the Sprint.
It's up to you.
Experiment and see what works best for you.
So now that we know when to capture those details, let's talk about how.
Two ways.
First, the conversation.
This is the ongoing dialogue between the product owner and the team.
It's where questions are asked, ideas are clarified, and expectations are set.
The story is just the start.
the real richness comes out in those discussions.
The second way to capture details is as acceptance criteria.
A user's story should include acceptance criterion, conditions that must be met before the story is considered done.
Whether you're using sticky notes or a digital tool, there's always a place to capture a story's acceptance criteria.
These are essentially high-level test cases that define what done looks like for a Story.
Let's look at an example.
Here's the story.
As a user, I want to cancel a hotel reservation so that I'm not locked in if my plans change.
Pretty simple, right?
We add the acceptance criteria and things get more clear.
For this story, I'll add that premium members can cancel the same day with no fee.
Non-premium members are charged a cancellation fee, a confirmation email is sent to the user, and the hotel is notified of the cancellation.
Now we're talking.
The story with its acceptance criteria paints a much more complete picture of how the feature should work and gives the team something concrete to build
and test against.
All right, if you followed along in the user story reset series so far, you've seen how flexible user stories can be, from simple logins to surprise rewards
to preventing abusers.
Are you ready to dive deeper?
I've got something that can help you and your team successfully and quickly write your next product backlog or improve the one you already have.
It will also help to avoid getting bogged down by teammates who want endless amounts of details.
Click the link here or in the description to watch the next video and learn more.

Definition of Done vs Acceptance Criteria: What's the Difference?

Transcript

A Product Backlog Item's acceptance criteria is a list of things that must be true for that backlog item to be considered done.
But a definition of done is also a List of Things that Must Be True for a Product backlog Item to Be Considered Done.
Are these competing ideas?
Do you need both acceptance criterion and a Definition of Done?
If so, how do the two ideas relate?
Let's dig into the relationship between acceptance criteria and a team's definition of done.
Hi, I'm Mike Cohn.
I am the author of three bestselling books on Agile and Scrum.
Each product backlog item should have an associated set of acceptance These are essentially high-level tests to prove the backlog item does what it's supposed to.
Suppose you're developing an e-commerce website that allows people to buy wine.
One of your backlog items gives site visitors the ability to search for a wine, acceptance criteria for that will include things like users can search
by type of wine such as Cabernet or Chardonnay.
Users can searched by price range.
Users can search by ratings and so on.
On this same wine shopping site, there will be another backlog item that allows users to pay for the items in their shopping cart.
That will have acceptance criteria such as the buyer is charged the right amount, shipping charges are calculated correctly and added,
if a credit card is declined, the buyers notified and given a chance to edit the card's details and more.
Notice that these acceptance criteria are very specific to each product backlog item.
Searching by price is an acceptance criterion for the search for wine backlog items, but searching by prices doesn't make any sense as acceptance for paying
for items in a cart.
Contrast that with a team's definition of done.
A team definition done should contain things that apply to all, or perhaps nearly all of its product backlog items.
On a definition have done, we'll see things like the item has been thoroughly tested, the code is checked in, The website works in Chrome,
Safari, Firefox, Edge and Opera, and other items like that.
You could write these as acceptance criteria for every product back log item.
But it would be a lot of work adding these to every backlog item.
So instead, we elevate common items into a universal definition of done.
Think about the Winebine website.
Every backlog items the team delivers needs to be thoroughly tested, have its code checked in, and so on.
The difference between acceptance criteria and a definition of done is that acceptance Criteria are specific to a particular product backlog item.
The definition Of done Is universal.
It includes things that nearly all product Backlog items need to comply with.
I say nearly All because you'll occasionally have items that don't need To meet every part of the definition have done.
In our Wine website example, the definition of done required that things work in five browsers.
That system will have some behind the scenes features without a user interface though.
Perhaps it sends nightly emails with low inventory warnings.
There's no web browser involved in that little area at all.
Still, because most features will be run in a browser, including browsers in your definition of done is a good idea.
Let's look at a quick example of how I'm using a definition-of-done and acceptance criteria right now.
My acceptance-criteria for this video were, one, explain what acceptance criterion are.
Two, explained what a Definition-Of-Done is.
Three, explains the difference.
But for this video to be complete, I also need to meet my definition of done for every video.
That includes starting with a quick introduction, keeping the video as short as possible to respect your time, creating a cover image for the videos when
I upload it, writing a short description, and adding a couple of these links to other videos.
Oh, my Definition of Done also includes reminding you to click the like button and to subscribe so you don't miss future videos,
I hope your definition of done also includes leaving me a comment.
Let me know how you're doing with acceptance criteria and your definitions of Done.
Or let me what other topics you'd like me to address so I can get those done.
Thanks for watching.
I'll see you next time.

Agile Epic, User Story, and Feature: Do Names Matter?

Transcript

User stories, epics, themes, features, backlog items, initiatives, sagas.
It gets so confusing and it doesn't need to be.
In this video, I'm going to explain these terms and then I'll explain why I don't use a complicated user story hierarchy and why you probably shouldn't either.
Hi, Mike Cohn and I am the author of three best-selling books on Agile and Scrum.
I help teams succeed with Agil and want to help you too.
Most agile teams have what they call a product backlog, using a term introduced by Scrum.
At its simplest, a Product Backlog is a list of things to add to or improve in a products.
A Product backlog comprises product-backlog items.
That is, each thing on a project backlog is product backlog item.
Since that's a mouthful to say or a lot of characters to type, you'll see it often abbreviated as PBI.
The Agile process extreme programming introduced the idea of user stories.
These are short, simple statements told from the perspective of a user.
Imagine team members talking to users and saying, so tell me a story about how you use this new system we're building for you.
I'm using software to control my camera right now.
If I am asked to tell a story about how I'll use that software, I might say that I want to be able to easily zoom my cameras in and back out.
That's a user story.
Here's the first problem.
User stories have become so common in Agile that a lot of people will use user stories and product backlog items interchangeably.
I get it.
If, let's say, 80% of your product backlog items are user stories, you just fall into the habit of calling them all user stores.
We're not going to do that today, though, as I want to be very precise in using these terms.
User stories were invented by a team at Chrysler.
When you invent something, you should be allowed to define the vocabulary.
And they did, defining the terms epic and theme.
Epic was used to mean big user story.
Think about watching some awesome superhero movie in a movie theater.
As you leave the theater, You turn to a buddy and say, dude, that movie was epic.
It was big.
There was lots happening on the screen.
It's the same thing with an epic user story.
it's big!
The other term they defined was theme, which meant a group of related user stories.
Suppose you're working on a system that has 10 stories about account management, and maybe there are 15 user-stories, each describing a report that users need.
These are themes, groups ofrelated items.
If I've confused you with Epic and Theme, it's likely because some of the tool vendors use the terms differently.
Jira, I'm looking at you.
These tools will use Epic to mean a group of related items.
I don't know if this was a deliberate vendor lock-in strategy, or if a programmer made a mistake on Tuesday, released the software on Wednesday,
and by Thursday it was too late to rename the feature.
In any event, it's created confusion in the Agile world about Epic and Theme.
I've kind of given up and I'll often refer to them as big ones or group.
No one can redefine those terms out from under me.
You'll want to use Epic & Theme the way your tool does.
But be aware that if you read articles or books, you might encounter the original and what I consider the actual definitions.
So we've got a product backlog, on it are product-backlog items.
Some of those product backlogs items, perhaps most for some teams, are user stories.
some user-stories are big, and we call those epics.
And user story can be grouped into themes.
Next up is the term feature.
Most commonly, this means a product backlog item that is big enough it can be released to users.
If you're building software to control the color of smart home lights, you probably wouldn't release a backlog that let users set only the red value of
the light.
but letting users control the full color spectrum by setting red, green, and blue values is big enough to release.
So that would be a feature.
Feature is similar to Epic, at least how Epic was originally defined.
Epic just tells us that a story is Big, but Features tells it's big ENOUGH to be releasable.
Some organizations or tool vendors add even bigger items on top of this.
Sometimes saga is used to mean something bigger than an epic, and initiative is use to means something taking perhaps a year to do.
Something this big shouldn't be on your product backlog, so I'm not sure why we need a name for it.
I recommend you think of these terms as labels or tags that can be applied rather than as a strict hierarchy.
This is because some features are bigger than some epics or themes.
There's not a magic size when an epic becomes a feature or the other way around.
Think of tagging movies in your movie library software.
I want to tag some movies as action movies, some as comedies, and perhaps some romantic comedys.
Is there a strict definition of these?
If there are 32 jokes per hour, does that make it a comedy?
If there are 20 jokes plus a kiss, is it a romantic comedy?
It doesn't work that way.
Action movie, comedy, romantic-comedy are just labels we can apply, and we do it for our convenience.
The same should be true of terms like user story, theme, epic, feature, saga, or initiative.
They're just labels.
Use them if they're convenient, or I guess if someone in your organization is requiring them.
I think of everything on my product backlog as a product-backlog item.
Some are big enough that they contain smaller backlog items within them, and some of those small items contain tiny items.
To me, it's quite simple with a recursive relationship.
i don't need a bunch of terms that can create confusion.
And when I do want to indicate that a backlog item is big, releasable, or related to other items, I can tag those items.
No complicated hierarchy needed.
Is your team using a complicated product backlog item hierarchy?
What benefits do you see to that?
Any challenges?
Do you use terms other than the ones I've described?
Let me know in the comments.
I read and appreciate every comment.
If this video has been helpful, click the Like button.
And if you're new to this channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching, and I'll see you next time.

The 5 Biggest User Story Mistakes Teams Make

Transcript

There are five big mistakes I see teams commonly make when working with user stories.
Fortunately, each is easy to avoid once you're aware of the mistake and why it's a mistake.
First is thinking that every user story needs to be small.
Small stories are great, and I want to bring only small stories into a Sprinter iteration.
But larger stories can be useful.
You should prefer large stories when it is not something you are going to work on imminently.
Suppose you have just begun work on a new product that will include a set of reports.
If asked, you can list some but not all of the reports that will eventually be needed.
And since this is a new product, none of their reports are needed immediately.
There is nothing to be gained by writing a bunch of small user stories at this point, especially since you don't yet even know all the of reports will
be need.
You could go interview a lot of users and stakeholders and perhaps get close to a complete list, but in most cases that work is better done later.
Having one big reporting story rather than a bunch of little stories keeps the size of the backlog more manageable.
You'll have one entry in your tool instead of 15 or 20. That's much easier to manage.
Further, if you do write all the small user stories, one per report, it gives the impression that you've thought of everything.
Early in a project, that's probably not true.
New reports will be identified, and some that are asked for initially may not be necessary.
So if bigger user stories are OK, when should a team split them?
Second in our list of mistakes is waiting until sprint planning to split user-stories.
Sure, some stories will absolutely need to be split during sprint-planning.
The common case, however, should be for stories to been split prior to the iteration or sprint plan meeting.
Many teams conduct backlog refinement meetings.
These should ideally be held two or three days before the start of a new iteration.
I view a product backlog refinement meeting as a pre-planning checkpoint.
It is a chance for the team and product owner to discuss the work that will likely be brought into the next iteration.
This should include whether high-priority items are small enough.
Any that are not should be split at that time.
Routinely breaking large stories into smaller ones during sprint planning makes that meeting take longer, and it's too late for the product owner to realistically
act on information provided by the estimates.
If stories are split sooner, it gives the Product Owner time to prioritize each.
Think about our large reporting story being split into a set of smaller stories, each representing a different report.
Some reports are more important, and the estimate to develop each should influence how each is prioritized.
Splitting small stories out of the larger stories prior to the iteration planning meeting gives the product owner time to make these decisions.
Let's look at a third big mistake teams make with user stories, thinking that everything on your product backlog needs to be a user story.
I get it.
User stories can be really helpful, but you don't want to use stories the way I cook with basil.
Yep, even chocolate chip cookies.
The purpose of a user story is to facilitate communication and understanding of users' needs.
Expressing a users needs in a story, is very helpful when there are nuances to what the user wants, but it's not always necessary.
Let me share two examples.
First is technical changes or enhancements.
A backlog item like upgrade the Linux server is perfectly fine.
In fact, it's preferable to something like, as a user, I want this system hosted on the latest version of Linux so that the system is secure.
A second example is bugs.
Teams have been writing bug reports since cavemen wrote the first line of code.
Writing, this system blows up when I enter a negative amount in the value field is good enough.
Naturally, supporting notes should be provided, but there's nothing to gain by writing most bug report as stories.
Additionally, some product backlog items you might be tempted to write as user stories might better as job stories.
Job stories are an interesting alternative to user's stories Job Stories de-emphasize who is doing a story and instead emphasize when the story occurs
and the job the user wants to accomplish.
I've got a video about job Stories that I'll link to in the description.
Another mistake teams make is slavish devotion to a template.
The, as a type of user, I want some goal so that some reason template, has become extremely popular.
It's a good template and it forces us to think about who wants the story, what they want, and why.
But I've seen teams go to the extreme of insisting everything be written in this format or it's not considered a user story.
A user's story can be any short, simple statement that helps stakeholders or users and the team discuss a user's need.
I think using a template is a good starting point, but not everything on your backlog needs to fit neatly into the same template.
A final mistake teams make is writing stories too far ahead of when they'll be developed.
I don't encourage writing the stories this week that you'll do next week.
It's good to have a vision or direction a couple of months ahead and to write stories for that horizon.
But when possible, you want to avoid having a backlog that stretches much further than that into the future.
There are exceptions to this.
If you're working on a fixed price project, you'll often need more of a backlog.
Similarly, if stakeholders need a roadmap of future deliverables, You may need to create a back log stretching that far.
However, remember the advice to use larger stories when looking that for ahead.
Larger stories won't include as much detail, but capturing a general future desire will often serve you better than trying to think of every little story
that users will want in the future.
Avoiding these five mistakes will help you create a product backlog that will set your product up for success.
If you found this video helpful, please do me a favor and hit the like button.
It really does help YouTube know to show the video to others.
And click the subscribe button if you'd like to be notified of future tips.

How to Split User Stories with SPIDR: 5 Story Splitting Techniques

Transcript

In the next eight short minutes, I'm going to show you how you can split any user or job story you come across.
Once you know the five approaches I'll share in this video, you'll know all you need to know to split stories.
From there, just get better with practice.
A few years ago, I was creating the Better User Stories course.
Because this course would cover everything someone needs to know to work effectively with stories, i knew it needed a module on splitting.
To create that module,I printed out over a thousand user stories I'd collected over 15 years.
For each story,i had the original story and the substories it had been split into.
I taped each Story onto a wall, grouping them based on how they'd been I was looking for the common approaches used in splitting all these stories.
I went through a variety of groupings trying to find the smallest set of approaches possible.
It would be easier to remember five splitting techniques rather than 20. The five I ended up with form the acronym SPIDER,
S-P-I-D-R, so spider without an E.
Let's take a look at each technique in the SPYDER acronym and see how you can use it to split stories!
The S stands for Spike.
A Spike is an activity a team undertakes to learn more about some backlog item.
Think of it as a research activity, but it may include prototyping or some experimental coding.
During a Spike, a Team isn't trying to develop new functionality.
Instead, they're developing new knowledge that will help them develop the functionality later.
We're here on YouTube, so let's use YouTube as an example.
Let's go back in time to when YouTube added automatic captioning.
The team doing that might have faced a build versus buy decision.
Do they use some commercially available software to generate the captions, or are their needs so unique that they need to develop something from scratch?
The way to settle that would be a spike to test out one or more commercially available captioning products.
Extracting a Spike makes the original story smaller, because some or all of the research included in the story is removed.
This is absolutely an essential way split stories.
So Extraction a Spikes is one of five splitting techniques you should use, but normally it won't be the first technique you'll reach for.
Our second splitting technique is paths, which is the pea and spider.
To split a story by paths look for alternate paths through the story.
Sticking with YouTube, let's use this story I can share a video with my friends.
When I click the share button in YouTube today, I'm shown 14 buttons I can click to share directly to various social networks.
I've also shown a link I could copy, and I am given the option to customize that link to start playback of the shared video at a specific time within the video.
That's 16 different paths through the I can share a video story.
I don't know that this story needs to be split into that many smaller substories.
That is for the team to decide based on the effort involved.
But with the path technique alone, we've identified 16 paths though the original story The eye in Spyder is for interface,
which refers to splitting a story by its interface.
The most trivial example would be on a mobile app.
You can split the story into an iOS and an Android version.
In other cases, splitting by interface can be done by having a simple version of the interface and a more involved version as separate stories.
This usually applies to a user interface Applying this to our YouTube video sharing example, as an alternative to splitting the story by paths,
we could have split out a basic sharing story like, As a video viewer, I can get a URL I share.
This could be implemented with no user interface other than a share button on the video page.
The pop-up with the 16 different ways of sharing wouldn't be needed if the only way to share is with a url.
A subsequent story could then be, as a viewer, I can share a video to various social media sites.
This could be done with a very simple user interface at first.
No fancy scrolling through a list of logos, maybe just a dropdown list text with the names of the social networks.
The final story, could, then, be something like, As a Viewer, i can choose the Social Network to share to by scrolling a through list showing the logos
of each.
Splitting by interface works because the ultimately desired feature can be built up to by progressively more detailed and better interfaces.
Let's move on to the fourth of the five techniques you can use to split any user story, and that is splitting the story by data,
which is the D in the Spyder acronym.
To split a story data do an initial version of a Story that processes only a subset of data that will ultimately need to be supported.
For example, YouTube allows you to upload a video in any of 16 different file formats.
If we're building a YouTube competitor, screw 16 file formats.
Let's start with one.
We're going to support one type of data.
All uploads need to be an MP4 format for now.
we'll add all the other formats later as separate stories.
Splitting by data is an effective approach.
Often there are a few types of data that add a lot of complexity.
Well, do an initial implementation that ignores the more complex data.
Get that implementation working, then add support for the complex more data You probably can't release the simpler version,
but you can still build it in that order.
I worked on a human resources system that did exactly this.
The system tracked who the manager was for each employee and would do things like route time off requests to that manager.
Most employees have one manager, but some employees had multiple managers.
We needed to support having multiple manager but, some stories were simplified initially by assuming each employees has exactly one managers Let's take
a look at splitting stories by rules, which is the R in our SPDR acronym.
Splitting using this technique involves relaxing some of the rules that a story will ultimately need to support.
Sticking with YouTube as an example, YouTube has some strict rules around including copyrighted music and videos.
If we're building a competitor to YouTube, our team's first story would be, I can upload a video so that others can watch it.
That story probably sounds simple, but there's a lot to it.
So in the first iteration, let's ignore the rule that videos can't contain copyrighted music.
We're not announcing our new YouTube competitor to the world after only one iteration anyway.
we'll have plenty of time after this first sprint to comply with our internal rule about not allowing videos with copyright music As another YouTube-related example,
suppose we want to prevent certain text from appearing in comments.
That could be swearing or maybe SQL commands that could mean hacking attempts.
Great idea.
Let's protect our users and our system from this type of text in Comments.
But an initial story of, as user, I can enter a comment on a video, can ignore that rule.
Doing so makes the story smaller so that it can fit within an iteration.
And support for the rule can be added a couple of iterations later.
Getting good at splitting user and job stories is an important skill.
With the short iterations used in Agile, it's helpful to have small units of work.
The five techniques we've covered here, splitting by spikes, paths, interfaces, data, and rules, should allow you to split any story.
In the comments, let me know what challenges your team has faced with splitting stories and share any other techniques you use to split.
If this video has been useful, click the Like button.
And if you're new to the channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching and I'll see you next time.

Why Your User Stories Keep Carrying over Sprint After Sprint

Transcript

Look at your sprint board for a moment.
If three or four items are almost done, one story is waiting on testing, another is on the back end, and the most important story moving into the next
sprint again, the problem probably isn't that the team didn't work hard enough.
The deeper problem is this, your team is finishing tasks but not finishing value.
In this video, I'll show you why that happens, how teams accidentally hide unfinished work inside their stories, and a simple test you can use to tell
whether something is really a story or just a task.
I'm Mike Cohn.
I've spent decades helping agile teams write better user stories.
And this is one of the most common patterns I see.
A team works hard, all sprint.
Everyone's busy.
Real progress is made.
But at the sprint review, the more important story still isn't done.
The backend works, but the interface isn' connected.
the happy path works.
but edge cases aren't tested.
The feature is close, but no one is comfortable calling it complete.
So the story moves into the next sprint.
When that happens occasionally, it may just be bad luck.
when it happens regularly, look first at how the Story was split.
Teams often think they have a capacity problem or commitment problem when the real issue is a splitting problem.
Big stories are hard to finish, but the bigger issue is that teams often break stories down in ways that still prevent anything usable from being completed.
Work moves, tasks get checked off, the board looks active, But the value is still trapped inside something larger that isn't done yet.
And in Agile, unfinished value is the same as no value.
That's where story splitting helps, when it's done correctly.
Story splitting means more than just making stories smaller.
It means creating smaller stories that each deliver something meaningful on their own.
The goal of story splitting is to release value sooner.
Let me show you what usually goes wrong.
A team has a story like this.
As a home buyer, I can search for a Home based on size, rooms, status, type, age, and amenities.
That's a big story.
So the team splits it by technical layer.
One backlog item for the user interface, one for back end, One for database and one testing.
That may look like progress, but nothing usable exists yet.
No one wants a search screen that doesn't search, and no one can use a database query without an interface.
The team has divided the work, But the value is still locked inside the larger story.
the team's finishing pieces of work but not finishing anything a user can actually use.
A better approach is to split vertically.
Do a little of the user interface, a lot of back end, little database work, and enough testing to make something work end to end.
For the home search example, the first story might be, as a prospective home buyer, I can search for a home based on size and number of rooms.
That's smaller.
It's incomplete compared with the full capability, but for what it includes, it works.
Now the team has finished something real.
A later story can add status and type of home.
Another story could add age and amenity searching.
Each story unlocks more value.
That's the shift from completing tasks to delivering value!
This is where teams confuse story splitting with task splitting.
Tasks describe activities.
Stories describe outcomes.
A task says, build database tables.
A story says a customer can complete a payment.
Here's the test I like.
After this is done, can someone do something they couldn't do before?
If yes, you probably have a story.
If no, You probably a task, even if you called it a Story.
If this sounds familiar on your team, this is exactly the kind of thing we help companies improve in our private agile training.
We work with teams to write better stories, split work more effectively, and make finishing meaningful work inside a sprint more realistic.
I'll include a link below if your company wants help with that.
One reason this matters is that big work hides uncertainty.
You've probably seen this, a story is 90% done.
A week later, it's still 90%. The developer was being sincere when they said they were 90%, but additional complexity showed up and finishing the story
got bigger.
Small outcome-based stories avoid this.
They move cleanly from not started to done and they expose risk earlier.
As a rough guide, be cautious of any story that can take half of a sprint.
That's usually a sign that value is bundled together instead of being delivered incrementally.
Good teams work with much smaller stories, not because small is automatically better, but because finishing is better.
So what makes a good split?
Someone can do something new when it's done.
The team can finish it comfortably within a sprint.
It cuts vertically through their product instead of separating the interface backend database and testing into separate backlog items.
Its clear enough that the team understands what must be true for this item to be considered complete.
And it creates value, even if it is only one small part of a larger capability.
Sometimes the team will say, this story cannot be split.
My first response, try harder.
Not harshly, but realistically.
Most teams give up too soon.
They try one or two obvious splits, usually technical layers.
And when those don't work, they give-up on splitting the story.
That's why I use Spider.
It gives teams multiple ways to find splits.
Spike, paths, interfaces, data, and rules.
If one type of split doesn't work, try another.
So when a story feels too large, don't ask, how can we divide the work?
Ask instead, what's the smallest piece of value we could deliver?
Can we support one path first?
can We defer an edge case?
We limit the scope to one persona, one data source, or one rule?
Are we creating smaller stories?
You're just disguising tasks as stories.
And most importantly, what must be true for this to be done?
If your stories keep carrying over, your team may not be failing to finish.
They may be finishing the wrong things.
The fix is to make the unit of work small enough that finishing something meaningful is realistic.
If you want a practical way to find those smaller value-based splits, watch my spider video next.
It gives you five ways to split a story when the obvious split doesn't work.
Thanks for watching.

Job Stories vs User Stories: What's the Difference?

Transcript

User stories have become the standard approach for creating product backlog items.
But that doesn't mean user stories are right for every product or feature that an Agile team works on.
As useful as user story can be, they've never been right to every team.
An exciting alternative for some teams is the job story.
Job stories originated at Intercom and were best explained by Alan Clement.
Job stories get their name from and are based on the jobs-to-be-done research of former Harvard professor Clayton Christensen and his colleagues.
That research led to insights that organizations often focus too much on categorizing users based demographic and psychographic data.
Demographics are objective data such as age, gender, and income.
Psychographics, are subjective and include things like goals, values, attitudes.
These characterizations lead to creating personas or user roles who represent different buyers or users of a product.
The jobs to be done theory says that organizations should focus more on what customers or customers hope to accomplish.
That is, we should focus more on the job to be done at the moment rather than on demographic or psychographic information about the user doing it.
Job stories de-emphasize who it is that's performing the action, which would traditionally be captured in a user story.
This leads to a different template commonly in use for job stories.
That template is when some situation, I want to do something so I can achieve this outcome.
As with the Common User Story template, there are three parts to the Job Story Template.
The first is a trigger or situation.
And that provides context on when the story is being performed or what action initiates the Story.
Examples could be when an order is submitted.
when searching by postal code, when no matches are found, or when looking at recent orders.
The second element of the Job Story template follows the I want to and provides the motivation for the story.
Think of a motivation as a user's stated or first order goal.
the third part of job story is the expected outcome.
think of this as the user ultimate goal as an example, I work with the video editor, Steve, to create these videos.
In case you're wondering, that's me.
When I record a new video, I want Steve to be notified automatically so that I can add the video to YouTube without delay.
My ultimate goal is to post new videos to Youtube soon after I recorded them.
I don't really care about Steve getting a notification, but that is the middle part of the story template, the motivation,
because it's how I think I could be able to make a video more quickly.
But if I give this story to a team and they have a better way of achieving the expected outcome, that's great.
To see the times when job stories may be better than user stories, let's look at some sample job stores and their corresponding user stores.
Let's start with this job story.
When an order is submitted, I want to see a warning message so I can avoid resubmitting the order.
This story describes the behavior seen on most e-commerce sites warning a user not to submit an order multiple times.
The user story equivalent of this might have been, as a customer, I want to be shown a message telling me not submit a order twice so that I don't place
a duplicate order.
The job story is superior in this case for two reasons.
First, this story applies to everyone making a purchase on the site.
So it's not important to know this person is a customer.
Second, the job store is better because it provides more context about when this is happening.
It is happened when an order is submitted, as the jobs story tells us.
Look carefully at the user story and you'll notice that it never tells when the message is displayed.
The team could successfully implement the user story by adding an item on an FAQ page warning users against double submitting orders.
But that is almost certainly not what the product owner wants.
Let's look next at entering the shipping destination when placing an order online.
The job story version is, when entering a shipping designation, I want the address filled in as I type, so I don't need to type all of it.
A user story version of this would be, as a buyer, I want the address filled in as I type, so I don't need to type all of it.
These two stories highlight the difference between user and job stories that exist in the first part of the template.
The when and as-a clauses differ, but in this example, the remainder of each story is identical in both user- and jobs-story format.
As in the first example, the job story is better here because of the additional context it provides around when the story has been performed.
Who is performing the action?
Entering an address in this case is not important, which is why the user story got written with the generic as a user.
In deciding when to use job stories, I think it's important to acknowledge that both user and job stores have unique strengths.
I still find user stories most helpful for products that have users who vary significantly and when deeply understanding those users is important.
This is why user story start with as a type of user.
We start user stores that way because doing so puts the user right up front.
In contrast with a job story, it is not important who is doing the story.
This makes job stories the better option when your product has users, but their needs are not very distinct.
If you've ever written a lengthy set of user stories and started each one with, as a user, you have encountered this situation.
When a large set user of stories all begin with as user recognize that you got a set stories for whom the user is very important.
Writing those as job stories rather than user stories would be helpful.
Doing so would allow this story to include the additional context of when the story is being performed.
In some cases, like these, knowing when a story might happen is more important than knowing who will perform it.
You do not always need to choose between a job and a user story.
It's possible to merge them and get the benefits of each in a single story To see how, let's revisit our user-story warning people not to submit duplicate orders.
That was, as a customer, I want to be shown a message telling me not submit an order twice so that I don't place a duplicate order.
As a user story, it is missing the context provided by the job story's win.
But we can add that, transforming this story to, as a customer, when I place an order, I want to be shown a message telling me not to submit an ordered
twice so that I don't place a duplicate order.
So when should you prefer user job stories over the other?
First, know that each is great and has its own advantages.
On any given product, I write some of each.
The two techniques are quite compatible, and there's no reason to view them as mutually exclusive.
If your product has users and those users' needs differ in important ways, I suggest user stories.
The additional emphasis a user story puts on who is performing the action can lead to insights about user behavior.
If, however, your products' users do not differ significantly, job stories are likely the better approach.
A good starting point is to mix user and job stories in the same product backlog.
Start by writing job story any time you find yourself tempted to write a batch of stories all beginning with as a user.
Job stories represent an important advance in building great products.
The jobs-to-be-done framework rightly shifts thinking about demographic and psychographic commonalities among users to instead thinking of their common needs,
the jobs to be done.
What do you think of job stories?
Would they be helpful on your product backlog?
Have you worked with job stores already?
If so, were they helpful?
Please share your thoughts in the comments.
If this video has been useful, click the like button.
And if you're new to the channel, please subscribe so you don't miss out on future tips.
Thank you for watching and I'll see you next time.

Story Map Timing: When to Create & Update Story Maps

Transcript

On a recent Agile Mentors podcast, I turned the tables on host Brian Milliner and I interviewed him about a resource he created for our community called
the definitive guide to the what and when of product owner responsibilities.
The link to download the free PDF guide should be appearing just above my head as I speak, and it's also in the description.
In this video, i want to share a moment from that interview with you.
We'll start at the moment when I asked Brian to tell me more about one of the quarterly activities he recommends for product owners,
creating a story map.
I want to ask you about the story maps for a second.
What's your guideline?
Because somebody asked me this recently.
I'm curious on your answer.
What is your guide line for when we should create a StoryMap?
Do you always, only at the start, or in the middle?
What your advice?
Creating it, I always created at start.
And again, this is my experience, right?
But what I have found to be useful is to do it at beginning.
It's sort of right in that order.
Right?
I've done the vision.
Figure out who my users are.
Then I want to know what the...
the general big picture is for my product.
I want to be able to step back from a 50,000 foot view and say, all right, here's kind of the step-by-step of what we're going to doing.
Because kind like a product backlog, it's a living, breathing document.
It's not done, we do it once at the beginning of our product and then it is done set forever.
It's constantly adapting and changing as we add new feature areas, as understand differently how our users would interact with the product.
We're going to adjust and change it.
I want it to always reflect reality.
Let's talk about reality there.
But what I see is story maps that are hard to keep up to date.
Are you seeing teams that really succeed at keeping them up to date all the time?
I know the living breathing thing for like a couple months and then it's like the dusty old story.
Yeah.
Well, this is kind of one of the things where it was kind hard for me to put this in a time frame because there's really two time frames that I would like
this to appear in.
Yes, I do think we should do it before the first sprint.
And by the way, again, there I would do this in multiple rounds with different sets of stakeholders.
But then once it's established, kind of would slide that into that quarterly kind.
Of activity to say we may not touch it every quarter, but every.
Quarter I.
Would want to check in on it and just say is this still accurate?
Do we need to adjust it?
We need.
To do anything different about it.
What about you?
Do you create story maps?
When?
How do you ensure they aren't just buried eight deep in some file folder?
Let me know in the comments.
Remember too, you can download the free, the definitive guide to the what and when of product and responsibilities from our site.

User Story Mapping Tutorial: How to Create and Use Story Maps

Transcript

Knowing how to create, read, and use a StoryMap are essential agile skills.
A Storymap can help you uncover user needs, find alternative ways of achieving a user's goals, help organize your product backlog,
visually communicate how the steps a users performs fit together, prioritize what to develop and more.
Story maps were invented by Jeff Patton.
In this video, we're going to cover how to read a story map, the vocabulary used for talking about story maps, when to create a Story map who should participate
in creating the Story Map, how turn a storytelling map into a roadmap, and how a storyline map relates to a product backlog.
Let's start by looking at how to read a story map.
By the way, my name is Mike Cohn, and I'm the author of three best-selling books on Agile and Scrum.
I help teams succeed with Agil.
A story is a two-dimensional visual representation of actions a user will perform to achieve some goal.
The first dimension of a StoryMap is across the map, Cards lined up horizontally show a sequence of steps a user will perform.
Because the horizontal dimension of a story map represents a Sequence, you can read across a map by mentally inserting the word Then between cards.
So the map here is read as a User does Step 1, Then Step 2, then Step 3. For example, if we're mapping the act of sending an email,
we might identify the steps of select recipients, enter a subject, compose the message, and send the email.
Each step becomes a card on the map.
You'd read the maps by inserting then between each card.
First, the user selects the recipients.
Then the users enters the subject.
The user composes the messages.
So far, so good.
But I said story maps are two-dimensional.
So let's look at the second dimension, which is going to be down.
The vertical dimension on a story map shows alternatives.
Sticking with the simple email example, there are actually a few ways to select the recipients of an email.
A user can type in an e-mail address or type a recipient's name or select a name from a contacts list or a select name for past recipients.
As you can see, we read down a map by mentally inserting the word or between cards.
Cards containing alternatives should be placed on the map in descending order of priority, the most important at the top and the least important the bottom.
Priorities established like this in a story map incision shouldn't be rigid, and their product owner can change them.
But it can be useful to have short discussions about rough priorities within a column of alternatives.
In my example story map, I'm saying that typing an address of an email recipient is the top priority.
So if we're developing this email product, i'd love for it to support all four ways of selecting recipients.
But if the team only has time for one, The top row of a story map is called the Backbone.
Generally, cards in the backbone are not stories you'll implement directly.
You won't, for example, bring the card Select Recipients into a sprint.
Instead, you will bring in one or more of the cards below it into the sprint A team might,for example decide that in coming sprint they will work on the
Type an Address and Type a Name cards, leaving the other two cards for later.
If your map gets a little too wide and unwieldy, you can make it easier to read by adding a second row to the backbone above the top row.
Think of the Top Row of The Backbone as analogous to signs along a highway, those signs that tell you when you're entering a new city or such.
On a story map, cards in the top row tell you when you're entering a new area of functionality.
But instead of, welcome to Arizona, the signs on the backbone say, Welcome to Saving a Document, or Welcome To The Checkout Process.
As long as we're talking about terms, let me go ahead and define a few other terms used with story maps.
After that, I'll describe how to create a Story map and how use it to convey a product roadmap.
In story mapping, we use the term step to refer to any card on the map.
Sometimes it's useful to referred to a group of steps.
In a story map, an activity is a collection of Steps that achieves some goal.
For example, logging in might be an Activity with the multiple steps of entering a name, entering password, passing a CAPTCHA challenge,
enter a code sent to the user's mobile device, and so on.
The steps and activities will become the user stories that give Story Maps their name.
Steps will typically be small implementation-sized user Stories.
An activity will be typically larger in what some teams and tools will call an epic.
If you put an activity under your product backlog, you'll probably later split it into the smaller steps or user Storys so that the team has small units
of work that fit well into sprints.
Finally, the term narrative is used to describe a sequence of items read across a map.
I was describing a narrative when I said you can read a across map by mentally inserting then between each card or step.
Looking back at our story map for writing and sending an email, we can a read narrative across the one line of the backbone.
Select recipients, then enter the subject line, and then compose the message, send the email.
By the way, if you want a one-page story mapping cheat sheet to help remember these terms and how to read a story map, I'll leave a link in the description.
It will give you a nice one page PDF on storymapping.
Let's talk about when to do story mapping.
I recommend doing it at the start of a project to get a feel for the overall product or system being built.
This is early on in a product, so don't get too detailed.
And I also recommend creating a story map any time a team is ready to develop significant new capabilities for users.
For example, suppose we're developing an e-commerce website and want to add wish lists as a new capability in the coming period.
We would create a story map showing how users will be able to interact with the new wish list capability.
I don't think you need to do a story map for everything.
For example, suppose we added wish lists to our e-commerce site years ago, and now we want to enhance that feature, perhaps with the ability to add a note
to items in a wish list.
We can probably just add user or job story to the product backlog describing this.
A user story could be, as a logged-in user, I can add note of an item in my wishlist so that I later remember why I added it.
Or I could write that as a job story.
When viewing an item in my wish list, I can add a note so that I later remember why I added it.
If you're not familiar with job stories, check out the video on them in this playlist and linked in the description.
Sure, there will be some UX design needed on this, but you probably don't need to map something out that is this small overall.
Who should participate in story mapping?
I want the product owner in any system or business analyst to participate.
We also want to consider including any users or stakeholders who can speak to the specific needs being story mapped.
If the team has a scrum master or coach, that person should facilitate the story mapping session.
And I want team members to participate, ideally the full team.
But this is not a meeting that I'm going to cancel if someone has dentist appointment.
I just generally want the whole team there.
When team members participate, they're going to hear the underlying reasons users and stakeholders want whatever is being developed.
Hearing about needs, problems, frustrations, expectations, or more directly from users or stakeholders can sometimes lead team member to insights they
may have otherwise missed.
And of course, I want team membership to participate because they often have very good ideas.
Ideas that non-technical participants may not think of.
Team members can also help steer discussions to the right level of depth.
I've seen more than one Story Mapping session where participants would have spent more time talking about something than it would've taken developers to
just do it.
Because a Story Map is arranged vertically in priority order, it's really easy to use a story map to convey a roadmap.
This allows a product owner to show the intended delivery sequence of features in one or more upcoming releases.
To create a roadmap, add a horizontal line to the map and then drag above the line everything that must be included in the next release or version of the product.
Then add label to map indicating what the items above line represent.
Here I've indicated that the cards above the line are part of the minimum viable product, or MVP.
Notice in this map that I put two cards from the third column above line.
This is fine.
It's just saying that those two alternative ways of doing something must both be supported in the MVP On the other hand,
notice that I didn't put anything from the fourth column above the line.
Again, this is fine.
It indicates that a suitable minimum viable product can be delivered without anything form that column.
Situations like these are common and to be expected.
To indicate additional milestones on a story map, you simply add additional lines.
Here I've added a second line to indicate the quarter three release.
I also moved a few cards above it and one lonely card below it.
Story maps can help teams discover important product backlog items they might have otherwise overlooked.
To do this, walk through the steps on your story map, thinking about each step from the perspective of a user.
It can be very helpful to ask a few questions at each stop, such as, what will a use most likely want to do next?
What mistakes could a user make here?
What could confuse a use at this point?
what additional information could the user need at the step?
If your product has multiple types of users, ask these questions for each type of user.
Story maps are my favorite tool to help product owners, stakeholders, and developers understand user needs and the interconnectedness of those needs.
I find story maps extremely effective for brainstorming the product backlog items that will be needed to achieve a team's next significant objective.
Do you use Story Maps?
Have you found them helpful?
What challenges have you experienced with Story maps?
Please share your thoughts in the comments below.
If this video has been useful, please click the Like button as it helps others find the video.
And if you're new to the channel, click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching, and I'll see you next time.

Walk Through a User Story Map Example with Mike Cohn

Transcript

Let's take a look at an example story map. I'll walk you through how to read this map and how a team would interact with the story map to develop the product. If you're new to me, my name is Mike Cohn, and I help teams succeed with agile. The story map I've created is for YumHub, a food delivery service. You've probably used a similar service. The first thing a YumHub user needs to do is enter the address where the food will be delivered. Then the user needs to select a restaurant. You can probably imagine there'd be a few ways different users might want to do that. One user might want to search for a restaurant by name. Another might want to see only Thai restaurants. Keep these different ways of selecting a restaurant in mind. We'll come back to them, but first we want to finish laying out the top row of the story map. After selecting a restaurant, a user will select the food they want delivered. I'll have the quesadilla. Then the user will set a delivery time, confirm the order, and finally pay. This row of a story map is called the backbone. It defines the main flow through a map, and it's read horizontally by mentally inserting the word then between cards. So we read this map as: first the user enters an address, then the user selects a restaurant, then selects food, then sets the delivery time, and so on. Story maps are two-dimensional, so let's add the second dimension to the map. Under each card in the backbone, you'll see alternative ways of doing that step in the backbone. Starting with enter address, our map shows three ways of entering the delivery address. A user can enter a new address, use a saved address, or use the current location. When you're adding these cards, you want to put them in priority order, highest at the top, lowest at the bottom. Here I've put enter new address at the top because I think that's the most important of the three. I don't think use a saved address can be the top priority because no one has any saved addresses until they've ordered at least once. And using the current location is great, but ever since I accidentally sent panang curry to my neighbor, I don't always trust my detected current location to be perfect. Because the cards in a column are alternatives, we can read down a column by mentally inserting or between cards. So here we would read that a user can enter a new address, or use a saved address, or use their current location. We'd continue reading the story map by saying, then they select a restaurant, then they select food, and so on. Across with then, down with or. In the next column, the user will select a restaurant. I've listed two ways of doing that. The user can browse the available restaurants, or the user can select a restaurant from past orders. Again, they're in priority order, and I put browse restaurants first because a user will not have past orders the first time they use YumHub. YumHub will let users select the food they want from either the full menu, past orders, or the most popular items at the restaurant. Then users can have the order delivered as soon as possible or schedule it for later delivery. After setting the delivery time, users can confirm their order or cancel their order. And then finally, I've listed three ways a user can pay for the order. Again, these are in priority order. Pay for my quesadilla with Bitcoin seems lower priority than paying with a credit card. I want to give you a tip that can really simplify working with story maps. Think of each card on a map as possibly containing a submap within it. To see this, let's drill down into the browse restaurant step of the map. I like to think of being able to metaphorically double-click on a map, and it turns into its own submap. So inside browse restaurant, we have this map. YumHub will let users filter by cuisine. You're looking for good Indian food. I still want that quesadilla. YumHub will also let users filter by star rating, which users can do by saying they only want restaurants with, let's say, four stars, or they can ask to see restaurants rated from four to five stars. Finally, users can also filter by price. They can do this by using preset price ranges YumHub will determine, such as $10 to $20, or a user can enter their own custom price range. Remember I said that you read across a map by mentally inserting then between cards. So here we have filter by cuisine, then filter by star rating, then filter by price. Some users will absolutely perform these steps in that order, but other users will perform them in a different order, maybe filtering by price first, and others may only filter by one or none of these options. It doesn't matter. Put the steps on a story map in the order you think makes sense, or in the order you think a typical user will perform them in. But don't obsess over the sequence in situations where things can be done in different orders. If you're mapping an email product, yes, write email needs to come before send email. But you'll encounter many situations like the browse restaurants case in which users may perform some, all, or no steps and can do them in any order. When story mapping, it's more important to think of as many steps and alternatives as you can rather than debating the order in which users might do variable steps. Story maps look deceptively easy, but they can be harder to create than they seem. It's worth it to take the time to get good at mapping interesting situations in your story maps. A good way to gain experience is to practice by mapping existing parts of either your product or a product you use often. If this video has been useful, please click the like button. And if you're new to the channel, click subscribe so you don't miss out on future tips to help you succeed with agile. Thank you for watching, and I'll see you next time.

How User Story Maps Become Product Backlog Items

Transcript

A story map shows a sequence of steps users perform and alternative ways users can perform each step.
Cards on a storymap can become product backlog items in three different ways.
First, any one card on the map can turn directly into a product-backlog item.
If we're building an app or site that collects payments, for example, we may have a card that says, Pay with American Express Card.
That's a Product Backlog Item.
Second, because a column of cards represents different ways of doing something, the entire column can become one product backlog item.
If our map has a Column of different Ways to Pay, that Column can Become one big Product backlog Item.
Finally, a Sequence of Colums can Become one Big backlog Item.
On an e-commerce site, users can search, save items to a wishlist, check out more.
Wishlists will span multiple rows and columns.
it could become one large product backlog item.
This is a good idea if you won't develop that feature for a while.

All Videos

2 Big Reasons Why Sustainable Pace Is So Important to Agile Teams

Transcript

Overtime is the first refuge of bad management.
When teams get behind, as they often do, even with Agile, managers search their bag of tricks for a solution.
All too often, the solution they pick is that solution that was used on them before they became managers.
Obertime.
It didn't work then, and it won't now.
Hi, I'm Mike Cohn and I am the author of three bestselling books on Agil and Scrum.
I help teams succeed with agile and want to help you too.
When a team falls behind schedule, there are many things besides overtime that a manager could try.
They could add people to the team, they could drop a few requirements, that is not drop them but do a simpler version of some.
Managers could extend the deadline.
Why then do managers so often reach for overtime as the solution?
Because it's easy.
Buy team members some pizza and Red Bull, sit back and watch the problem evaporate.
Well, maybe.
Other solutions are harder to enact.
You normally can't add people as quickly as you can buy a pizza.
Dropping requirements takes stakeholder participation.
By the time they agree, the project is either further behind, out of time, or both.
By contrast, asking or worse, telling a team to work overtime is easy and it sometimes works for a short while.
Kent Beck, inventor of the extreme programming agile methodology, has a great approach to overtime.
He says, overtime, is a symptom of a serious problem on the project.
The XP rule is simple.
You can't work a second week of overtime For one week, fine, crank and put in some extra hours.
If you come in on Monday and say, to meet our goals, we'll have to work late again, then you already have a problem that can't be solved by working more
hours One of my clients had to learn this lesson the hard way.
With a major deadline four weeks away, the CTO mandated overtime from everyone on the project.
And for the first week, it worked.
Velocity across all teams was up 22% over the average.
With results like that, he kept the mandatory overtime going.
The second week didn't go as well.
But velocity across all teams on the project was still up 2%. That's better than it would have been without overtime, but not by much.
people were starting to burn out, and in weeks three and four, velocity was down by 16 and 20 percent below the average without overtime.
During this four-week period, the teams actually delivered less with overtime than they would have if they'd worked at a consistent,
sustainable pace.
Even better would've been just one week of overtime to get that little extra surge of progress without burning people out.
There's nothing wrong with an occasional week-long surge of overtime when truly necessary.
In fact, a friend of mine claims that periods like that have been his favorite over his 30-plus years in the software industry.
He loves the team camaraderie and the trust that gets built when everyone comes together to achieve something.
I can't argue with him.
The problem is when overtime becomes the first tool managers reach for, and they see it as the solution to every problem.
Overtime leads to stress, which leads Here's a comparison of four successive projects undertaken at the same company.
Each project was adding functionality to the product, so the complexity is reasonably consistent across all four projects.
The red bars show the number of hours each project is estimated to take.
The blue bars show the number of hours of overtime worked on each project.
Projects 1, 2, and 4 had significant overtime, ranging from 22% on project 1 to 40% project 2. The yellow dots indicate how many defects were found in
each projects.
Look at the numbers of defects in the projects with overtime and compare those to the amount of defect in project 3, which had no overtime.
Overtime stress defects.
It's a predictable cycle many of us have seen time and time again.
An agile team seeks to break the cycle by working at a sustainable pace.
This is where a scrum's term sprint gets in the way.
Sounds like we're supposed to be burned out after a sprint.
We're not.
A bonus of working at a sustainable pace is that a team can choose to surge with up to a week of overtime if they want.
It can help.
And sometimes there are reasons to do it.
Your investors need a demo next week that will determine if the invest more money in the company or the companies will be fined if not in compliance with
a new law ASAP.
Is your team working overtime?
Let me know in the comments how it's going for them.
And if your has broken the overtime habit, use the comment section to let us know how.
I read and appreciate every comment.
This video is part of a series on how to work as an agile team.
Be sure to check out the rest of the videos by clicking the onscreen links.
Don't forget to click the Like button.
And if you're new to this channel, click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching, and I'll see you next time, unless you are working overtime.

3 Easy Steps to Stopping Manual Testing (And Be More Agile)

Transcript

There can be a role for manual testing on agile projects, but being agile is difficult if a team spends two, three, four or more days manually testing
each iteration.
When that happens, teams either move to longer sprints or they add testing, hardening, or stabilization sprint.
An over-reliance on manual-testing is a form of technical debt, which is any intrinsic technical deficiency in a product.
technical debt can sink a product.
In fact, technical has led all the way to the demise of entire companies.
Technical debt frustrates customers, companies, and developers.
Fortunately, there's a simple three-step process you can use to pay down a team's manual testing debt.
The first step is to stop the bleeding, which means stopping the situation from getting worse.
I worked with a team that spent about 50 hours every two-week sprint performing manual testing, essentially the last two days of every sprint.
If this team didn't make a change, the 50-hours would become 55 hours, then 60 hours and more.
As the amount of time spent on manual-testing debt climbs, it will be harder to pay it off.
it was urgent to stop things from getting worse.
To do this, team members looked for easy things to automate.
They didn't need to animate features being added in the current iteration.
That could come later.
The immediate concern was to Stop things From Getting Worse.
One simple automation they had created was for logging into the system and navigating to one of the areas under active development.
This saved everyone on the team about a minute for every test they ran.
With hundreds of manual tests being run each sprint, this was a big savings.
The second step in paying off manual test debt is staying current.
This is the critical phase when team members add automated tests for every new feature they add to the product.
Team members added their definition of done that every feature includes automated test.
Adding automation for each new features is not easy, but it helps that team member are able to improve their test automation skills during the stop the
bleeding phase.
A team can remain in the stay-current phase indefinitely.
Although they may still have a lot of debt, things are no longer getting worse.
The final step is paying the debt down.
During this catch-up phase, team members systematically attack the technical debt.
Sometimes this can be difficult because long-standing debt can hard to remove.
However, even incremental progress will help.
After all, the team has stopped the bleeding and is staying current with new automated tests for all new features.
They're now moving in the right direction.
We'd obviously like to see the debt paid down quickly, but that isn't always practical given competing needs for the teams time.
Following the three steps I've outlined, stopping the bleeding, staying current, and finally paying down the debt, can help any team reduce its over-reliance
on manual testing.
If you liked this video, please click the like button and don't forget to subscribe for more tips.
I'll see you in the next video.

3 Rights Every Effective Scrum Master Needs

Transcript

As a Scrum Master, you have certain rights and responsibilities.
In this video, I'm going to share three rights you need to be successful.
The first right of a scrum master is to have access to stakeholders and decision makers.
Lack of access isn't a common problem, but it occasionally comes up.
I worked in a call center systems project in which the developers and Scrum Master were not allowed to talk to the stakeholders.
The theory was that the call-center agents, who were all nurses, were far too busy to talked to developers, and the Scum Master.
That busyness was why they needed new software.
But without being able to learn their needs firsthand, we were making some bad decisions.
Everything had to funnel through our product owner.
That was not a scalable solution with over 100 developers on the project.
The developers basically resorted to stalking the nurses in the lunchroom because that was the only time that they could meet.
when a nurse was on his or her break.
That project was ultimately successful, but it probably could have gone faster if both the programmers and the Scrum Master had been given more access
to stakeholders and decision makers.
A second right of the scrum master is to be able to experiment with new ideas.
I love the fact that the majority of world now does two-week sprints.
But I think we've lost something as we moved away from four-week sprint.
Here's what we've lost.
The ability to experiment as frequently as we used to in the early days of Scrum with its longer sprints.
To see what I mean, consider a team in those early-days of scrum.
They would be doing a four-week sprint.
And imagine they have two options of how to achieve a goal.
One is the tried-and-true way.
Second is a possibly better way, but it's unproven.
The new way may not work, but if it does, it'll be better.
And with four-week sprints, teams very often would choose to try the riskier, breakthrough, innovative way, because if didn't work they would have just
spent three or four days on the experiment.
There would still be plenty of time to recover, to switch back to the safe approach.
Now we've moved towards shorter sprints and a lot of organizations have turned Scrum into a check the boxes process for determining if you finished all
the items you said you would.
If you did, you're successful.
But if haven't, failed.
And as that's happened, teams have moved away from feeling safe with experimentation.
Innovation recedes.
And so I'm mentioning this to you because I think it's important that we, as scrum masters, fight to establish experimentation as part of the company culture.
I am not talking about taking wild gambles or about experimentation during the final sprint of a major project.
But there are plenty of times during a project when it's worth trying an innovative breakthrough approach that may not work.
It's a worth a gamble sometimes instead of always using the tried and true approach.
Scrum Masters also need the right to address issues openly.
Part of your role as a Scum Master is to bring up problems and issues that need to be addressed.
If your company has a shoot the messenger culture, it'll be hard for you to continue bringing up issues when you're criticized and maybe even personally
attacked every time you do.
Do you have these rights in your organization?
Did you to argue to earn them?
Are there any additional rights you think you need as a Scrum Master?
Let me know in the comments.
I appreciate every comment.
If this video has been useful, click the Like button.
And if you're new to the channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching, and I'll see you next time.

3 Signs a Team Is Struggling with Sprint Planning & How to Fix It

Transcript

Sprint planning is often the longest meetings scrum teams have each sprint, so it's important to do it well.
But many teams struggle with sprint planning.
In this video, I want to share the top three signs that your team is struggling with sprint planing.
Number one, the meetings are long and painful.
I hear you.
Some of you are telling me that all meetings Perhaps, but while you may not enjoy being in a meeting, team members should at least find sprint planning
meetings valuable.
I don't enjoy going to the dentist twice a year to have her scrape the barnacles off my teeth, But I do acknowledge it's valuable Number two,
the team fails to finish most of the work and achieve the sprint goal in most sprints.
Teams don't need to achieve the sprint goal and finish everything every sprint, but they should finish every thing most of the time.
And too many teams miss every Sprint.
If people think of planning meetings as long and painful, those feelings are going to be compounded when the meetings don' t lead to successfully completing sprints.
And a third sign your team is struggling with sprint planning is that team members fail to leave the meeting enthused and energized about the work of the
coming sprint.
When sprint planting is done well, team member should be fired up, excited about doing the works they just spent time talking about.
If you and your teammates finish a planning meeting and aren't excited to do that work, it's a sign that sprint planning could be better.
Let's talk about how to stop struggling with sprint planting and do it better, by the way, I'm Mike Cohn, a co-founder of both the Scrum Alliance and the
Agile Alliance.
I help teams succeed with Agil and I want to help you too, especially with Sprint Planning.
To do, that I am going to share three tips.
First, keep your sprint planning meetings fairly short.
You don't want to rush through a planning meeting.
If you do that, you're almost guaranteed to overlook too much work and then not finish all the backlog items needed to achieve the sprint goal.
The advice be quick but don' hurry applies here.
the meeting should be fast paced but with no feeling that discussions are being rushed or cut off.
I like to target about 90 minutes to plan a two-week sprint.
If you're planning a 2-Week Sprint in 30 minutes, you are almost certainly not thinking through the work in sufficient detail.
On the other hand, when a Two-Wheek sprint requires a three-hour planning meeting, that's when people complain that the meetings are long and painful,
which was danger sign number one.
A second tip if you're struggling with sprint planning is to create a sprint backlog that includes a list of tasks and a rough estimate for each task.
A software team working on a relatively simple feature may, for example, have one or two coding tasks, a testing task, design task and maybe run a short
meeting to get the user's opinions on the design.
The estimates can be rough, little more than quick guesses.
The team should use them solely to gauge if they're bringing the right amount of work into the sprint.
Not too much and not too little.
Keep the estimates under a day of effort.
If something will take longer than a days, encourage team members to turn that into more than one task instead, each with its own estimate under day.
And the estimate should include time for everyone involved in the task.
The design review here has a three hour estimate, not because it's going to be a 3 hour meeting.
No, it is probably going be 1 hour and 3 team members will participate.
Coming up with these estimates shouldn't take much time.
Certainly not so much that your sprint planning meeting crosses over into that long and painful category.
Remember, they're really just quick guesses.
Plus, you won't need to do this forever.
Once your team has gotten good at planning sprints, try skipping the estimates.
Just create a list of tasks and see if team members can decide if a sprint seems appropriately full using just the list.
Here's a third and final tip, and this one will really save you time in planning meetings.
Don't try to think of everything.
I know, I just told you to make a list of tasks.
For each product backlog item, have team members yell out what needs to be done.
Code this, test that, decide how we'll handle such and such.
And very quickly, people will run out of ideas.
When that happens, give this silence perhaps five or 10 seconds to see if anyone thinks of any additional tasks, But after that,
move on and start talking about the next product backlog item and then creating its list of tasks and estimates.
When you do this, I can guarantee that some tasks will be overlooked.
If you'd given the team five more minutes to think about each product back log item, maybe played some Mozart music to help their brains think,
they would have come up with a few more items.
But it's not worth it.
Quickly identify the tasks the team can immediately name and then move on.
For this to be successful, make sure you don't fill the sprint too full.
The team will identify new tasks during the Sprint, so make you've left time for that.
For example, suppose you have a six-person team doing a two-week or 10-day sprint and you think team members can productively work for five or six hours
per day.
The rest of their time goes to meetings, discussions, corporate overhead, and so on.
A six-person team with a 10-day sprint and five to six hours per day will complete 300 to 360 hours in a sprint.
So perhaps this team should target identifying 250 hours of work during the planning meeting.
Team members will work the full 300-360 hours productive time during two weeks.
The 250 is just the amount that can be identified upfront at the start of the sprint, and the rest will be discovered as the team gets into the work.
Sprint planning is challenging, but it is vital for teams to get it right.
How is your team doing at sprint planning?
Let me know.
Are your meetings long and painful?
Do team members leave planning energized and excited about the works they're about to do?
And if your time is doing well at spring planning and achieving their sprint goals most of the time, please share your secrets in the comment section.
I read and appreciate every comment.
If this video has been useful, click the Like button.
And if you're new to this channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching, and I'll see you next time.

3 Signs Your Scrum Team Isn't Really a Team

Transcript

Scrum can lose its usefulness long before an organization stops doing scrum.
The events stay on the calendar, the roles remain in place, and the backlog keeps growing.
Meanwhile, sprint goals are routinely interrupted.
Reviews produce little useful feedback.
These same problems come up in retrospective after retrospect and unfinished work keeps moving into the next sprint.
No one decided to turn Scrum into bureaucracy, but that's what it's beginning to feel like.
How does that happen?
Usually, the problem extends beyond whether the team is following the framework correctly.
The environment around the Team is gradually making focus, feedback, and improvement harder.
In this video, I'll show you three places to inspect first.
your Scrum events, interruptions during the sprint, and the number of priorities your organization is asking teams to pursue at the same time.
I'm Mike Cohn.
And this gradual erosion of Scum is one of the most common patterns I see.
In this video, I'll show you three signs that may be happening on your team and what to do about each one.
The first sign is that your daily Scrum has become a status report.
You've probably heard this one before.
It's the most talked about Scum anti-pattern there is.
But stay with me, because the fix most teams try doesn't actually work.
The typical advice is to stop asking, what did you do yesterday?
And start asking the three questions differently.
Teams try that.
it feels a little bit better for a week.
And then things drift back.
The reason is that the format isn't really the problem.
The problem is the team is still orienting around individuals instead of the work.
Here's what actually changes things.
Start your daily Scrum with the board, not the people.
Point at the items closest to done.
Ask what does this item need to move forward?
Who can help unblock it?
What is most at risk of not finishing?
That shift moves the conversation away from individual activity and toward team delivery.
The team stops proving everyone is busy and starts deciding how to finish the most important work.
the second sign is that your sprint contains a mini waterfall.
A story moves from analyst to developer to tester to reviewer.
Each person does their part and hands it off.
That can feel orderly, but it creates waiting.
Someone waits for clarification, someone waits design, somebody waits code, and someone for testing.
Each wait may seem small, together they stretch the time it takes to finish anything.
Handoffs also delay learning.
The tester sees the story late, the product owner sees implementation late.
the developer learns about a problem after starting something else.
That's how teams end up with several items nearly done and very little actually done.
Here's a useful exercise.
Take one product backlog item from your last sprint and trace it from start to finish.
Mark every time it waited for someone else.
Then ask, which weights could have been avoided?
Who should have involved earlier?
What could we have overlapped?
The goal is not to eliminate every handoff, the goal to make handoffs visible and reduce the ones that slow the team down.
A team should be asking, what should we finish next more often than, What can I start next?
The third sign is that people are focused on my tasks instead of our work.
A team working like individuals organizes around personal assignments.
Each person owns their piece, tries to stay busy, and can say, my part is done.
But Scrum works best when the team cares more about finishing valuable work than keeping every individual occupied within their specialty.
A developer who finishes coding should not automatically grab the next unrelated item just to stay busy.
They should look at what the team is trying to finish.
Can they help test?
Can the review someone else's work?
can they swarm, meaning the whole team focuses together on the item most at risk of not finishing?
The question is not just, what am I assigned to?
the better question, is what does the Team need to Finish?
That shift's important.
Many struggling Scrum teams have several items nearly done near the end of their sprint.
Coding is done, but testing is not.
Testing is, done but feedback is missing.
A team with shared ownership attacks that problem earlier.
They don't wait until the last day to discover that too much work is unfinished.
Now, before I get to what teams can do about all this, I want to name something leaders often miss.
Sometimes a team keeps working like individuals because the organization keeps treating them like individual.
People are assigned part-time to multiple teams.
Specialists are shared across too many efforts.
Managers reward individual output more than team delivery.
Urgent work interrupts the sprint without a visible trade-off.
When that happens, people adapt.
They protect their own tasks.
The focus on what their manager will notice.
they avoid helping outside their specialty because they're already stretched thin.
So when a Scrum team keeps working like individuals, don't only ask what the team needs to change.
Also ask, are we asking this team to behave as a team while staffing, measuring, interrupting, and rewarding them as individuals?
So what should a team actually do?
Start small.
In your next sprint, pick one important product backlog item and treat it as a Team effort from the beginning.
Discuss the risks early.
Clarify acceptance criteria together.
Identify where handoffs would normally happen and look for ways to reduce them.
If the item gets stuck, swarm on it instead of letting it wait.
Reframe your daily scrum around the sprint goal and the work most at risk.
Point at the board.
Ask what's closest to done, what is blocked, and what the team needs to finish today.
Also, look at your work in progress.
A team that starts too much creates more handoffs, more context switching, or more unfinished work.
Finishing items sooner is often better than starting everything and hoping it comes together at end.
And in your retrospective, look specifically at where work waited.
Where did an item sit without progress?
Where does a handoff create delay?
where did the team discover a problem later than it should have?
Those delays are clues about where teamwork needs to improve.
Scrum gives teams a structure for working together.
But the structure alone isn't enough.
What makes the difference is shared ownership.
Developers who coordinate around the sprint goal rather than their individual tasks.
a product owner who helps the team focus on value, a Scrum Master who help the teams improve, and leaders who create conditions where real teamwork is
actually possible.
At the end of your next sprint, look at the board again.
Are things finishing together, or are they piling up, almost done, waiting for someone?
That board doesn't lie.
and now you know what it's telling you.
Are we focused on what each person started or on the what the team will finish?
If your team recognizes any of what we covered today, working on a Scrum team is designed for exactly this situation.
A private course for product owners, Scum Masters developers, and the leaders who support them.
There's a link below if you'd like to explore bringing it into your organization.
And if you want to go deeper on getting your Scrum team to actually work as a team, watch this next.

3 Strategies for Overcoming Resistance to Change: A Model

Transcript

It's easy to observe that people are resistant to organizational change.
If you've worked in an organization for more than a brief period, you have probably been resistant yourself.
Perhaps you were told you'd have a new manager or that your team would be using a technology, or your company was being acquired.
Maybe your teams had grown in size and was split into two teams.
The most common reason people resist change is a lack of awareness about the reasons for the change.
If your team is being split into two teams, you're much more likely to support that change if you understand why it's happening.
Another reason employees resist changes is the fear of the unknown.
I might be willing to go skydiving, but when it's time to jump out of the airplane, I'll be a lot more inclined to through with it if an instructor has
removed the fear of unknown by telling me exactly what to expect.
The third most common reason employees resist change is a lack of job security.
I've got bills to pay and mouths to feed.
Will I still have a job after the change?
If a change was introduced and I'm worried it could affect my job, I am probably going to resist that change.
Finally, the fourth most common reason employees resist change is a lack of executive sponsorship for the change.
We're all much more likely to support a change if there is at least one key leader advocating for change!
Managers resist changes for slightly different reasons.
They are a fear of losing control and authority.
A lack time.
Comfort with the status quo, not having an answer to what's in it for me, and not being involved in designing the change.
I think these reasons managers resist change are informative because each also applies to scrum masters, product owners,
coaches, architects, lead developers, or others with some added authority or influence.
Let's look at three strategies you can use to overcome these types of resistance, especially resistance to adopting or improving at Agile.
In combination, the three Strategies are designed to convert resistors to advocates by progressing through a sequence of steps needed to make any change.
First, people need to have an awareness that there is a better approach than what they're currently doing.
Second, they need the desire to use that approach.
And once that desire exists, People need ability to the new approach Suppose I've recently learned that vegetables from a home garden taste better than
store-bought vegetables.
That's the first step, awareness.
Next, I need the desire to start growing my own vegetables.
It sounds good, but it's so much work and buying vegetables at the store is so easy.
That is why right now I don't grow my vegetables even though I know they taste better.
I'm stuck at that desire step.
Once I get past that hang-up and I desire growing vegetables, I'll need the ability to grow them.
I will need to know how much to water them, which should be planted in the most sunlight, and so on.
The three steps then are me becoming aware homegrown vegetables taste better, then me desiring to take the effort to grown them and finally having the
ABILITY to do so.
When someone is resistant, take a moment to think about these three stages and see if you can figure out where the person is stuck.
Are they aware there's a better way?
Do they know there is a way but just don't desire to do it?
Or is desire present but the other person doesn't have the ability?
Where someone is stuck will help you know what to do to reduce their resistance.
If someone has stuck at the awareness stage, there are a number of things you can do.
First, be sure to communicate that a problem exists.
Be clear what will happen if the problem is not addressed.
Is a product at risk of being canceled?
Is it losing market share to a new competitor?
At this point, you want to sell the program, not a specific solution to the problems.
To persuade resistors that a problem exists, use metrics when possible.
Instead of saying your product has lost market share, quantify it.
Also, consider exposing resisters to new people and experiences.
Take them to one of the annual Agile or Scrum conferences.
Let them meet people who have successfully made the changes you're proposing.
Are there people in your organization who are further along with Agile you can introduce them to?
I want to share a little tip about persuasion.
Don't try to convince people with a list of benefits.
If you tell me there are four reasons I should make a change I don't want make, I'm going to pick the weakest of your four points and argue about that.
My argument may not convince you, but I'll convince myself that I've parried that point.
And with one less point in favor of the change you want to make, I'll also convince myself I can continue resisting.
So don't try to persuade someone with a list of reasons Agile is better than what you're doing today.
Instead, focus on one compelling reason.
Let's move on to looking at resistance because of a lack of desire.
These individuals are aware there is a better way.
They simply don't want to do it.
We saw some reasons for a Lack of Desire in the list I gave at the beginning of this video.
Someone may be worried about their job.
A leader may fear a loss of control or authority.
and resistance increases when there's no good answer to what's in it for me.
Fortunately, there are a number of things you can do to increase desire.
The most important is to communicate the why behind the change, creating a sense of urgency.
If our product is losing 10% of sales per quarter, I'm a lot more willing to make changes than if we're losing only 1% a year.
To return to my example of learning that homegrown vegetables taste best, suppose you also inform me that they're much more healthful.
That will give me the desire to start my own garden.
Sometimes you can persuade resistors by shifting your attention away from them.
Focus instead on those who are engaged in and enthusiastic about the transition to agile.
Use their desire, to build momentum, since enthusiasm is contagious.
If you can make the change to Agile seem inevitable, that will often reduce resistance.
Our list of reasons for resistance show that some are due to fear.
Address these fears, have private conversations with resistors, and ask what their concerns are.
Never be dismissive of fear and never promise what you cannot, but see if you alleviate fear!
To address concerns about what's in it for me, talk with resistors about the opportunities Agile could bring to their worlds.
Paint the picture that while the future is unwritten, it will bring opportunities to those who notice them.
Increasing someone's desire to change, often by increasing the urgency of the need for that change will move someone to the third step,
having the ability to do what is needed in the new way of working.
If you have a resistor stuck at the ability stage, one of the best things is to provide training and coaching for the person.
Think of better results from my new vegetable garden if a master gardener is there to coach me through it.
A lot of individuals and teams that we work with are in this category.
They have the awareness and desire to change, they just need to acquire new skills to be agile.
If you're not aware of our training options, we have courses for individuals in teams, that range from introductory to advanced with live online classes,
as well as on demand video courses.
You can find out more about what we offer by clicking the links in the description.
You should also create ways for team members to share information with each other.
I remember working with a team that was really struggling with how to incorporate automated testing into a website that had been in place for years and
had developed with no eye toward automation.
Adding automated unit tests was a real challenge for this team.
And I remember the day one of the developers started the morning by announcing that he had some epiphanies the night before and had written 20 unit test.
This was an amazing breakthrough for a team that had managed one automated test the entire previous sprint.
The developer who figured this out shared how he'd done it.
You could tell white bulbs were going off for the other developers.
Finally, create a safe environment for team members to just do it.
Many people have a tendency to hesitate and overthink.
I'd certainly hesitate an over think before jumping out the plane door if I ever did go skydiving.
When team members are practicing a new skill, ensure they know you will value the effort more than the results.
Their efforts at learning new skills should be considered experiments or trials.
More important than succeeding at the new scale is trying until they do succeed.
I always think it's useful to set realistic goals, try to manage expectations of how much a team can accomplish in its early sprints.
Agile can teach us a lot about overcoming resistance.
Attack resistance iteratively and incrementally and you'll succeed.
How have you overcome resistance among any of your colleagues?
Please share your tips and experiences in the comments.
I read and value every comment.
If this video has been useful, click the like button.
And if you're new to this channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agil.
Thank you for watching and I'll see you next time.

3 Things to Try When Teams Write User Stories Too Big for One Sprint

Transcript

When I started doing Scrum, some of my product backlog items were too big to fit into four-week sprints. Over time, I learned ways to split that work into smaller pieces. If I wanted to, I could split those long-ago huge items into product backlog items a team could complete in less than a day.

Now, when you're faced with something you consider too big to fit into a sprint, do three things.

First, try harder to find ways to split it up.

Second, if you don't succeed at splitting it, go ahead and let the item take two sprints.

Third, feel a little guilty about letting something take two sprints. I include “feel guilty” as a reminder that you don't want this to happen too often.

I can promise you that finding ways to split work does get easier the more you do it. Finding the patterns to split the common types of work for your product is worth the effort.

This video is part of a three-part series. Be sure to check out the seven mistakes Scrum Masters and product owners make by clicking the links. Don't forget to subscribe so you don't miss out on future tips to help you succeed with agile.

Thank you for watching, and I'll see you next time.

3 Ways to Get Your Product Owner Engaged During Sprints

Transcript

A big deal is made in the agile world of the phrase inspect and adapt, and that's as it should be.
Inspect and adopt are both important words, but they belong together.
There's no point inspecting if you don't go on to use what you learn to adapt.
And adapting without first inspect results in arbitrary changes.
Unfortunately, some product donors don' take advantages of all the opportunities they're given to inspect.
These product owners often disengage during sprints.
They might show up for a planning meeting and probably for the sprint review, but throughout the Sprint, they're as elusive as Bigfoot.
I've got some tips that will help you if your product owner is not engaged for peak agility.
Hi, I'm Mike Cohn, the author of three bestselling books on Agile and Scrum.
And today I want to help YOU and your Product Owner.
The first thing I suggest is speaking with your product owner about the importance of staying engaged throughout the sprint.
Point out that the team will benefit from feedback as they develop, that team members will have questions that need timely answers,
and that working together is the best way to ensure success.
Also note that I said to speak with your product owner about this.
Email and chat software are great.
They have their purposes.
But I think you'll be more persuasive if you actually speak to the product.
If you can't persuade the Product Owner to become more engaged throughout each sprint, here's an easy next thing to try.
Tell the Project Owner that they will be responsible for running the demo during the review.
I prefer to have various team members run the keyboard to show the new features each worked on.
But when faced with a disengaged Product Owner, I tell the Product owner to be the one with their hands on the Keyboard.
I sometimes go so far as to imply it's a Scrum rule that they give the demo.
It's not, of course.
But I've learned that if they know they'll have to demo the product at the review, they don't disengage as fully during the sprint.
They don' want to embarrass themselves, so they stay more in touch with the work and the team members during this sprint Product donors often disengaged
during sprints because they're busy.
If that busyness is self-made, we can sometimes help by showing the product owner how to be more effective or how delegate parts of the job.
But in other cases, the busy is real and cannot be removed.
If this is the case and your product is too busy to do the work, you may need a different product.
You probably won't be successful at making this change if you go to the product owner's boss and tell them you need someone different.
But you can often succeed in getting a new product donor if your convince the current product to support the idea.
I do that by telling the Product Owner that they're too busy for the job.
They'll nod along as I point out the obvious.
I then tell them that they should instead be the key stakeholder.
I tell him the Key Stakeholder is the person that the whole team, developers, Scrum Master, and product owner are focused on making happy.
The Key stakeholder has the right to get mad if the team doesn't build the features.
I often make it sound like this is an official Scrum or Agile role.
It's not, but you know what?
Maybe it should be.
When I tell the overly busy, disappearing product owner that they may instead be the key stakeholder, the idea almost always immediately resonates.
They see that they can delegate the product owner responsibilities to someone else, yet retain the right to insist the products contain certain features.
This is often enough to encourage them to delegate their job to somebody else or to support the organization in an effort to find someone.
And of course, we should be looking for someone who has time to fully be the Product Owner without disengaging during the sprint.
Have you worked with a product owner who is less engaged than you would like?
What did you do to correct this situation?
Please share your thoughts in the comments.
I read and value every comment.
If this video has been useful, click the Like button.
And if you're new to the channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching and I'll see you next time.

3 Ways to Help a Busy Product Owner

Transcript

Being a product owner is a tough job.
Product owners often carry a heavy burden because they have to get a succession of decisions exactly right.
And they usually need to do this while being extremely busy.
Everyone seems to need some of the product owners' time.
Fortunately, there are things a good scrum master can do to support an overly busy product owner.
And in this video, I'm going to share three of them with you.
Hi, i'm Mike Cohn.
I am the author of three best-selling books on Agile and Scrum.
One of the most useful ways a Scrum Master can help a product owner is by helping them make time for important work that could get pushed aside by the
day-to-day emergencies of work.
For example, suppose your productowner needs to write acceptance criteria for the user stories for their next sprint.
They hope to get it done on Monday.
Doesn't happen.
The hope you get done it on Tuesday.
It doesn't happened.
Wednesday, same thing.
This happens because items on a to-do list are promises to ourselves.
And we don't treat those promises as well as we treat promises to others.
Today, I had two meetings and seven things on my to-do list, such as making this video.
I made all the meetings because I didn't want to let others down.
But four items remain unstarted on My To-Do List.
If your product owner is struggling to fit certain work into their week, offer to schedule a time to meet with them to help do it.
Agree that tomorrow at 2 p.m., the two of you will meet to write the acceptance criteria for next Sprint's stories.
The product will almost certainly make time for that shared activity, whereas they probably wouldn't fit it in if it were just an item on their own personal
to-do list.
Another way you can help a Harried Product Owner is to convince team members that they can answer some questions for themselves.
Some team member fall into a trap of thinking that their Product owner needs to specify every last detail about every product backlog item.
It's not true.
Product owners need to specific the things about a backlog items that are so important that the item will be rejected without those things.
But there are many smaller details about how something is implemented that can best be decided by the team.
For example, imagine a system with a screen that could be sorted by various columns.
Now, the columns can be sort in ascending or descending order.
Which column and which order should be the default?
If the product owner has a strong preference, the Product Owner can absolutely state that preference and the team will need to sort in that order on that column.
But lacking a Strong Preference, a decision by the Team is likely to be just as good as one from the Project Owner.
As Scrum Master, help your team understand this.
And where the product owner has not already stated a strong opinion, encourage team members to make a decision.
They'll probably make the right decision, if not, the Product Owner can redirect the team as soon as they next see the products.
Sure, the team will occasionally have to backtrack and redo some work, but that will probably not be much, probably won't happen often,
and needs to be balanced against all the time saved by not having to discuss every small issue like that in advance.
A third way you can help your product owner is by being on the lookout for best practices.
You are more likely to be attuned to advances in how products are developed.
For example, as Scrum Master, you might have heard about story mapping or job stories shortly after each was introduced.
It could easily be years before such innovations come to the attention of a product donor.
Keep your eyes open for advances in product development, agile, and so on.
And bring time savers to the attention of your product owner.
What do you do to help a busy product donor?
Are there things you've done to your project owner manage all they're expected to do?
Please let me know in the comments.
I read and value each comment.
And if this video has been useful, click the Like button.
If you haven't already, Click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching and I'll see you next time.

5 Common Paths to Product Owner

Transcript

Since product owners are often promoted from within, let's look at some of the roles people have before they become product donors.
If you're new to the channel, I'm Mike Cohn.
I am a co-founder of both the Scrum Alliance and Agile Alliance.
The most common move is from business analyst to product owner.
A business analysts is often the right hand of product-owner, doing portions of job to help the product.
If the current product owner moves on to a new product or company, the analyst often becomes the product donor.
Another common move is from product manager to productowner.
There's no industry-wide agreement on the differences between these roles.
Most common, however, is that product managers are outward-facing, dealing with customers, competitors, pricing, marketing,
and so on.
Product owners are then inward-facing and working with the team and treating the product manager as a stakeholder.
Similarly, a common transition is from project manager to product owner.
As organizations adopt Agile, project managers often become scrum masters, coaches, or product owners.
A fourth common transition is from a user of the product.
This is especially common for internally developed software.
Users will often have the industry knowledge required.
Those who develop a passion for the products often make great product owners.
Finally, development team members can make great product owners.
This is especially true of UX designers and testers.
So should you become a product owner?
First, you'll want to have the skills I've listed and see a path from your current role to becoming a Product Owner.
If this video has been useful, click the Like button.
And if you're new to this channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching, and I'll see you next time.

5 Key Factors for Effective Product Backlog Prioritization

Transcript

Not only do you need to build the right features, you have to build them in the right order. I want to share five key factors you should consider when prioritizing a product backlog. Let's start with a biggie: value. And while it's a given to consider how valuable a feature will be, value is a nebulous term. Most work a team will pursue will be valuable to users, but other work may be valuable just to the team. Still other work may be valuable to both users and team members. For example, consider refactoring: improving the structure but not the behavior of code. Because this makes code more maintainable or easier to change, refactoring is valuable to developers. Still, the cost of refactoring is usually justified by the way it benefits users too. If code is more maintainable, users should experience fewer bugs. Similarly, improved code means that users should receive new features in that area of the product a bit more quickly. The second factor to consider when prioritizing is the cost. The largest cost is usually the team's effort to develop a feature. Most teams estimate the effort product backlog items take in story points, but some estimate in person-days, ideal time, or other similar units. In some cases, there may be additional costs that should be considered. A current common consideration: the ongoing cost of delivering features that rely on various artificial intelligence products. These products often include small per-use fees, but those fees can certainly add up at scale. Regardless of the unit in which a team estimates their product backlog items, that cost to develop and support a feature should factor into an item's priority. For example, an item that a team estimates as five should be prioritized higher than a feature estimated at 20 if all else is equal. This is true whether these are story points, person-days, person-hours, ideal time, or any other unit. A third factor to consider when prioritizing is this: the amount of learning that will occur when the team develops the product backlog item. If you'll learn something important by developing a backlog item, develop that item early so that you have time to act on whatever you've learned. Learn something too late, and you won't have time to benefit from the new knowledge. Learning can take two forms. It can be about the product or the project. Learning about the product occurs when the team develops a feature and receives feedback on it. If users love the feature, do more of it and more things like it. If users don't love it, consider removing the feature or lowering the priority of related features. Learning about the project refers to knowledge team members gain about how to develop the product or solution. For example, suppose a team intends to build part of a product using a technology that team members have never used before. When team members develop the first product backlog item using that new technology, they will learn things about it, such as: Does the technology work as promised? Should estimates for using the new tech be revised? And can the technology be used in other parts of the product or project? The fourth factor to consider when prioritizing is the risk inherent in developing the product backlog item. If something is risky and you need to do it, do it early. You want to know whether that risk is going to materialize. On the other hand, if a feature is risky and you may not need to develop it, delay working on it until it becomes clear you need to do it. The final factor you should consider when prioritizing is dependencies between product backlog items. Some items may not be high priority on their own, but they're necessary for delivering other items. When that's the case, the enabling but lower-priority item needs to be moved higher on the backlog in order to be done before the item dependent on it. As an example, consider a summer camp I helped use Scrum. Among their product backlog items was repainting all the canoes. That was high priority because they wanted to show photos of the shiny, newly painted canoes in their marketing. But painting the canoes was dependent on another backlog item: sand and repair any canoes that needed it. Technically, repairing the canoes didn't need to be done until a day or two before the summer camp opened, but that item was prioritized higher in the product backlog because the marketing photos of the canoes needed to be taken long before that. While all five factors are important, I don't recommend combining them through some fancy formula. The value of a feature and its cost, our first and second factors, are the most important. I recommend continuing to prioritize based on these, but then using the other three factors to adjust priorities. For example, suppose a product owner or product manager has prioritized an item such that it won't be done for another three or four iterations based on its value and cost. At that point, consider learning, risk, and dependencies. Move the item up an iteration or two if any of those factors is significant. Additionally, there are many ways to prioritize product backlogs, including formal prioritization frameworks such as Kano analysis, RICE scoring, and relative weighting. Even with those formal methods, keep the five factors I've mentioned here in mind, even when they're not explicitly part of those frameworks.

5 Myths About Transitioning to Agile

Transcript

I've never been a huge fan of horror movies, but I have always liked Halloween, especially as a kid.
I loved dressing in a scary costume and trying to frighten my friends or other trick-or-treaters.
And I admit to getting a bit of a thrill from walking through a well-executed haunted house.
But there are aspects to every agile transformation that can send a shiver down a spine.
And those moments are not quite so thrilling.
So let's take the fear factor away from five things that might make you want to run for cover along your agile journey.
First, by naming them, and then by talking about why they aren't so scary once you understand how they work.
One scary aspect of transitioning to Agile is that there is no technical design phase.
This can be particularly frightening to architects and other senior technical people.
Just because there's no design in Agiles does not mean that design doesn't occur.
Design does occur!
Technical design on an Agile project is characterized by two attributes.
It is both emergent and intentional.
An emergant design is one that comes into existence over time.
Rather than being done all upfront in a single phase, design in an ongoing activity.
The design emerges through the creation of the product.
But design is also intentional.
This means the design does not emerge randomly.
Design is guided by the intent of the senior technical people on a project, or perhaps even by someone in a designated architect role.
If the Senior Technical People are concerned about a particular part of this system, the product owner should prioritize a product backlog item or two
in that area.
this will allow the team to explore that part some small part of that system.
Doing so will help identify the appropriate design in that area.
Allowing design to emerge guided by the intent of the team will reduce the terror of there being no design phase in Agile.
Another thing some team members might be troubled by is the myth that on agile teams, everyone must be a generalist.
This is frightening because many people have worked years or decades to acquire this specialist knowledge and skills they possess.
Plus, their compensation is tied to that deep expertise.
Additionally, most people don't enjoy all types of work equally, and we'd prefer to spend our time doing the things we excel at and enjoy.
Fortunately, the idea that everyone becomes a generalist on an agile team is completely false.
If I'm coaching a team that has the world's greatest JavaScript wizard, I am going to want that superstar doing amazing things in JavaScript,
not learning how to become a database administrator.
Yes, agile teams value members who have multiple skills, the tester who can write some JavaScript, for example.
This is because it's the easiest way to balance the skills needed on a team.
If everyone is a specialist, a time that needs one and a half testers will be forced to choose to have exactly one or two.
The problem goes completely away when some people on the team have more skills.
A great deal is made of having a cross-functional team in Agile, which means a team has all of the skills needed to produce a finished working deliverable
within the iteration.
A cross functional team requires the team as a whole to have all the skill needed.
Every team member does not need all skills.
When transitioning to agile, management is often chilled to the bone by the idea that an agile team can't plan or predict dates further ahead than the
current iteration or sprint.
Fortunately, this does not need to be the case.
Yes, agile teams give up the false comfort of overly planned projects with intricately drawn Gantt charts showing a precise completion date way in the
distant future.
But that does not mean agile teams are unable to make plans or predict future delivery dates or scope.
A huge benefit of agile is that every iteration, the team turns the crank on the entire development process.
That is, they take an idea usually expressed as nothing more than a simple user story, and they fully implement that feature.
This means that every few weeks, a team can measure its progress.
They learn how quickly they turn raw ideas into running tested features.
Contrast this with a traditional development project, perhaps one with an analysis phase, design phase a coding phase and finally a testing phase.
When that team measures its process over a period of time, they're measuring only how fast they are at doing one or perhaps two types of work.
How fast a team is it doing design?
It says nothing of how fast the team will be at coding and testing.
The key with agile planning is embracing the uncertainty, admitting that it's impossible to know all the functionality that will built before starting
the project, and then adjusting for that in a variety of possible ways.
When teams combine this realization with the ability to actually measure the amount of work done every iteration, it leads to reliable planning,
which should calm the nerves of management daunted by the prospect of having no predictability.
The prospect of transitioning a team or company to Agile is enough to scare the pants off some managers who are concerned they won't have a job after the
transition is complete.
This is understandable.
It would be dismaying to start a transition effort aimed at helping a company knowing that it may make your role superfluous.
However, I can clearly say that I have never helped a company adopt Agile and then seen that company terminate everyone with a certain job title.
Sure, a companies may decide that a specific job is no longer needed or appropriate, but the individuals with those titles still have jobs,
and in most cases I believe they end up with better, more focused jobs.
It can be true, however, that following a transition to Agile, some managers will end up with less direct control over people or decisions.
Some might find this frustrating and they may make the choice to leave the company.
And yes, there are well-publicized stories of some companies abandoning their agile initiatives or deciding to get rid of scrum masters,
product owners, or coaches.
But again, I've never seen an organization lay off an entire set of people in a role because of the transition.
So I think this fear is as misplaced as that of a zombie apocalypse.
Like many people, I really hate meetings.
In fact, it's largely why I do what I.
Most days I have no meetings at all, pure bliss.
But even I can acknowledge that some meetings are important and useful.
And that includes the four standard meetings of Scrum.
The sprint planning meeting, the daily Scum, The Sprint Review, and the Retrospective.
the thought of all these meetings, however, can send some people into a cold sweat.
Here's the problem with Sc rum meetings they have names.
When something has a name, it's easier to attack.
In my experience, many teams who adopt Scrum had more meetings before Sc rum, but the meetings didn't have names and were mostly ad hoc meetings called
to resolve specific issues.
Here's an experiment I like and that you can easily do to see if you're having significantly more meetings with Scrum.
Randomly pick a month on your calendar from before you started adopting an Agile approach.
Open that month up in your Calendar software and add up the time spent in meetings.
Then add up the average time in your Scrum meetings and see how they compare.
Based on my experience, you might well be surprised by the results.
But because these pre-agile meetings were not recurring regular meetings, they didn't have names.
And so they don't stick out in our memories the same way a meeting like Sprint Planning does.
The key for overcoming the terrorizing thought of too much time spent in meetings is keeping the meetings short.
Occasionally, I'll work with a team that I need to encourage to spend more time in a certain meeting.
But most teams spend too time each of the standard Agile meetings.
Once they find ways to shorten those meetings, the meeting should no longer frighten us out of our wits.
While it can be fun to walk through a haunted house or wear a scary costume, most of us can easily remember that it's all make-believe.
Those ghosts, ghouls, vampires, werewolves, and crazed lunatics with chainsaws are not real.
And neither are the five things I've outlined here.
And while no one can be faulted for being afraid at first, education and experience will pull the mask off the myths, leaving us reassured rather than unnerved.