Agile and Scrum Videos

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

All Videos

Transcript

There is clearly a Goldilocks size for Agile teams.
Not too big, not too small.
But how many people is that?
It's fewer than you may think.
Hi, I'm Mike Cohn, and I am the author of three best-selling books on Agil and Scrum.
I help teams succeed with Agiles.
And teams can succeed more easily when they're the right size.
For most projects, that will be four or five people.
But there are times when you may want a larger team.
How you decide between a small team and a large but less productive team depends largely on whether you need the project done as quickly as possible.
Think about the movie Apollo 13, which tells the true story of the mission control ground crew who are trying to save the lives of three astronauts.
The astronauts face a severe risk of running out of oxygen.
On a project like that, finding a solution quickly is more important than doing so with the least number of person hours.
And so you'd want a large team, even if each person is a little less productive.
Much more often, we're on projects on which we can sacrifice a bit of time to value in favor of the cost savings of a more efficient team.
Let's look at some research as well as some common sense about why I say a team of four to five is best.
Let us start with the research, beginning with a study undertaken by Harvard professor Richard Hackman and colleague Neil Vidmar.
They assigned tasks to teams of various sizes, and then asked everyone two questions.
Was the team too small to achieve the best result?
And was the Team too large to the achieve best results?
Charting the answers they received to those two questions revealed the optimal team size.
The first line shows how people responded to question about the teams being too-large.
Almost no one thought a team of two people was too big.
But then the line rises dramatically, especially above five team members.
Conversely, regarding the line showing responses to the question about the team being too small, many participants felt a team of two was too,
but very few thought a two of seven was small.
Where these two lines intersect is what the researchers considered the optimal team size – 4.6 people.
The company QSM, founded by Larry Putnam in 1978, has built one of the largest databases of metrics from software projects of all sizes and methodologies.
Kate Armell of Qsm studied over a thousand projects in their database.
To test the idea of 4.6 being a good team size, Armelle divided the projects into those with four or fewer team members and those of five or more.
The larger teams did finish in slightly shorter time frames, but depending on the size of the project, she found large teams were three or four times more
expensive with two to three times, more defects.
Okay, so there's some research showing that teams of four to five are the most productive.
Does this team size fit with common sense?
I think it does.
Teams of 4 to 5 are far smaller than the Scrum Guide advice of fewer than 10, which could be 12 if the scrum master and product owner are counted separately.
I'm not aware of any studies that show 10 to 12 being a good team-size.
However, the Scrum Guide doesn't recommend teams that large.
It simply defines 10 as a typical upper limit.
That's bigger than I'd recommend, but it's okay.
A common approach to thinking about team size is to consider the number of communication paths within teams of different sizes.
On a five-person team, there are 10 communication path, as each person can and should communicate with each other person.
That means a six-person team will have 15 communication paths, and a seven- person team with have 21. The formula for this is the product of n times n
minus 1 divided by 2, where n is number of people on the team.
Clearly, as team size grows, the overhead of all this communication can really impair productivity.
Larger teams also suffer from what has become known as social loafing, which was first observed in research in 1913. Social loafin refers to individuals
putting in less effort when their work will be judged as part of a group.
If you were ever assigned a project back in school, you probably experienced social loafing.
You or your teammates put less into the group project than you would have into a solo project.
I think about long ago helping a friend move into his new house.
There was a group of us helping and so I put in less effort than if I'd been helping alone.
Because the little bit longer it took to move everything wasn't directly observable as my own fault, I took it a bit easy.
Ivan Steiner formalized social loafing, communication overhead, and any number of other factors into a formula.
He said that actual productivity is equal to a team's potential productivity minus losses due to faulty processes.
Losses due failty processes are anything that prevent a teams from performing at its theoretical best.
In addition to communication overhead and social loafing, low morale or a lack of motivation could reduce actual productivity,
so could burnout, lack clarity, or many other things.
Steiner's formula says a team will never perform at its theoretical maximum productivity.
Does the idea of teams of four to five members pass the sniff test?
Does it make sense with your experience?
It does with mine.
Small teams sure seem faster to me, and we've seen some reasons just now to believe that's true.
We also took a look at some research indicating the same.
What do you think?
From your experience, what team sizes seem the most productive?
Please share your thoughts in the comments below.
And if this video has been useful, click the Like button.
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

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.

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

Transcript

A lot of leaders think their job is to ask for what they want, and the team's job to figure out how to make that happen.
Sometimes that works, but often it doesn't.
And when it does, that's the moment when planning needs to become a shared problem.
A leader says, I need all of this by this date.
The team looks at it and says we can't do all that by then.
And at that point, many leaders make the same mistake.
They push harder, they restate the deadline, the repeat the importance, ask for more effort, more creativity, commitment.
But once a team has told you the work won't fit, pressure is usually the wrong next move.
It doesn't make the works smaller, it doesn' remove the dependencies, doesn eliminate the uncertainty.
The pressure just makes the conversation worse.
What should happen instead is this.
The leader's request should start the discussion, not end it.
That is one of the most important shifts a leader can make.
Because when the work doesn't fit, the goal is no longer to force a better answer.
Now, I want to be fair to leaders here.
Leaders usually ask for too much because they care.
They want the business to succeed, they want solve the customer's problem, and they're also often reacting to a very real concern.
Teams aren't always as predictable as leaders need them to.
So this is not a story about bad leaders and innocent teams.
This is a system problem.
Leaders push too hard because they're worried the team won't deliver.
Teams become less reliable because their being pushed too-hard.
And around and around it goes.
The way out starts with curiosity.
When a team says the work won' fit, a leader's job is to get curious, not judgemental.
Don't ask, why can't you do it?
But instead ask what's making this too big.
What part is driving the complexity?
What's essential here?
what would be a good enough version?
Those questions change everything.
Now the team is not defending an estimate.
I was working with a team developing human resources management software.
They were adding a feature to let a manager approve an employee's request for time off.
The team's estimate was higher than the VP of product wanted.
Instead of getting mad, he got curious and asked why.
The Team explained that a big part of the effort came from an edge case, employees who had two managers.
Now they had to decide how approval should work in that situation.
Would both managers need to approve the request?
Would some organizations want approval from only a primary manager?
Would others accept approval from either manager?
Those questions were enough to push the feature beyond the desired timeline.
So the VP made a trade-off.
For the initial release, they would not support the full two-manager case.
If an employee had two managers, the manager who had first been assigned to that employee would approve their request.
Full support for the more complex case would come a sprint or two later.
That's what good leadership looks like in planning.
Not insisting on the original request, not arguing with the estimate, helping the team find the best solution to the real problem.
It's great when you can get everything you want in the time frame you wanted.
But when that's impossible, a leader and the team need to work together to find the best solution.
And this is why planning has to become a shared problem.
The leader owns the outcome.
the Team understands the work.
You need both.
A leader who just throws a request over the wall isn't really leading.
And a team that just says no without helping explore options isn' really collaborating.
Better planning happens when both sides share the solution.
So when the team tells you the work won't fit, don't treat that as resistance.
Treat it as information.
They're showing you where the real problem is.
Your job is to help the Team decide what matters most, what can wait, and what version solves the problem well enough right now.
Because planning works better when their request belongs to the leader, but the Problem belongs everyone.
If you can make that shift, you'll get better plans.
You'll better decisions.
And very often, You get a better product too.
Because the best leaders don't just ask for more.
They help teams find what matters most.

Transcript

You can only get so far by attempting to manage people's performance through control.
It is far better to lead or manage by defining the context of their work.
I was fortunate to learn this lesson early on when I worked in a fast food restaurant.
My manager Jim trained me that each burger was to be dressed with two leaves of lettuce, two tomatoes, three slices of onion,
and three pickles.
Jim didn't drill this into my head.
Jim did not inspect my burgers.
Instead, he explained the context, the reason why our burgers should be dressed exactly that way.
He told me to imagine a customer who orders a burger with extra pickles, and a cook who loves pickles and puts five pickles on by default.
When asked for extra pickles, that cook puts on seven.
That's too many for this customer, who on a return visit asks for light pickles.
The burger is made by a different cook who would normally put on three pickles and so puts just one when asked.
My boss gave me a vision of a hapless customer alternately ordering extra or light pickles and never getting what they want due to the preferences of the cooks.
I remember the context Jim defined decades later.
How long would pimply-faced me have remembered these amounts if my boss had merely presented them as rules?
My manager defined the contest of my customer, a hungry person seeking consistency.
And that was enough.
Weeding through context can involve a mix of things, such as defining the wildly important goal or wig the team is working toward,
helping people deeply understand and empathize with users, guiding a team in defining its igniting purpose and intrinsic motivation that inspires exceptional performance,
and understanding the strengths and weaknesses of competitive products.
Leading an agile team, whether as a manager, executive, scrum master, product owner, team lead, or other, is different.
It requires new skills.
A self-organizing team resists rules and thrives on creativity and freedom.
Leaning such a team by providing context can also cause it to excel.
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

Scrum, Agile, how do these terms relate?
Is Scum Agil?
is Agiles Scumm?
I'm going to tell you and I am going make it memorable so you never forget or confuse the two again.
Hi, I Mike Cohn and the author of three best-selling books on Agils and Scrums.
I help teams succeed with Agille.
To see the relationship between Agilles and Scrums, let's talk about your refrigerator.
If your refrigerator were to break, you'd want to replace it.
You could buy a new fridge online, or you could go to the local appliance store and check out the various models in person.
Let's go to the appliance store.
As you enter the store, you might be tempted to turn left.
That's where the big screen TVs are.
But you're here for a fridge, so you head into that part of the Store.
Once in the refrigerator section, You'll notice a bunch of different brands of refrigerator.
There's LG, General Electric, Whirlpool, Samsung, Jenn Air, Bosch, Viking, Hyre and more.
Now, let's suppose that instead of your refrigerator breaking, it was your team's software development process that broke.
You can't buy that at the appliance store, so you head into the process store.
Again, don't make a wrong turn, you want to find the Agile department.
Don't go over there, that's the waterfall department, It's full of cobwebs and skeletons, nothing gets finished over here.
So you find Agiles department and you see a bunch of different brands of Agil.
Of course there's Scrum, but there are also Kanban Extreme Programming, DSDM, Feature-Driven Development, Safe, Large-Scale Sc rum,
Crystal, and more.
The point of this story is that Scum is a brand of Agile.
Just like Samsung and Whirlpool are brands of refrigerators.
I think of Agile as this great big category term.
And within it are a bunch of different brands.
Scrum is just one of those brands, so are Extreme Programming, Kanban, Scaled Agil, and the others I listed.
So if you tell me your team is Agiles, that doesn't tell as much as if your say your teams use a Sc rum.
A Scum team will always be Agils, but not all AgIL teams, use Scums.
Let me know in the comments what brand of Agile you're using.
And if you have any questions or comments about Agil or Scrum, you can leave them down below, and I'll help if I can.
I read every comment.
If this video has been helpful, click the Like button.
and if your new to this channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agiles.
Thank you for watching and see you next time.

Transcript

Many years ago, I heard a conference speaker say agile teams don't plan.
He was wrong, though.
he hadn't noticed agile team's planning because agile don's have a big upfront planning phase.
Instead, agile plan frequently, but always in small doses.
Hi, i'm Mike Cohn, and I'm the author of three best-selling books on agile and Scrum.
I help teams succeed with agile.
On an Agile project, planning occurs at multiple levels.
At the smallest level is the daily planning occurring in a team's scrum or stand-up meetings.
Every day during these short meetings, team members discuss problems, progress, and plans toward achieving whatever goal they've selected for this sprint
or iteration.
Sometimes a lack of progress may force a team to shrink or change its goal.
Other times, team members may conclude that they can strive for a larger goal!
While a teams daily plans are made almost exclusively for its team-members, they are communicated to those outside the team.
Usually this is done through a Team's Kanban or Task Board or by allowing outsiders to observe the daily meeting.
Daily planning occurs within the context of a sprint or iteration plan.
This plan is made at the start of each new iteration during a dedicated sprint planning meeting.
Based on the work accomplished in the just-finished iteration, the product owner suggests a new goal for the team to target in this new integration.
Team members assess the proposed goal and collaborate with the Product Owner to define a New Sprint Goal that is acceptable to all.
Now that the sprint goal is set, team members create a plan for how they will achieve it.
Usually this involves selecting a set of product backlog items, often in the form of user or job stories, but stories are not required.
What is required?
A goal and a Plan for How to Achieve It.
To know which and how many backlog items they can complete within an iteration, most teams identify the steps, or tasks,
required to deliver those items.
And in many cases, teams will take a further step of very roughly estimating how long each task will These steps of identifying tasks and rough estimates
are not done so that management can use them as a club with which to hit the team.
Rather, the tasks an estimates, are used by team members to assess the amount of work they are bringing into a sprint.
It's worth repeating that tasks in estimates or not required as part of sprint planning.
All that's required is that the teams have some degree of plan for how to achieve the sprint goal they've selected.
Most teams will communicate about their sprint plans by sharing at least the sprint goal and often the product backlog items selected to achieve that goal.
Tasks and estimates, if created, are normally reserved for team members.
In some cases, though, those outside the team can log into a team's backlog management tool and see the tasks and effort remaining,
although they are not commonly encouraged to do so.
Moving out a level in our planning onion, many teams do milestone planning.
They identify a target date and scope a bit further out than a single iteration.
Many teams and organizations find two to six months an appropriate balance between the foreseeable future and long-term plans.
Not every Agile team plans at this level and not all organizations require this type of look-ahead.
Many, however, find it a useful hedge against the Cheshire Cats admonition in Alice's Adventures in Wonderland that, if you don't know where you're going,
any road will get you there.
A plan at this level should be expressed as a set of outcomes or objectives the organization or team would like to achieve.
For example, let's say a team working on a SaaS product has an objective of increasing the percentage of site visitors who sign up for a free trial from 20%
to 30%. There are likely many ways the team can achieve this.
Clearly expressing what the desired outcome is, but leaving to the teams how it will be achieved is better than listing specific product backlog items
the Team must do in the hope of achieving the increase.
A mid-range goal, I prefer quarterly, establishes a vision for the team to work toward.
This avoids the short-term sub-optimization that can occur when a team bounces every couple of weeks from one sprint goal to the next.
Milestone goals are definitely communicated outside the team.
It's common that other parts of an organization will have work to do to fully capture the value delivered by the new capabilities,
so they will need to have advanced notice of what is being targeted by when.
Moving out a layer, we see roadmapping.
The product roadmap describes how a product is expected to evolve over time.
This level of planning is normally disconnected from the product backlog.
In other words, the roadmap usually won't contain specific product-backlog items because at this level, their product's goals have not yet been turned
into specific features that will be added.
At the roadmap level we also see less team involvement in the plan.
The roadmap will usually be created by the product owner, who may request some input from a scrum master or lead developers.
They may, for example, be asked to make a loose forecast of future velocity if three team members are added.
Product roadmaps are definitely communicated outside the team.
In fact, road maps are most commonly created for outsiders rather than for the members working on the project.
I like Roman Pickler's advice to create goal-oriented road map.
For increasingly distant timeframes, list one or more goals, any specific features intended to support that goal, and metrics that can be used to measure success.
Having reached the roadmap level, did you notice that as we move from the inside of the onion to the outer layers, the level of detail decreases?
The innermost level daily planning is super granular.
Who is about to work on what today?
Outer levels forego that detail in favor of a bigger picture.
Similarly, as we move to the outer levels, the target audience of a plan shifts from team members to outside stakeholders.
This approach of differing timeframes, audiences, and detail is central to ADSL planning.
Moving beyond the roadmap level is portfolio planning.
This entails determining which products fit with customer expectations of a company.
It would be unexpected for the car manufacturer Ford, for example, to start selling breakfast cereal.
Their reputation in building cars wouldn't carry over into breakfast cereals.
Typically, only a team's product owner will be involved in portfolio planing.
At the outermost level of the planning onion is company strategy.
This will almost universally be created outside the team, but it should guide the Team, and especially its Product Owner,
in the Planning done at the inner levels.
What challenges does your team face in planning at any of these levels?
Let me know in the comments.
I read every comment, and I may make a new video about some of the challenges you mentioned.
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.

Transcript

To see the times when job stories may be better than user stories, let's look at some sample job story and their corresponding user story.
Let's start with this job.
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 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.

Transcript

When a Scrum team slows down, we often blame obvious causes.
Shifting priorities, unclear roadmaps, too many meetings.
But sometimes the real problem is not outside pressure.
It's role confusion within the team.
That's what this video is about.
Think of it as a diagnostic tool to help you spot problem patterns within your team I'll walk through different roles, what can go wrong,
why it happens, and the signs to watch out for.
This isn't about pointing fingers.
Most of these patterns come from good intentions.
The goal is to help you see where role dynamics might be holding your team back so you can start the right conversations.
I've also linked to resources for each role in the description so that you dig deeper.
Let's look at how different role might unintentionally be the one holding the team.
Let's start with the product owner.
One of the first things I check with struggling teams is whether backlog items are truly ready.
If your team spends the sprint chasing the Product Owner with, what should the system do here?
How should this report change?
That's a red flag.
The lack of clarity upfront leads to confusion and inevitable delays.
Product owner availability is another big problem.
When the product owner is overloaded or hard to reach, even quick decisions get stuck in limbo, slowing everything down.
But there's a flip side to this.
Teams that expect the Product Owner to specify every tiny detail.
That's the fast way to overwhelm the Project Owner.
If it's small user interface change or a technical decision, the team should be empowered to decide.
Good product owners delegate when it makes sense, but they stay accountable for the overall product direction.
Trouble comes when they try to answer everything themselves or step back so far that no one is steering.
And of course, there's scope creep.
Adding new scope mid-sprinter struggling to prioritize leaves teams spinning their wheels.
Wait too long for perfect clarity and you stall just as badly.
So what's the balance?
Product owners should make the big calls that set direction, while the team owns the day-to-day choices in their area of expertise.
If you're experiencing issues like the ones I've described, it's time to reset this balance.
A clear sign of trouble with the Scrum Master role is when impediments never go away.
If the same blockers appear sprint after sprint, the scrum master may not be clearing the path.
You can also spot Scum Master issues at team meetings.
When sprint planning drags on, daily scrums feel pointless or retrospectives never lead to change, quite often it's not a problem with a meeting,
but with facilitation of that meeting.
Micro-management is another warning sign.
The scrum master's role is to coach and support, not assign tasks or direct every move.
If the team feels managed instead of empowered, something's wrong.
if scrumb events are skipped or just treated as formalities, it's time for the scrumm master to reinforce why they matter.
Protecting the team from distractions is crucial.
If stakeholders can pull people away mid-sprint for unrelated work, the Scrum Master is not shielding team effectively.
And continuous improvement matters.
if retrospectives don't lead to real change, The Scum Master should help create a culture where the Team is always looking for better ways to work.
If developers work in silos without sharing knowledge or helping each other, progress slows and quality drops.
Ownership of quality is another key marker.
When developers see quality as the tester's job, bugs and technical debt pile up.
Specialization can be good, but not if it's rigid.
In Scrum, you want people who will pitch in outside their core skills when the team needs it.
If everyone only sticks to their part, bottlenecks form quickly.
If developers focus only on finishing their individual tasks rather than on achieving the sprint goal, you may end up with a set of completed items that
don't add up to real value.
And if blockers or progress aren't communicated, problems surface too late to fix easily.
Finally, how developers handle feedback matters.
Defensive reactions in code reviews or retrospectives stall improvement.
The best teams treat feedback as fuel for learning, not something to defend against.
One thing I often see with analysts is the tendency to over-specify requirements.
It comes from a good place.
They want to be thorough.
But it can lock the team into decisions too early and slow the teams down.
If an analyst works mostly in isolation, there's a risk the requirements they create don't reflect what's technically possible or even what the user really wants.
And if they act as the only channel between the developers and the product owner, you get a communication bottleneck that slows everything down.
Good analysts adapt requirements as new information comes in.
If nothing changes from the original plan, even after the team learns more, that's a warning sign.
And of course, clarity is key.
if the Team is working from ambiguous requirements, You can almost guarantee confusion and rework later.
When testing happens at the very end of the sprint, you can guess what happens.
Bugs show up late, quality suffers, and fixing problems is more expensive and disruptive.
I've seen teams where testers are treated almost like outsiders, brought in only after the work is done.
That's a huge missed opportunity.
Testers should be part of a team from the start, contributing to planning, refinement and design conversations.
If testing is entirely manual, that's another red flag.
Without some level of test automation, it's incredibly hard to keep up with regression testing while also covering new features.
I also look at how clear acceptance criteria are.
If testers aren't confirming those details with the product owner and developers early, you'll get misunderstandings, rework,
and frustration.
And lastly, if issues aren't raised as soon as they're spotted, you end up with a last-minute scramble.
The earlier a bug is identified, the easier it is to fix without derailing the sprint.
Stakeholders play a huge role in a team's success, and one of the biggest issues I see is unclear or constantly shifting priorities.
When priorities change without explanation, the team loses focus and momentum.
Micromanagement is another trap.
If stakeholders try to direct the teams' day-to-day work, it undermines both autonomy and the scrum roles.
But the opposite is also a problem.
When stakeholders aren't engaged enough, if they skip reviews or don't give timely feedback, the team risks building something that misses the mark.
Bypassing the product owner is another common problem.
It might seem faster for a stakeholder to just go straight to a developer with a request, but it disrupts the flow of work and the prioritization process.
And then there are unrealistic expectations, wanting more than the team can possibly deliver in the time given.
That's a quick way to hurt morale and erode trust.
If you recognize yourself or your team in any of these patterns, it's because they're common and they come from a team's good intentions.
The key is building a shared understanding of roles, what great teamwork looks like, and how to support each other better.
It's one reason we created Working on a Scrum Team, a two-day live online course designed for real Scum Teams, not just for individuals.
I'll link to the course page in the description.
No single role makes or breaks a Scrum team.
But when roles aren't aligned, everything slows down.
The fastest way to get back on track is to fix that misalignment together.
In this class, you'll build a clear shared understanding of Scum roles so people stop stepping on each other's toes.
You'll get practical strategies for improving collaboration between developers, testers, analysts, product owners, and stakeholders.
and you'll leave with a stronger sense of ownership and confidence in how to work together.
Whether your team is brand new or has been stuck for a while, this course gives you the reset you need to get aligned and deliver results.
Want help spotting these patterns in your teams?
Drop a comment below or message me.
I've seen these issues in teams of every size, and I'm always happy to help you figure out where to start.

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 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.
OK, 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, can request a password reminder so, that i can log-in even if I forgot 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 onscreen acknowledgment so the user knows they're valued.
The story says this happens on the nth time, because at the time the story's written, it's not important if this is the third,
the fifth, or the 20th, 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.

Transcript

No one expects agile improvement to happen by accident.
Most teams know it takes effort.
You might try new tools, invest in training, adopt Scrum, or some other framework.
Maybe you bring in a few agile coaches.
Those are great steps, but they don't guarantee results.
After more than 20 years working with agile teams in every kind of environment, from regulated industries to fast-moving startups,
I've learned that agile success depends on five essential pillars.
Mindset, practices, roles, teamwork, and support beyond the team.
If even one of those pillars is missing, you'll feel it.
Progress will slow, teams will get frustrated, stakeholders will start to doubt the value of Agile.
But when all five pillars are in place, Agiles thrives.
Let's take a look at each.
Agile isn't just a checklist of practices, it's also a mindset, which is our first pillar.
It's about embracing change, collaborating openly, and seeing failure as a chance to learn.
But this mindset doesn't happen automatically.
And I've heard the frustration.
Leadership says we're agile, but still demand waterfall-style deadlines.
Teams do agile practices but they don't believe in them.
Mindset is the why behind every decision.
Without it, team members don't know why new practices are being put in place.
Even if you focus on improving practices through workshops and training, without an agile mindset, teams will eventually disengage.
Ads will become something they're told to do, not something that they own.
If you're leading change, you can avoid this by helping your teams understand the purpose behind the process.
You can also run a simple retrospective style session where teams list behaviors that feel agile and those that don't.
Doing this creates an opportunity for meaningful discussion.
From there, you can start to carve out a path towards an agile mindset for your team.
The second pillar is the collection of practices agile teams use.
If mindset gives you the why, practices give you how.
Backlog refinement, sprint planning, daily scrums, retrospectives, these aren't just rituals, they're the scaffolding of effective delivery.
But teams struggle here as well with issues around story splitting or planning effectively.
We come and hear things like, We can't break stories down small enough.
Planning takes hours and still no one knows what they're working on.
When agile practices are missing or misapplied, you get chaos.
Work piles up.
Quality drops.
Delivery becomes unpredictable.
Fortunately, You don't need to overhaul everything at once.
Start by spotting the weak links.
If your retrospectives feel repetitive and only scratch the surface of issues, spend the next retro drilling deep into only one topic.
Spend time uncovering root causes rather than immediately jumping to solutions.
If sprint planning isn't creating enthusiasm for the work of the coming sprint, consider shortening the meeting.
The sprint-planning meeting should be fast-paced, but shouldn't feel rushed or cut off.
I like to target about 90 minutes for a two-week sprint.The goal in sprint planning is not to identify every task team members will need to do.
the goal is to select a viable sprint goal and their product backlog items to support that.
Talk about tasks and possibly estimate those just enough to decide which product backlog items can be brought into the sprint.
Yeah, doing it this way will mean overlooking a few tasks, but spending extra time thinking harder just to identify a small task does not add enough value
to be worth it.
The third pillar of a successful agile improvement effort is roles.
Scrum introduces new roles and redefines old ones.
But if you don't clarify who's responsible for what, you'll experience problems.
I've seen this so many times.
Product owners aren't empowered and Scum Masters aren' respected.
We have a product owner, but everything still goes through the VP.
No one knows what the Scumbaster does, so they just book meetings.
When roles are fuzzy, team members end up frustrated because they're unsure what they are allowed to do.
Here's something you can try if team member struggle with role confusion.
Run a who does what alignment exercise.
Write down key responsibilities, like prioritizing the backlog, facilitating meetings, or making sprint trade-offs.
And ask the team to match each one to the right role.
This kind of conversation clears up mismatched expectations quickly And it prevents a lot of finger pointing down the line.
While practices are important, they don't guarantee great teamwork.
I've seen teams that have very skilled individuals, but almost zero collaboration.
The truth is you just won't see great results without strong teamwork, which is the fourth pillar.
Great teams share ownership.
They finish work together rather than passing it down an assembly line, But when we've surveyed ADSL practitioners, the feedback shows a lot of disconnect
between team members.
We still hand things off like before.
Our team is remote and barely talks outside of standups.
That's not a team, that's a collection of individuals.
Here's an experiment you can try if you think your team needs to work on its collaboration muscle.
Pick one story in the next sprint and swarm on it.
Have three or more team members work together at the same time.
See what happens.
Most teams know what too little collaboration looks like.
With swarming, we want to overcollaborate, have more people work together than seems necessary, so they're forced to find ways to split work up.
This small experiment builds shared ownership, improves communication, and often gets work done faster than solo assignments.
The fifth pillar of a successful agile improvement effort is one people often overlook, support beyond the team.
Even the best agile teams will struggle if the surrounding organization still clings to old habits.
You've probably heard things like we did in our survey.
Stakeholders expect exact dates, but don't come to reviews.
Leadership drops new priorities mid-sprint with no discussion.
When that happens, teams feel whiplashed.
Morale drops.
Agility becomes a scapegoat.
So how do you fix it?
Start with expectations.
If leaders want predictability, they need to participate.
Invite them to review.
Show them how planning really works.
Educate them that just because they want something doesn't mean it's possible.
When stakeholders want more than can be delivered in a desired amount of time, that needs to become a shared problem.
The team and stakeholders collaborate to find the best solution within the constraints.
When people outside the team start supporting the Agile process, teams can finally breathe and deliver.
No transformation starts perfectly.
But if you want change that lasts, these five pillars, mindset, practices, roles, teamwork, and support outside the team are where to begin.
Look at where your teams are today.
Identify the weakest pillar and do something to improve in that area.
Then repeat.
look again for the weakest pillar.
It may be the same pillar, And find something else to approve.
That's how agility takes hold and sticks.
And if you want help building a truly agile team from the inside out, take a look at our course, Working on a Scrum Team.
It's designed to get your entire team aligned on the same page, speaking the language, and ready to deliver.
You'll find all the details on this page.
Thank you for watching.

Transcript

I remember working with a product team that was stuck.
They were smart, experienced, and deeply committed to building something meaningful.
But despite their talent, their work felt flat.They were completing tasks, but they weren't creating anything truly innovative.
They weren't challenging each other's thinking.
They were imagining possibilities beyond the obvious ones.
Then something shifted.
During a planning meeting, someone asked a question that reframed the entire discussion.
What problem are we really trying to solve?
That question sparked a debate, a lively one.
And within minutes, the room was buzzing with ideas none of the team members had considered before.
They envisioned possibilities, challenged assumptions, pushed each other, and built on each others' thinking.
By the end of the meeting, they had the beginnings of a breakthrough.
What changed?
Not the people, not the tools, the process.
what changed was the team.
Acting like a team again.
Sharing purpose, curiosity, creativity.
And that's when I was reminded of simple truth.
Real innovation happens when people think together.
For generations, we've romanticized the idea of the lone visionary, the single brilliant mind who creates something extraordinary in isolation.
But that's not how great products are built, and it's how innovation actually works.
Even when an idea begins with one person, it is shaped, refined, improved, made real by many.
Teams provide the friction, feedback, and diversity of thought that transform good ideas into great ones.
When I look at the most successful product teams I've worked with over the years, they all share something powerful, a commitment to thinking together.
They don't simply divide work, they pursue understanding, debate, explore, build on each other's strengths and perspectives.
That collaborative engine is what produces insight, and insight is that produces breakthrough results.
Decades of research point to the same conclusion.
A landmark analysis published in Science Magazine looked at 19.8 million research papers and 2.1 million patents.
Over the five decades of this research, the percentage of team versus individual discoveries grew.
And team discoveries were six times as likely to be highly referenced by future research.
The conclusion is clear.
Innovation has shifted decisively from individuals to teams.
This isn't a coincidence.
As problems become more complex, we need more perspectives to solve those problems.
Teams bring that, they bring debate, conflict and reconciliation.
They bring the synthesis of multiple ideas into something none of them could have created alone.
Innovation is a conversation.
In my work with teams around the world, the differences between high-performing teams and groups of individuals is unmistakable.
High-performing teams share a deep understanding of purpose.
They challenge each other respectfully.
The encourage experimentation.
they create psychological safety for new ideas.
And high performing teams find joy, even fun, in working together.
Simon Sinek would say they know why they're doing the work.
This shared purpose isn't a feel-good sentiment, it's a performance driver.
Research from Google's Project Aristotle confirms that teams with psychological safety and shared meaning consistently outperform those without it.
Amy Edmondson's work shows that the teams who openly learn and explore together innovate faster.
When teams understand the why, they do better work.
when they lose that, creativity evaporates.
I worked with a team that used AI to determine what their users wanted.
They had created a very thorough product backlog, but they rarely talked to their prospective users.
The product that resulted was technically impressive, emotionally empty, useful, not compelling, functional, and not intuitive.
The team had the talent, they had data.
What they lacked was collective curiosity, the kind that emerges when a team explores a problem together and challenges each other's assumptions.
They didn't need better tools, They needed better teamwork.
Today's work is more interdependent, more complex, and more unpredictable than anything we faced 20 or 30 years ago.
Customers expect better experiences.
Markets shift faster.
Products intertwine across disciplines.
Solutions require a wider range of expertise.
We need teams, not because it's fashionable, but because its necessary.
Teams that think deeply, teams that collaborate authentically, Teams that challenge and support one another, teams that understand why their work matters.
The research reported in Science Magazine didn't mark the end of individual creativity, it marked the rise of collective creativity.
If you lead teams, this is the moment to double down on teamwork, real teamwork not task distribution.
Invest in stable, cross-functional teams psychological safety, time for discovery, purpose-driven work, clear communication and shared learning.
and team training and coaching that unlock creativity.
Because in every organization I've ever worked with, one truth always holds.
When teams thrive, everything else gets better.
Better ideas, better products, Better performance, and better outcomes for customers and the business.
Teams remain our most powerful engine for innovation, And they will shape the breakthroughs of the next decade.
If this made you think about your own teams, their collaboration, they're creativity, there purpose, you're not alone.
Many organizations have talented people who simply aren't working together in the way they want or need.
That's exactly where Mountain Goat Software can help.
For more than 20 years, we've helped organizations build high performing collaborative teams that deliver meaningful results.
Through training, coaching, and hands-on guidance, We help teams strengthen communication and trust, clarify purpose and align around shared goals,
improve collaboration and decision-making, deliver value more predictably, and create an environment where creative thinking thrives.
If your teams aren't performing as well as you'd like, or if you know they're capable of more, we'd love to talk.
Helping organizations build stronger, more effective teams is what we do best.