Hello, I'm Mike Hohn.
Thanks for joining me here today, and welcome to How to Write Better User Stories in Less Time with Less Aggravation, the three surprising techniques of
top agile teams.
First, make sure you're in the right place.
This webinar will be perfect for you if you believe in user stories, but you are struggling to make them work.
Or if your user stories are inconsistent and you'd love a more systematic approach to writing them.
Or, if you're not always sure how to split an epic so that you can complete the stories within an iteration and show progress stakeholders actually care about.
Perhaps you are under pressure from team members to answer all questions about a story before they'll even start building it.
Finally, this webinar is for you if you want to know more about user stories so you can coach others and even overcome their resistance to user Stories.
Let's talk about what you'll learn today.
First, how to stop day-to-day emergencies and yelling stakeholders derailing your progress during an iteration.
You'll learned why you need one or two clearly defined goals every quarter and how decide what those should be.
And a step-by-step way to plot stories so that you can prioritize them faster and clearly communicate to stakeholders what will you build.
You'll learn the real reason agile teams split user stories and focus on being potentially releasable at the end of each iteration.
You learn why too much detail is worse than too little and how to achieve the sweet spot of just enough, just in time.
I want to tell you how dramatically user stories helped one of my clients.
But I need to start by sharing how I became obsessed with user of stories.
I've only told this story a few times, but I wanna give you a little insight into why user's stories are so important to me.
Back in the early days of Agile, Scrum was the original Agil framework.
And Scum's product backlog was treated pretty much like a junk drawer.
You know, the drawer we all probably have in a kitchen.
The product back log was a place you just threw all the things you needed done to a product.
In those early days, teams didn't do product backlog refinement.
They didn' write user stories.
And I started to notice that my teams who treated the product backlog more seriously did better.
Treating the project backlog more serious could mean any number of different things.
It could be spending time keeping the back product prioritized or making sure that the top items were small and well understood.
I simply noticed that teams who treated the product backlog as something more than a junk drawer were more successful.
Around this time, I stayed home from work sick one day, and I read Kent Beck's Extreme Programming Explained book.
This is the book that introduced the world to the idea of user stories.
And I couldn't wait to get back to work the next day and share that idea with one of my teams.
Here's a photo of part of that team.
One of our team members was a train nut, and he told us about the national hand car races.
These are those cars that sit on railroad tracks, but you manually pump a bar up or down to get them to move.
They're a blast.
So one of out programmers loved trains, And we entered that race and came in second place.
But back in the office, I told this team what I'd read about user stories in Kent Beck's book.
That team gave them a try, and they worked phenomenally well.
After that first success, I introduced User Stories into other teams in that company and then to teams at other companies.
Just about every team had struggled with its product backlog.
And with User Story,s I'd found a way to ease those struggles.
With User stories, a team kicked its project off in the right white weight manner, And that let them be agile for the whole project.
For example, here are the results from just one of those early teams to adopt user stories.
On the left is a semi-agile project that had used use cases.
on the right is the project used user-stories.
The middle row is size of the projects.
You can see that about 10% more functionality was delivered with user story.
the bottom row shows that the team did this in one-tenth of person months.
Getting good with user stories really benefits an entire project.
Since then, I've worked with many companies, large, small, in various industries, including software, energy, finance, health care,
games, hardware development, digital agencies, and so on.
And they've all struggled with users stories, And all have seen drastically improved results once they got user story right.
I don't have time to share everything I know about user stories, but there are three fundamental techniques that I see that turn struggling agile teams
into top performing agile team.
I'm going to show those three things now.
Let's start with the first, which is running a quarterly story writing workshop.
Yeah, I said quarterly.
You're probably writing stories every iteration.
A lot of agile teams write a small number of user stories each iteration.
It's probably what you're doing.
You write 10 stories at the start of the iteration, and then you deliver perhaps 8 or 10 by the end of it.
What I want you to do instead is write 1 quarter's worth of stories, at start to the quarter.
If you're thinking that's going to make you less agile, here's why it won't.
When you write a bunch of stories quarterly, it allows you to focus on the bigger picture.
The team's product owner picks a big goal or two for the quarter.
You write the stories to achieve that goal, and then run the iterations to makes it happen.
As you're running those iterations, you'll still write some new user stories.
Someone on the team will come up with a great idea over breakfast.
There's a new story.
And some of the stories you wrote for the quarter will need to be split.
They're are some user story's.
So I'm not saying you forbid the creation of new users stories, what I am saying is run a deliberate focused meeting at the start of a quarter or some
similar period.
During that meeting, participants attempt to brainstorm the stories needed to achieve the period's most important goal.
This meeting is called a Story Writing Workshop.
There's a big problem with any iterative and incremental process.
And Agile is an iterated and an incremental processes.
The problem is that you run a series of sprints and then you look back on what you've accomplished and realize it wasn't much.
This happens because every sprint, the product runner and team look around at what to work on.
and the answer is often some emergency or some fire to put out.
There's a quote commonly attributed to old President Eisenhower that says, What is important is seldom urgent, and what is urgent is,
seldom important.
If you've ever been working on something important, say a presentation for your boss, a report, or even getting the next user story is written,
And you gave into the temptation to look at your email, you fell into trap of working the urgent rather than the important I suffer from this all the time.
Say I'm trying to write a new blog post or even put a webinar together and my email dings.
I think, oh no, someone needs me.
And I stop working on the important thing to work instead on urgent thing, the thing that dinged and got my attention.
When I do that, I am giving into the urgent rather than staying focused on important.
Agile teams fall into the trap of working on the urgent rather than the important all the time.
It happens because of an overly short planning horizon.
Every sprint, the product owner chooses the most important things for the teams to work on.
But sometimes the more important thing to working is not the thing that stakeholders are yelling about in the moment.
This problem is made worse when a team writes new user stories every iteration.
This short-term focus from writing stories each iteration causes the product owner and team to give in to the temptation to work on the urgent rather than
the important.
When this happens, the team doesn't deliver all the value it could.
Stakeholders become dissatisfied.
After all, they aren't getting what they thought they would.
Team members get frustrated because this leads to more changes being introduced in the middle of iterations.
And then ultimately the business starts to doubt the benefits of Agile.
Through all of this, your team might be faster, but it's not building the right stuff.
What you need to do instead is write user stories less frequently.
I like doing it in a quarterly story writing workshop.
When you do this, the product owner team and stakeholders are able to step away from the day-to-day crises and think, what are the most important things
to achieve in the coming quarter?
And then they write the user story that will make that happen.
At that point, you'll begin to find that the urgent firefighting doesn't always win.
Without a big longer-term goal, though, every crisis seems worth addressing.
But once our product owner and stakeholders establish a rough goal that's out there further than an iteration away, now there is something to compare the
crisis against.
The conversation can then be framed as, should we address this crisis or should stay focused on the big goal?
But without that big goals, the crisis always wins.
I want to share a couple of things you'll want do to have a successful story writing workshop.
The first is to focus each workshop on a single significant objective.
One of the worst things that you can do in a storywriting workshop is start by asking participants, so what should you build?
Ask that, and you get nowhere.
The question's too open, because the whole system is fair game.
Ask That, And you'll get answers that span the entire spectrum of your product's functionality.
You want instead to focus each story writing workshop on one significant objective.
Doing that helps keep the workshop shorter and increases creativity because participants focus all their energy on one goal,
rather than sprinkling their attention across the entire product.
The product owner selects the significant objective, normally in consultation with stakeholders.
And remember, a good significant object is big enough that it will take a couple of months to accomplish.
I like targeting about three months.
Once a significant objective has been selected, the product owner conducts a story writing workshop to generate user stories that will achieve the significant objectives.
And then the team runs a series of iterations to deliver those user stores and achieve that objective.
Then the quarterly cycle repeats.
Let me give you a few good ways of thinking about what makes a good significant object.
One is to think about delivering a minimum viable product, or MVP.
The term MVP comes from Eric Ries and his book, The Lean Startup.
An MVP is a version that gets the maximum amount of information with the least effort.
Thinking about a minimum viable product is great.
But personally, I think it gets overused.
And I have a bit of a problem with the term.
What do you build next?
You're already minimum.
You are already viable.
So whatever comes next is more than that.
It's like you can only use this term once.
There's another term I want to introduce you to that I like a little bit better.
It's minimum marketable feature, or MMF.
A minimum-marketable-feature is a subset of an overall feature that delivers value when released independently.
That is, it's not everything you may ultimately want in the feature, but it is enough to get some feedback.
In the spell checker, for example, you might release a version that checks your spelling but doesn't allow users to share custom dictionaries or do other
things you know you'll eventually want.
But it enough market that the future is present.
A minimum marketable feature can be thought of as smaller than a minimum viable product.
An MVP usually needs to have a set of features that are all minimally market-able.
One more way to think about a significant objective is to thinking about wildly important goal or WIG.
A Wig is the most important thing you want to accomplish in the coming quarter or whatever period you've chosen.
So there you go.
Three different ways to thing about what will be the important to add in a coming period.
Again, I like to about this quarterly, but any time frame longer than a single iteration is fine.
Regardless of which of these concepts you like best, I just generically refer to them as a significant objective.
The second thing you need to do for a successful story writing workshop is to involve the whole team, including the development team.
Yep, you want your programmers, testers, DBAs, designers, analysts, tech writers, and so on all to participate.
I get why some product owners may not do this.
Involving the team in your storywriting workshops may seem inefficient.
But let's see if I can convince you it's worth it.
First, while this is a time investment, that time-investment will be paid back with time savings when the team works on the stories.
When developers are present when stories are first written, they'll have fewer questions later.
They'll be likely to have some context from how the story originated, perhaps what users were thinking about at the time.
Not only does this mean fewer interruptions to a developer's day later, but it also means the developer may come up with a better implementation from having
directly heard the user or stakeholder's actual request.
But there's a second reason why I recommend including the whole team in your story writing workshops.
Doing so leads to increased creativity because development team members think differently from the business stakeholders,
customers, and users who are typically present in a storywriting workshop.
OK, we've established that you should be doing a story writing workshop once per quarter, that it should focused on a single significant objective,
and that the entire team should participate.
The last thing you need to do to run a successful storywriting workshop is to have some way of visualizing all the stories created during that meeting.
The best way to visualize the relationship among stories is with a story map.
Story maps are the invention of Jeff Patton.
And I think Jeff deserves that Nobel Prize or whatever the Agile equivalent is for the idea.
Let's take a quick look at what a Story map is and how it helps you organize stories.
A StoryMap is laid out like a grid with rows and columns.
Each card in our Story Map is one user story, one thing a user needs to do.
We read across a Story map by mentally inserting the word then between the cards.
So this map is read as A, then B, and then C, than D.
And that's the first dimension of a story map.
Horizontally, we're showing a sequence of activities.
First, a user does A, then the user as B, and so on.
Don't treat the sequence of stories on a map too literally.
Here, I've shown the users doing A then B then C.
But some users might do C before B.
don't obsess over it when you're creating a Map.
Just create what you think is a logical sequence.
As an example, think about Facebook.
When I visit Facebook, it's normally because I want to post something.
But after that, I check my timeline to see if my friends are up to anything interesting.
So my Facebook use looks like I've shown in the map.
Log in, post, then check timeline.
Your Facebook usage, however, might be the opposite.
You check your timeline before you post, and someone else may never post at all.
So some steps can be optional in the sequence on a story map.
There's really no universal way of showing optionality on the map If you're really worried about it, you could use different colored cards for mandatory
and optional steps, or you can draw a little symbol on some cards.
I find it best, however, to just not worry about it.
The map is not meant to be that detailed.
It doesn't matter how you sequence post and check timeline, then.
Just do it in the order you think makes sense or that you thing will be most common among your users.
The second dimension in a story map is down.
We read down a storytelling map by mentally inserting the word or between story cards.
So the first column of this map, is read as first the user does A1 or A2 or a three.
Then the user does B1, or B2, B3, and B4.
Then C1 or C2 and so on.
So across a map is showing a sequence and down a is map showing alternatives.
The alternatives should be stacked in priority order.
the most important at the top of a column and the least important on the bottom.
So in this map, I'm saying that A1 is the most important option in the A column, and A3 is least.
What that means for an Agile project is that if there's enough time, the team would develop A 1, A 2, AND A 3. If there is not enough,
though, then the teams might only do A-1 and maybe A2.
Let's make this more concrete with an example.
When I was making these slides, I stopped to have dinner.
I ordered from a food delivery service that picks up at nearby restaurants and brings me my meal.
Let us take a look at a story map for that.
To order my meals on this site, had to pick a restaurant, then select my food, and then decide how I would pay.
Finally, add a tip and confirm my order.
At the highest level, I've just described the whole product, but we want to dive deeper than that.
So in a story writing workshop, we would engage participants in discussion about how users pick a restaurant.
And let's say we come up with two approaches.
A hungry user can browse the full list of restaurants on the site, or the user could pick from a list restaurants that user has ordered from in the past.
Cards for those stories are added to the story map.
Participants then turn their attention to selecting the food items for the meal, and they decide there are three ways of doing that.
First, selecting one or more items from the full menu.
Second, reordering items form past orders.
And third, a list of the most popular items at the chosen restaurant.
These first two columns are a good example of showing priorities on a story map.
I placed full menu as the first item under select food because it's the top priority.
If the team working on this product only has time to develop one of those three approaches, I want them to show the full-menu.
I put past orders second because that's how I frequently order, but if I can't see the full menu the first time I order I won't have past order.
So full-menu has to be first.
And as the third priority, I decided it would be nice to show the most popular items at a restaurant.
I find that helpful when I'm ordering from someplace I've never been to or even heard of before that meal.
And here I've added the detail for selecting how the user will pay, add a tip, and confirm the order.
I want to explain why I made the top row blue.
The cards in the Top Row are probably not stories that will be implemented.
They're more titles or labels for the functionality below them in The Map.
For example, Pick A Restaurant is a story, but it has two sub-stories.
Pick a restaurant by browsing and pick a Restaurant from past orders.
the team will not grab the Pick-A-Restaurant story and go develop it.
they'll pick one of the sub stories and develop that.
So it's often useful to think of the top row as titles.
Some tools call these top stories epics or themes or other terms.
I've largely given up on those terms as different tools use the terms inconsistently.
Now that I've explained the top row, I want to add a row on top of it.
Here's why.
Sometimes a story map will get huge.
You can have 100 or more columns if you're mapping something extremely involved or doing it in a very detailed way.
With a Story Map with 100 columns, it can be really hard to find the column you are looking for on the map.
So sometimes it's useful to add a row above there that's kind of like a table of contents into the map.
The cards up there indicate where different bits of functionality begin.
You can see here I've added a card indicating that ordering begins in the first column and that checking out begins the third column.
you don't need to do this, but I think you'll find it handy for a map with more than perhaps a dozen columns.
There's a lot more you can do with a story map.
You can use story maps to plan and communicate roadmaps of what will be delivered in the future release.
Let's recap those three tips.
One, focus on a single significant objective.
Two, involve the whole team in writing user stories.
Three, visualize user of stories with a story map.
If you can start doing story writing workshops the way I just described, once a quarter with full team involvement and focused on single,
significant objectives, you will see some positive changes.
your team will be able to stay focused on important work rather than work that's merely urgent.
That means you'll be delivering more valuable functionality, often much more value.
And that means your customers and users will feel happier.
Instead of questioning the value of Agile, they often become your biggest supporters.
But it's not just users, customers, and stakeholders who are happier.
So are team members who were able to see a much more immediate and positive impact on users from their work.
Our next tip for writing better user stories and less time with less aggravation is to master the art of splitting stories.
And that means getting comfortable splitting Stories that demonstrate progress, even if sometimes the result is not truly shippable.
You know splitting stories is important.
Agile teams try to finish what they start each iteration.
And that's hard if your stories are big.
But you also know that splitting story is hard.
Splitting stories hard for a number of reasons, including that it's to know when the story's small enough.
Every story is different.
We're often splitting a story with incomplete knowledge of what's needed, and we're trying to split stories for the coming iteration while busy finishing
the work of the current iteration.
So teams do the best they can.
But this means they often end up with stories that take more than one iteration.
They end with inconsistent and unpredictable velocity and difficulty planning new iterations, especially if they plan based on velocity.
And they have disappointing sprint reviews because work isn't really done.
Most of these problems are caused by a single thing, and it's not just a lack of experience or skill in splitting stories.
It's a misunderstanding of the goal in the splitting story.
Teams split stories so they can gauge their progress.
Software developers in particular are horrible at knowing how done they are with something.
There's a whole joke in the industry called the 90% syndrome.
The 90 percent syndrome says a software product is 90 done for 90 of its schedule.
Think about asking the developer, how done are you?
And the developers says, 90%. You think, great, you go away.
You come back a week later expecting the thing to be done.
you ask the development how dumb they are now.
And they again say, ninety percent.
What's going on?
Is the developer just lying?
No.
When you first asked the developers how done they were, they sincerely thought they where 90% done.
A week later, the devloper is still 90 percent done because they've realized the problem is actually bigger.
This doesn't happen because your developers are evil lying jerks.
It happens because estimating how far done we are with something is notoriously hard.
In Agile, we make it a lot simpler.
We don't estimate percentage complete.
we simply want all work in one of two states, not started or done.
This is easier.
Were pretty good at knowing when we're done with, something and we were really good in knowing if we haven't started the thing.
So the goal of splitting stories is to make this assessment easier.
You want each story small enough that the team can finish it within an iteration.
If you do that, assessing not started done is easy, because by the end of each iteration, a work is in one of those two states.
A second goal in splitting Stories is the do so in a way that each Story truly represents progress.
The Agile Manifesto includes the principle, working software is the primary measure of progress.
This means that stories we split have to still deliver working, software.
That means we aren't going to split up separate analysis, design code, and test stories.
Each story has to deliver, Working Software.
But here's where teams get hung up.
When teams hear the Scrum phrase's potentially shippable product increment or potentially releasable, it's almost as though they don't hear their first word,
potentially.
And this is where they go wrong.
Potentially shoppable or potential releaseable are not the same as truly shuppable and truly releaserable.
Once you get used to that, splitting stories becomes much easier.
Let's take a look at a couple of examples.
First, let's suppose your team is developing this home finder website.
We have a story of something like, as a prospective home buyer, I can search for a home based on its size, number of rooms,
status, type of home, age, and amenities.
Our designer tells us the user interface to all that is going to be at least moderately involved to build.
And from all the combinations that can be selected, the database query could be challenging to get perfect and to test.
So we want to split this story.
The team talks about various splitting options, but none of them seem to result in anything potentially shippable.
One team member suggests building just the user interface in the first iteration.
But that's not potentially shippable.
Who wants a screen that doesn't do anything?
Someone else suggests getting all the database queries working.
That's the same problem.
It's potentially not releasable The solution, then, is to do a little bit of both parts in each iteration.
Do a LittleUserInterface and the backend query to support that.
Then do MoreUiserInterfaces and add the back end to the support the new user interface fields.
And repeat this until you've delivered the full original story.
Here's how that would work with our Home Finder website.
In the first iteration, the team could build an extremely minimal user interface.
It's just a subset of the search criteria that will eventually be supported.
And that's essentially no design, but the Search does work for those fields only as it's connected to the database.
To do that, you might split out a story like shown here.
As a prospective home buyer, I can search for a home based on its size and number of rooms.
In the second iteration, your story would say that users can include property status and type of home in the search.
The team would deliver this story by adding those fields on the screen.
And you can see here the user experience designer has, by this iteration had a chance to design this screen, so it's no longer plain and boring.
As before, support for those field has been added to the database.
This home search works perfectly from user interface to database for the fields on it.
And finally, in a third iteration, the team delivers the remaining search criteria, age of the home and various amenities.
Those fields are added to a fully designed screen along with the database to support them.
I refer to this as splitting by interface.
It's one of five essential techniques I've identified that teams need to split any user story.
Let's address whether the stories in this example are potentially releaseable.
First, they're clearly not truly release-able, but I contend they are, potentially, release able.
For me, Potentially Releaseable or Potentially Shippable means high quality, tested, and what it does, it, does well.
But it doesn't include being a cohesive set of functionality.
That's the difference between being potentially Release-Able and truly Release Able.
In our home finder example here, we could theoretically release after the first iteration with just the top part of the user interface and the back end
search for those fields working.
Nobody probably wants it, but we couldn't potentially release it.
It's high quality, it's tested, and what it does, It does well.
it just doesn't do enough to be worth releasing.
So when you split stories, remember the goal is to potentially shippable.
Don't forget the potentially.
Let's look at another example and see how we might split it.
A few years back, I was doing some work for a hotel chain and working on software that would set prices at the hotels in that chain.
There were more than a dozen factors that needed to be considered in setting the price of a room.
These included how full is the hotel already, the day of the week, how well reviewed is hotel, How much are similar hotels charging,
and more.
All these factors were mixed together, and a fancy algorithm would set a price.
A lot of the data was pretty easy to get, the day of week, for example.
Other data, was a little harder, but still fairly easy.
For example, how busy the hotel was last year on similar dates was easy get.
But some of the data was hard to get.
The prices being charged by other hotels was harder to.
Some of that data were accessible through an API, but other data got by screen scraping it from various hotel websites.
And the screen scraper had to be tailored for each different hotel site.
So the team could not fully implement the story of, as a hotel manager, I want to see recommended prices for rooms in my hotel within one iteration.
So here's how we split it so that we were potentially shippable each iteration, even if not truly shuppable.
In the first iteration the team implemented a story about developing the algorithm, and they implemented stories that provided some of the easier data
into the system.
But they didn't implement anything about seeing the rates at other hotels.
What they did was basically fake that in the system.
The algorithm needed to know the cost of nearby hotels, and so instead of doing all the hard work to get that data, some programmer just hard-coded it
to always say nearby hotel cost $200 a night.
This means that the result being generated by the algorithm would be worthless, 100% worthless.
The hotel manager would not be able to use the recommended rates.
But this was an incremental step forward.
It was potentially shippable.
Don't panic, no one had any intent of delivering it this way.
No manager was going to get a bad number.
But think of how much easier it made to test the work of the first iteration if the price at other hotels was held constant.
If that number was being screen scraped off some other hotel's chain site, it would have been much harder to make sure the other parts of the algorithm
were working correctly.
So yeah, this was potentially shippable, and that it was high quality, well tested, what it did well.
But it wasn't a cohesive or complete set of functionality yet.
And in the next iteration, the team developed the stories to get competitive prices from a couple of data vendors and to screen scrape their own data from
few chains.
The output prices were now getting better.
They weren't perfect yet because hotel ratings were not yet being considered.
If our hotel is 4.2 stars on Google and the other hotel's 3.9 stars, we might be able to charge a bit more than the hotel.
And that wasn't added until the third iteration.
I hope you can see here that in each iteration, the team was developing something useful.
They weren't just writing documents.
Instead, they were developing some portion of a bigger set of functionality.
Each story they split out could easily be assessed as done or not started.
Remember, I said we find that easy to do, but we struggle with determining we're 85% done with a larger story.
In this example, the team was splitting stories by the rules that were to be implemented for that story.
Splitting by rules is the second of the five techniques I mentioned that I've identified that will help you split any user story I don't have time to go
into all five story splitting approaches in this webinar, but I have shown you two and you can find information on the others on this site.
If you're able to get your team thinking this way about the goal for each iteration, you'll find it much, much easier to find ways to split stories.
That's going to save you time in backlog refinement and in iteration planning meetings.
And that's gonna give you more time developing.
So you will be much more likely to delight your customers.
The biggest struggle I see with stories is that teams spend too long and still find themselves stuck with a story they can't complete or that doesn't impress stakeholders.
This last important technique is going to be the shortest.
But man, is this one important.
Get this wrong, and it does more than just slow your team down.
Getting it wrong and you may no longer even be agile at all.
I'm talking about adding just enough detail, just in time to your user stories.
Knowing you need to do this isn't a surprise.
Who's going argue with doing something just-enough and just time?
So we know what we need do, but many teams struggle to get it right.
If you add too much detail to stories too soon, you could be wasting time.
That would be the case, for example, if you added detail a story that is later dropped or put off for a long time, But if you add too little detail or
add it too late, it slows the development team down as they get stuck waiting for answers.
There's clearly some middle ground between too much too soon and too a little too later.
But what I see a lot of teams do is shift to the side of adding too-much-too-soon.
They seem more afraid of being stalled waiting an answer than they are of investing time in features that aren't developed.
This actually creates a really bad situation for the team.
What happens is team members will want to know all the details about any story before they start on that story.
This bad habit can begin for a number of reasons.
It could start, for example, because the time is under pressure to provide perfect estimates or because team member aren't comfortable with uncertainty.
These situations lead to a team trying to answer all questions about a story before being willing to start development on that story.
When the team does this, they're no longer overlapping work.
They're doing all the analysis on a Story before they start any design, coding, or testing on That Story.
Overlapping work is a central tenet in most Agile processes.
It's why we don't have phases in Agil.
So to avoid adding phases and keeping your agile process agile, here's what you need to do.
You've got to avoiding putting too much detail onto your user stories too early.
Thinking back to the balance between too much too soon and too little too late, you're better off being on the side of too-little-too-late.
If you are over there, it's easy to fix because the problems are so apparent.
You'll have team members stalled waiting for answers.
That will lead to too many stories being worked on concurrently during an iteration.
It's obvious when you add too Little detail too Late, and the fix is easy.
Just start adding a little more detail earlier until you've got it right.
It can be harder to notice the problem of adding too much detail too early because things appear to be going well.
No one is stalled waiting for answers.
The answer is all figured out before the iteration started.
The problem when we don't overlap work is that time-to-value starts getting stretched.
If you do your job and then give me what I need to do mine, the elapsed time to finish both jobs is longer than if we overlapped our work.
And that's the case even if overlapping makes our individual tasks take a bit longer because of the extra overhead of communicating.
The best way I've found to get the right amount of detail in your stories is by asking two questions.
The first is something to ask during product backlog refinement or similar discussions when team members are thinking about a story and whether enough
is known to gets started on it.
When someone on your team wants to lock down a detail about the story before starting work on the store, ask, do you need that answer before you start
on this story?
When someone tells me they need an answer to something or need to resolve some open issue, I always say, yes, you need and answer before you finish work
on that story.
But do you the answer you before start work?
on the story.
See the difference?
Consider a trivial example of whether a button should be red or blue.
The programmer absolutely needs to know which color to make the button, but the programmer doesn't need to that before starting on whatever feature requires
the new button.
So do you need an answer before you start on this story is our first question.
The second is something I ask in every retrospective.
Did we get answers just in time, in just enough detail?
The only way to really see how you're doing balancing too much too soon against too little too late is to ask after the story has been developed.
I like to do that during the sprint retrospective.
Whatever you decide by asking that in this sprint's retrospect, won't help the team in the spring, of course, but it will help them in coming sprints.
Teams can fine tune the amount of detail to add to their stories by iterating to that level by ask this question in every sprint,
retrospect.
There's clearly a Goldilocks amount a detail, an amount that isn't too much or too little, But just right and added just at the right time.
When you get this right, you'll spend less time in product backlog refinement meetings and discussions.
Team members will begin to embrace rather than fear uncertainty in the form of open issues.
And you reduce the amount of calendar time it takes to finish a feature, which will delight your customers.
It's not easy to balance this level of enough detail so the outcome is clear, but with enough flexibility for developers and testers to figure out the how.
Let's bring the three techniques we've discussed today together.
First, don't write stories one sprint at a time without a longer-term goal.
Periodically bring right people together, focus them on a significant objective, and write the stories that will help achieve it.
Second, get comfortable splitting stories into smaller pieces that show real progress.
Those pieces don't always need to be truly releasable on their own, but they should be high quality, tested, and useful steps towards something valuable.
And third, add just enough detail just in time.
Give the team what they need begin and continue answering questions as the work progresses rather than trying to eliminate every bit of uncertainty in advance.
These ideas are fairly straightforward when I explain them in a webinar.
Applying them with a real team and a product backlog can be harder.
You may have stories that repeatedly carry over from one sprint to the next.
Your refinement meetings may take too long without producing stories the team feels ready to work on.
Your backlog may be full, but not focused on a clear objective.
Or your product owner, team members, and stakeholders may have very different ideas about how much detail a story needs.
Those are exactly the kinds of problems we help companies solve.
Mountain Goat software works privately with teams and organizations that want to improve their user stories, product backlogs,
refinement practices, planning, an overall teamwork.
Sometimes that means bringing private user story training to a company.
Sometimes it means facilitating a focused workshop in which the team works directly on its own backlog with us.
And sometimes the best place to start is diagnosing why the teams current approach isn't producing the results everyone expected.
The important part is that we work with your situation, your team, and your actual work.
We don't just teach a technique and leave you to figure out how to apply it later.
So if you found yourself recognizing your time in some of today's examples, get in touch with us.
Check out the links below and tell us a little about what's happening with you stories or backlog and where your theme is getting stuck.
we can talk through what you've tried, what isn't working, or what type of help would be most useful.
You don't need to know which course, workshop, or service you need.
Start by describing the problem.
We'll help you think through the right next step.
I hope today has given you at least one idea you can try with your team immediately.
And if you'd like help putting these ideas into practice across your teamwork company, we'd be glad to hear from you.