Agile and Scrum Videos

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

All Videos

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?

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.

Transcript

Scrum teams try to finish each sprint, having finished everything they brought into the sprint.
But that can be a challenge in many teams' struggle.
In this video, I'm going to share why I don't think a great Scum team should finish everything every sprint and I'll give you a more appropriate goal.
Hi, i'm Mike Cohn and iIm the author of three best-selling books on Agile and Sc rum.
I help teams succeed with Agil.
At the start of a sprint, a team makes a commitment to deliver a specified amount of work.
The word commitment has gotten a bad reputation in Agile.
So let's address that.
A commitment is not the same as a guarantee.
a Commitment is a promise to do your best.
Consider the word Committment this way.
Think about a cause you are committed to, like the cause of decreasing climate change or providing clean drinking water to everyone in the world.
One of the causes I'm committed to is ending illiteracy.
But I am not guaranteeing to end illitaracy all by myself.
I've committed that cause, but I can't make any guarantees about ending it.
So consider a commitment to a sprint the same way you consider the commitment of a cause.
Not as a guarantee, as promised to do your best.
At the start of a sprint, the team grabs some amount of work and they commit to delivering it.
The product owner commits to leaving the teams alone.
Both of these commitments need to be in place for either commitment to function.
And yet, I don't want a team to deliver 100% on that commitment every single sprint.
Think about that for a moment.
Suppose a team finishes everything every time.
That would tell me they're playing it safe.
They're likely afraid of letting the organization down by not finishing everything.
So instead they let the organizations down, by forgoing chances to deliver a bit more work most sprints, even if some sprint they don't finish everything
A great Scrum team will not deliver everything they commit to in every sprint.
In fact, it's not even desirable.
My goal is 80% of the time the team accomplishes 100% percent of what they pull into the sprint." Note that I'm not saying 100 percent the of time,
the Team finishes 80 percent what say they will.
I am saying that most but not all of that time that Team delivers everything that they plan into a sprint Because there are going to be times when a team
can't finish, either because of a product owner changing their mind or for some other good reason, I don't want the team to feel so much pressure to never
miss anything.
A Scrum Master has to look at a Team missing their goal occasionally as a positive sign.
I understand how strange that sounds, but you want to foster an attitude that a team not finishing everything occasionally is viewed as a sign of the team
trying hard to do more rather than as team failure.
I've been teaching this idea that what a teams commits to in planning is not a guarantee for years.
And long ago, a guy emailed me after taking my CSM course.
He said, hey, Mike, my boss took a different Scrum course, and my bus has a difference impression of what commitment is all about.
I don't remember the boss's email verbatim, of course.
But here's the gist of that boss emailed.
Dear team, Scum is a commitment-driven process.
From now on, any team that fails to make its commitment will answer directly to me, And I will take corrective action up to and possibly including termination.
This boss just ruined things.
The team is now going to go into every sprint planning meeting thinking about having to commit to just enough that they don't get yelled at,
but not so much that the risk not finishing everything.
Sprint planning should be an attempt to figure out a team's likely capacity.
What do team members have a good probability of finishing?
But this boss has in effect told the team to aim low.
I know that saying a team doesn't need to finish everything every sprint is controversial.
Let me share an analogy to help see why not finishing everything, every, sprint, is good.
Think about your favorite sport.
Mine's basketball.
In basketball, a player shoots the ball at the basket and expects the balls to go into the basketball basket.
A good player, however, knows the ball is not going in the basket every single time.
But the player expects to score.
Otherwise, he wouldn't shoot the balls.
When planning a sprint, I want the same mindset among team members.
I wanted them to fully expect to finish what they pull into the sprint.
But what about the product owner in all of this?
For a team to achieve the target of successfully finishing all they plan for most of their sprints, the Product Owner needs to refrain from introducing
change into the sprint.
I tell Product Owners to aim for the same 80% success rate as the team.
A good product owner will keep changes out of the sprint most of time.
I say 80%, but that goal can vary.
Some teams are more interrupted-driven than others.
But the more a product can keep change out the Sprint, the most likely the developers can achieve the goal of finishing 100% of their work 80% time How
is your team doing at finishing what team members bring into a sprint?
How do others in your company respond if a team misses occasionally?
Let me know 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 Agile.
Thank you for watching, and I'll see you next time.

Transcript

Would you like to get a check from Dolly Parton for $500? Yeah, me too.
But Dolley actually figured something out way more valuable than money.
And if you're part of an Agile team, this might be the lesson you've been waiting for.
Back in her hometown, Dolli saw too many kids dropping out of high school.
So she made a deal.
She told every seventh and eighth grader, graduate highschool and you'll get $ 500 from me.
But there was a catch.
You only get the money if your chosen buddy also graduates.
That's it.
Simple.
But the results?
Stunning.
The dropout rate went from 35% down to just 6%. Why?
Accountability.
When your success is tied to someone else's, you step up.
Look out for them.
Work together.
Now, what if Dolly made that same offer to agile teams?
Because the best agile team, they succeed or fail together.
No one wins when developers finish on the last day of the sprint and leave the testers scrambling with no time to test.
But when accountability is shared, magic can happen.
Testers identify edge cases early.
Developers write more unit tests.
Sometimes they even jump in to help with the testing, because they're not just checking off tasks.
They're owning outcomes.
So how do you create that buddy system vibe on your team?
Here are a few things that could help.
Keep backlog items small, smaller pieces flow faster.
Hand off work early and often.
You don't have to finish a whole item before collaborating on it.
Communicate a lot and use the right channels.
Some things need a quick conversation, others just need message.
Overlap your work.
Design test code.
Don't treat them like separate stages.
And of course, meet daily.
Use that time to stay aligned and accountable.
So no, Dolly Parton probably won't write your team a $500 check.
But if you build a culture of shared responsibility, you'll deliver better products faster and with less stress.
I'm Mike Cohn, agile coach, author, and someone who really likes dolly's thinking.
If you found this helpful, I share one short agile tip every week, straight to your inbox.
Over 100,000 people already subscribe.
You can join them by clicking the link in the description.
Thank you for watching.

Transcript

Let's talk about who does what on a Scrum project.
There are only three roles on the Scum team, Scummaster, product owner, and developer.
Hi, I'm Mike Cohn, a founder of the Scrum Alliance and the Agile Alliance.
I help teams succeed with Agil.
In 2020, a new version of the Scrum Guide stopped referring to the scrum master, product owner, and developers as roles.
It instead started calling them accountabilities.
The change was to allow for the idea that one person may fulfill more than one set of accountibilities.
But I find that needlessly confusing.
There is nothing about the word role that says one person cannot fulfill multiple roles.
For example, there are plenty of examples of actors who played multiple role in the same movie.
In The Wizard of Oz, Ray Bolger played the roles of the scarecrow and a worker on Dorothy's family's farm.
Eddie Murphy often plays more than one role in his films.
And for the Wayne's World and Austin Powers movies, Mike Myers played the roles of actor and writer.
So there's nothing about the word role that restricts someone from fulfilling only one roll.
There can of course be disadvantages to someone sharing multiple roles.
With that, let's talk about the three roles on a Scrum project.
First are the developers.
A developer is anyone responsible for developing or creating a solution for whatever we're trying to accomplish.
So this doesn't mean just programmers.
If we are a marketing project or marketing team, developers could be a copywriter, a graphic designer, and an ad executive.
Developers are the people developing the solution.
I know a law firm where developers are three attorneys and a few paralegals.
The developers, are solving a problem that's been identified by Scrum's second role, the product owner.
A product owner decides what needs to be built.
The productowner is responsible for deciding the big overarching goal of the product.
I want this.
the Product Owner should avoid micromanaging exactly how the goal will be achieved.
That's the responsibility of developers.
So a Product owner says, here's what I Want.
Developers decide how to go about doing that.
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.
Our third role is the Scrum Master.
The Scum Master is a coach for the team.
This Sc rum master helps developers perform to the best of their abilities.
the scrum master does the same for their product owner.
Good scrums masters also coach the rest of the organization, helping them get better at their jobs and helping then be less in the way of scrumb teams.
So those are the three roles, developers, product, owner and scrummaster.
There's actually one more role to be aware of, the Scrum team as a whole.
The Scum team is not precisely a role on its own because it's a combination of roles.
the scrumteam includes the product owner, The scrummaster and the developers.
It's everyone with specific responsibilities on a Scumm project.
What role do you fill on your Scrum team?
Or do fill multiple roles?
I guess I should say accountabilities.
What challenges are you facing in those roles.
Let me know in the comments and I'll make some additional videos on those challenges.
If this video has been helpful, 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.

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.

Transcript

I just discovered the best way to explain the iterative and incremental nature of Agile, perfect for teams and even managers.
I've taught teams how to use an iterive and an incremental process to succeed with Agiles for 25 years, but I think I have only just found the perfect
way of explaining how iteratives and incrementals differ and relate.
By the way, my name is Mike Cohn, and I'm the author of three bestselling books on Agile and Scrum.
I help teams succeed.
The film shows Seinfeld developing a completely new act.
He couldn't rely on jokes from his stand-up routines from a decade earlier.
He begins by performing for just a few minutes at small comedy clubs.
After each performance he refines the wording, sequence, and pacing of his jokes.
he's iterating over each joke.
As he finds material that works, he adds time to his shows.
His performance goes from five minutes to 10. He is incrementally building his show.
he continues adding increments, new jokes, until he achieves his goal of more than an hour of new material.
Refining each joke is iterating.
Adding jokes bit by bit until you have a full show is incremental.
This example also shows why iterative and incremental aren't very good on their own.
Imagine a comedian who only iterates over existing material, but never adds any new material.
Or imagine one who keeps adding new jokes, But never iterated to ensure each is funny.
Another thing that comedian movie teaches us is the value of experimenting.
When Seinfeld and another comedian profiled in the film perform, their shows contain a mix of material they know will get laughs and some new joke they're
trying out.
Experimenting is equally important in product development.
Teams can experiment with their process or the product by delivering small partial features to confirm their value before going all in.
Who knew that being iterative and incremental helped as much in comedy as in product development?
If you want more resources that help you explain Scrum and Agile, visit the Agiles Resources section on our website.
It's free and has a number of articles introducing Agil and Scum frameworks.
You can also use the search function to ask questions, and our AI search will deliver personalized answers fast.
See the link in the description.

Transcript

The biggest myth about sprint planning is that team members need to create a sprint backlog that contains every single task they'll perform during the sprint.
This is both untrue and undesirable.
You don't want a team to identify every last task that'll performed during this sprint First, it's impossible.
It doesn't matter how smart team member are or how much time they spend thinking about their work.
They'll overlook some tasks.
or something will emerge during the sprint.
Instead of trying to think of every task, I encourage teams to thing of the big tasks and the obvious tasks.
You want the team to thinking of big task because these are the tasks that will determine if a specific product backlog item will fit in the Sprint.
And you want team members to think of the obvious ones because, well, why not?
They're obvious.
So you might as well add them to the sprint backlog.
What you don't want to do is have the team then spend another 15 minutes thinking hard about what else there may be to.
Instead, acknowledge that some tasks will be discovered during the Sprint and be comforted by the fact that they probably won't be the big tasks.
One thing you can do to assist a team with this is to look for patterns in the type of work the team does.
Nearly all teams will have some type work that will be performed multiple times.
For example, a software team I worked with discovered that most of their product backlog items had a task for coding the user interface,
another for code the backend, One for creating the test plan.
Another task for automating the tests.
And finally, tasks for executing the tasks, fixing any bugs, and rerunning the task to confirm that everything had been fixed.
That team was able to apply this pattern over and over.
Occasionally, a task could be left out or another was needed, but this task list served as a good starting point for an immense number of their product
backlog items.
Using just this pattern helped them think of the majority of work that would be needed on any product backlog item.
Sure, they might have overlooked tasks, some of which they could have identified if they'd spent an additional 15 minutes thinking,
but coming up with those extra tasks would not have been worth the bloated meetings.
When cutting corners though, it is essential that the team not plan the sprint overly full.
After all, if you know you haven't thought of everything, because you didn't try to, and because doing so would be impossible,
you need to leave room for those tasks to be added to the Sprint once they're discovered.
Some managers looking at the team from outside may take issue with this.
They see a sprint that appears to be lightly filled and think team members are taking it easy.
The Scrum Master will need to explain to these managers that the teams is instead using their time responsibly.
Team members saved time in sprint planning by not pursuing the impossible goal of thinking of every task and are now embracing the certainty that unidentified
tasks will be uncovered.
It is more efficient for the team to accept that than try to eliminate uncertainty by attempting to think of everything.
The sprint backlog is meant to emerge during the sprint.
During the planning meeting, team members think about all the big and obvious tasks.
Their goal is to select the right work for this sprint and to understand that work well enough to be confident they can complete it.
But as the Sprint progresses, team members' understanding of the selected work improves.
That means some new tasks will be added to the sprint backlog, and some tasks may be removed or their estimates could change.
The sprint back log is a tool for the team to use to think about and organize their work.
Don't fall for that myth.
Goodadsel teams allow tasks to emerge rather than trying to thing of everything upfront.

Transcript

One of the most widely cited laws in software development isn't true anymore.
The cost of change curve?
It's outdated, and most managers are still managing as if it isn' t.
For decades, we've believed that the later you make a change, the more expensive it becomes.
That idea came from Barry Beam's research in the 1970s and 80s.
And at the time, it was absolutely right.
Software was expensive, tools were primitive, testing was manual, integration was painful, deployment was risky.
If you found a major requirement change late, you could be looking at months of redesign and retesting.
Late change really was disastrous.
But here's what we forgot.
That curve was a snapshot, not a law of physics.
And the economics of software has changed.
Tools flattened the curves.
Modular architectures flatten the curve.
Automated testing flatten to the curb.
Then agile arrived.
Agile didn't magically make change cheap.
It took advantage of what was already becoming true.
Kent Beck captured this in the subtitle of his book Extreme Programming Explained.
Embrace change.
That wasn't motivational.
It was economic.
Now, AI pushes this even further.
AI flattens the cost of change curve even more.
AI reduces the human time required to write and revise code.
That sounds incremental.
It isn't.
When coding gets faster, experimentation gets cheaper.
Trying an idea is cheaper, revising it is deeper, starting over is cheap.
AI makes iteration inexpensive enough that the traditional fear of late change starts to disappear.
And when that happens, the bottleneck shifts.
the cost of change becomes less about writing code and more about waiting for feedback.
The primary cost to change today is increasingly feedback delay, not development effort.
This doesn't mean software development is easy.
Understanding users is still hard.
Discovery is so hard, decision making is too hard but the hard parts have moved.
The hard part now is learning what to build.
Once you have feedback, acting on it is cheaper than ever.
That's the real shift.
So what does this mean for managers?
Many organizations today still have approval processes designed for a world where late changes were catastrophic.
In many companies, the slowest part of delivery isn't coding, it's waiting for permission.
If the cost of change has fallen and AI is accelerating that decline, then the biggest risk isn' changing too late.
The biggest risk is learning too late.
Requirements don't need to be perfect.
They need be revisable.
The cost of change curve hasn't disappeared.
But if you still manage as if change is catastrophic, you're using a mental model that's decades out of date.
In modern software development, especially in the age of AI, adaptability beats completeness of requirements.
Stop trying to perfect requirements.
Instead, perfect your feedback loop.

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.

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.

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.