Agile and Scrum Videos

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

All Videos

Transcript

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

Transcript

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

Transcript

Integrating testing into iterations can be a challenge for agile teams.
When testers get handed work late in the iteration, it's hard for them to test everything as quickly as needed.
This frustration of being overworked at the end of an iteration goes along with frustration early each iteration when testors don't yet have anything to
By the way, my name is Mike Cohn and I'm the author of three best-selling books on Agile and Scrum.
I also offer a range of training materials, free tutorials, and tools to help teams succeed with Agil.
You can find these at mountaingoatsoftware.com.
Right now, though, let's take a look at what you can start doing today to helps testers have the time needed to test everything within the iteration in
which it's coded.
The key is to reduce the size of handoff between programmers and testers.
It's common for a programmer to grab an item from the product backlog, typically a user story, develop the new functionality,
and then hand it over to a tester after the whole thing has been developed.
This means the programmer might work on a backlog item for few days or even a week or more.
When the tester finally gets their hands on it, there's a lot to test.
Instead of finishing an entire product backlog item and handing that over to a tester, programmers should hand over small parts of an item as each is finished.
Think about a typical product backlog item and its acceptance criteria.
Let's suppose it's a user story with four acceptance criterias.
As the programmer writes the code to fulfill each acceptance criterion, that work should be handed over for testing.
This allows the program and tester to work nearly concurrently.
Here's how this would work for a simple user story about logging in.
As a member, I'm required to log in so that my account is secure.
With that acceptance criteria of the right credentials grant access, the wrong credentials deny access and display an error message,
a user can request a password reminder, and a users locked out after three failed attempts.
Before any work begins, the programmer and tester talk and decide where to start.
They decide to Start with granting access when the right credentials are entered.
While the program writes the code to support only this, The tester creates a test plan for just this small part of the full user story the Programmer is coding.
That doesn't take our tester much time in this case, so the tester creates test data while the programmer is still working on just the first part.
Depending on how much automation is already in place, the test may even be able to script automated tests that will run as soon as the code is available.
As soon both the Programmer and Tester are done, they check their work into the official build system and test to run.
They then talk about what to work on next.
Let's say they choose the bit allowing users to request a password reminder, another of the story's acceptance criteria.
Again, while the programmer codes support for just this, the tester creates test plans, test data, and automation scripts.
There are still handoffs between the program and the tester.
But instead of one big handoff of the entire product backlog item, The programmer is handing work to the tester one small subset of full feature at a time.
For this to work, the programming and testing tasks don't need to take the same amount of time.
Coding could, for example, take twice as much time as getting tests ready to run.
In that case, this same tester could be following a similar pattern with a second programmer or doing any of a myriad of other testing tests.
Reducing the size and increasing the frequency of handoffs solves the problem of testers not having enough time to test.
Near the end of an iteration, testors will have only the last small handoff from the programmers to tests.
If you found this video helpful, please do me a favor and hit the like button.
It really does help YouTube to show the video to others.
And click the subscribe button if you'd like to be notified of future tips.

Transcript

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

Transcript

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

Transcript

During a sprint planning meeting, two team members were debating whether a task would take four or five hours.
Back and forth they argued, I couldn't take it anymore.
I typed five into the cell of the spreadsheet they were using to plan the sprint.
A little later in the same meeting two programmers were arguing about the best way to implement a feature.
They'd only argued for a couple of minutes when I asked them how long they thought their preferred approaches would.
Take they each said four hours, I typed in write code and four hours in the spreadsheet.
Then I added another row, fight, and allocated them one hour to hash out the best approach.
These are just two of the many examples I've seen of teams doing sprint planning poorly.
Hi, I'm Mike Cohn, And I am the author of three bestselling books on Agile and Scrum.
I help teams succeed with Agil.
And in this video, i'm going to help you run sprint-planning meetings that finish on time.
The way to do it is to stop trying to identify every task that will be performed during the sprint.
That level of detail is not necessary.
In fact, it's impossible and leads to overly long sprint planning meetings.
Think about it this way.
Suppose you're planning a week-long vacation.
Since we're making this up, let's make it somewhere great.
You're going to Paris for a weak.
To make the most out of that trip, you'll probably want to make a list of the important things you want see or do while in the City of Light.
Visit the Louvre, the Musée du Orsay, a day trip to Versailles, see the world's largest ball of twine.
Wait, that's in Kansas.
Anyway, you get the idea.
You're not going to make a list of everything you're going do in Paris.
I'm a planner when I travel, but even I am not gonna make list everything I do.
If you disagree, think again.
It's no different when planning a sprint.
Team members don't need to think of everything.
In my experience, a team that identifies about two-thirds of its potential tasks during sprint planning has done a good job.
That is normally enough to know if the sprint is full.
As an example, Lisa is a great scrum master I worked with.
She looked at how many tasks her team had done in each of its past few sprints.
This is easy data to get from essentially any agile tool.
she found that the team averaged 70 tasks during their two-week sprint.s She told the Team that she wanted to try cutting 30 minutes from the time they
normally allocated to sprint planning.
She suggested saving that time by not trying so hard to think of every task.
She kept the target of two-thirds to herself, but as the meeting progressed, she kept an eye on the number of tasks, knowing that if the team went much
beyond identifying about 50 tasks they were probably spending too much time on planning.
That's how she knew when to tell the Team they'd been at it long enough.
When the sprint ended two weeks later, the team had successfully met their sprint goal, completing all the product backlog items they brought into the Sprint.
I don't necessarily want you to cut a team off once they've identified 2 thirds of their average.
Instead, I suggest using this as a gauge for whether the Team might be spending too much or too little time in sprint planning.
Suppose, instead, that Team is planning a sprint, and they identify 30, then 40, than 50 tasks.
You know that's well above the two-thirds of the likely 60 total tasks.
You can't really stop them at that time, because maybe they haven't identified any tasks for the last product backlog item.
Instead, use that information to encourage a shorter next sprint planning meeting, much as Lisa did in the story.
It's worth pointing out that I am suggesting identifying two-thirds of the tasks, but that will almost certainly comprise more than two thirds of hours
in the sprint.
This is because the task team members will identify will be the bigger, more obvious ones.
The team isn't going to forget the eight-hour main coding task.
During sprint planning, however, they may forget one hour task to update a report after the coding is done.
Focusing on identifying the most important tasks during sprint planning, rather than striving to identify every task, can save teams up to an hour in sprint planting.
And the team should still be just as likely to finish the needed work to achieve their sprint goal.
How are your sprint planning meetings going?
Do you think they could be shortened and remain as effective?
Or do you need to spend more time in planning?
Please let me know in the comments.
I read and appreciate every comment.
If this video has been helpful, click the Like button.
And if you're new to this channel, Click Subscribe so you don't miss out on future tips to help you succeed with Agile.
Thank you for watching, and I'll see you next time.

Transcript

In the next seven short minutes, I'm going to show you how to split any user or job story.
Once you know the five approaches I'll share in this video, you'll be able to bring any story down to size.
From there, You'll just get better with practice.
I've identified five ways to Split any Story.
Spikes, Paths, Interfaces, Data, and Rules, or as I call them, Spider.
Let's look at each one individually.
The S stands for Spike.
A Spike is an activity a team undertakes to learn more about some backlog item.
Think of it as a research activity, but it may include prototyping or some experimental coding.
During a Spike, a Team isn't trying to develop the new functionality.
Instead, they're developing new knowledge that will help them develop their functionality later.
We're here on YouTube, so let's use YouTube as an example.
Let's go back in time to when YouTube added automatic captioning.
The team doing that might have faced a build versus buy decision.
Do they use some commercially available software to generate the captions, or are their needs so unique that they need to develop something from scratch?
The way to settle that would be a spike to test out one or more commercially-available caption products.
Extracting a spike makes the original story smaller because some or all of the research included in the story is removed.
This is absolutely an essential way to split stories, so extracting a Spike is one of five splitting techniques you should use,
but normally it won't be the first technique you'll reach for.
Our second splitting technique is paths, which is the P in Spyder.
To split a story by paths look for alternate paths through the story.
Sticking with YouTube, let's use this story I can share a video with my friends.
When I click the share button in YouTube today, I'm shown 14 buttons I could click to share directly to various social networks.
I am also shown a link I copy.
And I'm given the option to customize that link to start playback of the shared video at a specific time within the video.
That's 16 different paths through the I can share a video story.
I don't know that this story needs to be split into that many smaller substories.
that's for the team to decide based on the effort involved in each.
But with the path technique alone, we've just identified 16 paths, through, the original story From running webinars on writing better user stories,
I've learned that splitting stories by paths is one of the most popular approaches.
The I in Spyder is for interface, which refers to splitting a story by its interface.
The most trivial example would be on a mobile app.
You can split the story into iOS and Android versions.
In other cases, splitting by interface can be done by having a simple version of the interface and then a more involved version as separate stories.
This usually applies to user interface but doesn't have to.
Applying this to our YouTube video sharing example as an alternative to splitting that story by paths, we could have split out a basic sharing story like,
as a video viewer, I can get a URL to share.
This could be implemented with no user interface other than a Share button on the video page.
The pop-up with the 16 different ways of sharing wouldn't be needed if the only way to Share is through a url.
A subsequent story could be, as a viewer, I can share a video to various social media sites.
This could done with a very simple user interface at first.
No fancy scrolling through a list of logos, maybe just a drop-down list text with the names of the social sites The final story could then be something like,
as a viewer, I can choose the social network to share to by scrolling through a list showing the logos of each.
Splitting by interface works because the ultimately desired feature can be developed by starting with a simple interface that is successively improved.
Let's move on to the fourth of the five techniques you can use to split any user story.
And that's splitting the story by data.
This is the D in the Spyder acronym.
To split a story by data, do an initial version of a Story that processes only a subset of the data that will ultimately need to be supported.
For example, YouTube allows you to upload a video in any of 16 different file formats.
If we're building a YouTube competitor, screw 16 file format, let's start with one.
We're going to support one type of data.
All uploads need be in MP4 format for now.
We'll add the other formats later as separate stories.
Splitting by data is an effective approach.
Often there are a few types of data that add a lot of complexity.
Well, do an initial implementation that ignores the more complex data.
Get that initial implementations working, then add support for the complex more data You probably can't release the simpler version,
but you can still build it in that order.
I worked on a human resources system that did exactly this.
The system tracked who the manager was for each employee and would do things like route time off requests to that manager.
Most employees have one manager, but some employees had multiple managers.
We needed to support having multiple mangers, But some stories were simplified initially by assuming each employer had exactly one Manager.
Let's take a look at splitting stories by rules, which is the R in our SPDR acronym.
Splitting by Rules is probably the technique I get the most questions about during webinars and live classes on writing better stories.
To split a story by rules, write a storytelling that relaxes one or more of the rules the story will ultimately need to support.
Sticking with YouTube as an example, YouTube has some strict rules around including copyrighted music in videos.
If we're building a competitor to YouTube, our team's first story will be, I can upload a video so that others can watch it.
That story probably sounds simple, but there's a lot to it, so in the first iteration, let's ignore the rule that videos can't contain copyrighted music.
We're not announcing our new YouTube competitor to the world after only one iteration anyway.
We'll have plenty of time after this first sprint to comply with our internal rule about not allowing videos with copyrighted music.
As another YouTube-related example, suppose we want to prevent certain text from appearing in comments.
That could be swearing or maybe SQL commands that could a hacking attempt.
Great idea.
Let's protect our users and our system from this type of text in Comments.
But an initial story of, as user, I can enter a comment on a video, can ignore that rule.
Doing so makes the story smaller so that it can fit within an iteration.
And support for the rule can be added a couple of iterations later.
What if having the right size stories allowed you to motivate team members and finish projects faster?
Beyond knowing these five techniques to split any story, it's important to know why it is so important have small stories to begin with.
The answers in this video.
You'll learn the three reasons why is vital to work with small story.
They probably aren't what you think.
Click the link on the screen or in the description and I'll see you in next video!

Transcript

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

Transcript

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

Transcript

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

Transcript

It's often worthless to tell a boss, client, or customer that a project will be done in, say, 142 story points.
Even if stakeholders fully understand what a story point is, telling them how many points a project will take or cost isn't very helpful to them.
These stakeholders are accustomed to hearing how much time and money a product will make.
And it's important that teams and their leaders communicate with stakeholders in the terms those stakeholders prefer.
Fortunately, it is quite straightforward to convert an estimate of points into money.
Here's how.
Start by gathering data on how much the team has been paid over a period of time.
Ideally, this should be at least a few months, but you could start with as little as one sprint.
Next, divide total team compensation by the number of story points delivered by team in that period.
This gives you a cost per point.
For example, suppose a team has been paid $100,000 over some period.
During the same period, the team delivered 100 story points.
Dividing $ 100, 000 by 100 gives a cost per point of $1,00. This can then be multiplied by the total expected size of the project to give an estimate of
total financial cost.
You can get fancy with this if you'd like.
Instead of using compensation as I did in this example, you might want to use fully loaded labor cost, As its name implies,
this includes compensation as well as other costs such as benefits, overhead, and payroll expenses.
Those would be things like taxes and Social Security in the U.S.
A company controller can easily and almost always immediately provide you this as a percentage.
It's typically going to be in a range of 25 to 40% added to compensation.
You can get fancy by trying to adjust for seasonality or team size changes.
However, that's usually not worth the effort.
It shouldn't significantly impact the cost per point.
Keep it simple.
Clearly communicating expected costs with your stakeholders will improve your relationship with them.
Everyone appreciates being communicated with in terms they understand.
Using the simple technique here to convert points to money can improve team stakeholder communication.

Transcript

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