Splitting User Stories – Agile Practices

Hi I’m Mark. I help organizations write
software more efficiently. The Agile principles say that we should try to deliver software
to the user frequently and that we need to do our best to strive for simplicity and only
build what is necessary and important. Both of those things require a great deal of skill
and practice in the way we organize our work. In this video we are going to talk about how
to slice our work into valuable user stories that are small enough that they can be completed
in a reasonable amount of time while still being valuable enough that they represent
progress to the user. If we want to create stories from the perspective
of the user, we need to think about the application the way the user thinks about it. Developers
tend to see the application as a stack. There is the hardware at the bottom. On top of that
is the operating systems. Then comes the database and application server. Then we have a database
access layer. Above that is the service or business logic layer. Somewhere above that
is the code that is responsible for the GUI. Everything is stacked on top of each other
like a cake. So a developer is likely to think in terms of stories like: As a developer
I want a service layer So the application logic is separated from
the GUI. As a developer
I want a GUI layer So the so the user can interact with the system. Having a service layer is a good. Having a
GUI layer is good. But having stories to build each of these layers violates our principles,
but it is easy to see why we might end up with stories like this when we recognize the
way developers think about an application. But what about the user? We want our stories
to start off as fiction from the user’s point of view. It represents the way the user’s
world will look once the story is completed. To write good stories about the user’s world,
we need to understand how they think about the software applications.
A user will think of an application in terms of the behavior they find valuable. So they
might think of an accounting system as consisting of the part that lets them create invoices,
the part that lets them pay bills, and the part that lets them balance their accounts.
They may know that creating an invoice means doing something in the GUI that gets passed
on to the business rules and eventually ends up in the database, but that isn’t how the
application is organized to them. A developer sees an application as a collection
of layers of cake that are stacked on top of each other, but users see the application
as a collection of slices of cake that represent the different things they need to do. The
fact that there is a database doing something toward the bottom of their slice of functionality
is important but only to the extent that it is necessary to support that slice of functionality.
If we could build software the same way users think about (and use) software, we could deliver
value much more quickly. It is a nice thought, but everyone knows you can’t build a house
one slice at a time. For that matter you can’t just create one slice of a multilayer cake.
You have to start at the bottom right? Absolutely—IF you are building a house or cake, but we are
developing software. Code is not at all constrained by the same physical properties of buildings
and deserts. We actually can build a slice of functionality
in software. If it seems hard to do, it is because we are too set in our ways of thinking
of writing code as a construction or baking project where you have to complete one layer
before putting anything above it. If you want to think of writing code in terms of some
other activity, think of writing music. Bach didn’t have to write the entire bass part
of a fugue before he could go back and put the other voices in layer by layer. Instead
he could write a few bars for all the parts and try it out before moving on. Or think
of a symphony. Composers don’t write hundreds of bars of base drum before going back to
add the next instrument. Instead they write music several bars at a time with different
voices interacting together. They may even finish a section and have it played to decide
how well it works. They create valuable slices the same way that users think of our applications—the
same way we should develop our code. As we’ve mentioned before, the size of a
story can vary from team to team, but a good starting place is to make stories represent
what you think will take one or two days worth of work. This may sound like a a contradiction.
We just talked about creating stories that represent an entire slice of user functionality
and now we are saying the slices shouldn’t take more than a few days. How can you create
something useful for a user in a few days if you don’t even have you database layer
setup? This is where the skill of splitting user
stories comes to bear. Yes it is hard at first, but it is possible. If you can take a story
that is going to take more than a few days and split it into several stories that are
shorter you’ve done two things. First, you’ve created smaller units of work so we can keep
everything closer to the same size. Second, you have now created the chance to prioritize
the stories differently. This is a very valuable thing for the user because if some of the
resulting stories are lower priority and can be deferred until later, the user can instead
focus on stories that are higher value. Splitting stories is a way to increase the user return
on investment. But how do you split stories? Lets look back
at our music example to see if it gives us any ideas. Many composers of large scale works
would write the most important parts of their ideas in slices (measures) at a time for a
reduced number of instruments and then come back and fill in the supporting parts once
they had proven out the overall idea. They would write the 20 percent that gave 80 percent
of the value and then come back later and enhance it.
There are some pieces of functionality without which no value has been created. There are
others that are very important but their absence doesn’t block value. Think about a checkout
process for a web store. You add items to a cart, click the checkout button, login so
you don’t have to type in your address information, choose how you want to pay, type your payment
information, and complete the purchase. Is there anything in that process that could
be left out in providing a first slice of value? What if we didn’t bother with the
login? Everyone just types in their information to checkout. Can we split it to something
even simpler that adds value? We could do away with the idea of a cart and just have
a buy button that takes you to the payment page to purchase one item at a time. What
if our first story is just to get the catalog available online so customers can find products,
but to order they still call the 800 number? So what started out as a sizable story is
now a matter of hooking your database up to the web to display products. People can actually
find the products online which adds quite a bit of value even if they have to call to
place an order while you build the next piece. Even if you decide not to push this version
all the way into production, you still have created something the user can exercise and
provide feedback. Now you might look at this and say it is way
to small. You can get the product information into web pages in 45 minutes. Don’t forget
we are building the full slice of functionality though. That means you’ll need to setup
your database to allow access. You also may need to setup the web server and make sure
it integrates into your existing site. There are many things that need to happen to make
this seemingly small story work. Of course that is the point, make the story small because
there are a bunch of other layers that need to be in place.
With rudimentary capability to let a visitor see a product, users can figure out what the
next most important piece is they want to see built. Maybe it is the ability to buy
a single product and process the credit card transaction. Maybe once they have seen the
products online they realize that displaying related items is actually a higher priority
than online checkout. By splitting the story into something small, they now have options
on what to do next that they wouldn’t have if everything was all in the same big story.
These options mean work can be prioritized. Creating software with slices of value isn’t
easy. It takes a lot of practice, but it is well worth the effort because it gives you
the ability to create a constant flow of valuable, usable functionality for your users.

Comments 35

  • Thanks for this Mr Mark Shead, I have learned a lot this Tutorials.

  • I would also recommend you to make a tutorial in TDD and Unit Testing using any Java, C# Programming or Android Development.

  • Your tutorials are very easy to understand and nicely animated 🙂 Thank you!

  • how you make animation brother.

  • What if your slice of software is built of many other slices that only have value when they're all together?

    For example with a house, its only valuable when it's built since you can't use it otherwise.

  • Hi Mark, I work as QA and since last 1 year using BDD techniques for writing user stories in 3 amigo sessions.
    Please share your thoughts on breaking down "Big Story" into small meaning chunks with help of "Example Mapping" techniques in cucumber website.
    Example Mapping helps in creating Rules & Concrete Example and prioritize those for each sprint. Thanks in advance.

  • Really EXCELLENT video to explain the concept! I'll be using this in a training tomorrow. Thanks for this.

  • I have been searching for something that would explain to a person coming from a conventional background like me on how we can split user stories. Finally found a video which explains it in such a simple and intuitive way. Thank You.

  • How to move stories in jira

  • nice vid thanks mate

  • Yes it did. Still …. not easy with only backend team

  • Thanks for the videos Mark, you have very good content and i would say point on to clarity. Really helpful!

  • Well, this is a very good presentation, but the title should be "WHY splitting user stories".
    The hardest part is, in fact, HOW to do this. And that's another …story.

  • Nice one

  • Great job man👏👏

  • Hi Mark very helpfull and Thank you so much . Please take a lesson on BRD ,FRD and RTM.

  • Great Video Mark, looking forward to learn more from your videos 🙂

  • Great video thank you Mark, hope you have an amazing day!!😁

  • Excellent video very helpful and very well explained. thank you

  • That's BY FAR the best explanation for this topic I've found on the Internet. Simple, easy to understand and straight to the point.

  • Thanks for these Agile videos. They are fantastic and very helpful. We are trying to use more Agile principles in our team. Question: when using an agile approach, where we can't be completely sure of the user's detailed requirements at the start, how can we give estimates of timescales and plan the overall project and know we will hit the target end date?

  • great explanation – resonated well!

  • Like your videos Mark & their emphasis on the Agile Principles. FYI These "User stories" seem similar/analogous to "use cases" in UML and "work products" in PERT/Gantt project planning terminology.

  • Really impressive tutorial… everything made so easy to understand… yes, many of us know this but to explain it in such a way is an art… Thank you for this.

  • Excellent Tutorial but the animated cartoon character… really differ from your actual face.. haha

  • G U I. Not gooey

  • Nice explanations but there are several forces here. The smaller you make the stories the more interdependence you have between them. Story mapping or starting with usage scenarios can help here. The goal shouldn't be to split the story into something that can be done in 2-3 days. That's wildly arbitrary. The goal should be to break the story down as small as possible while still deliver value. In iterationless methodologies, smaller stories becomes an optimization rather than a requirement to fit in an iteration. I advise teams to start by making the stories small enough to fit in an iteration. Then offer techniques for splitting such as using the Acceptance Criteria as and outcome based value for a story to split off from.

  • Love this illustration, this is how agile development should be..Thanks Mark

  • I really enjoyed your videos…great job!!!

  • Very well explained using user and manufacturer perceptions of a cake as an analogy

  • Why can't you explain in terms of how things are actually done at work using the appropriate technical lingo? Your audience is NOT a 5th grader. Your audience is a technical person who has the know how about how agile works but may not know the details.

  • Simply brilliant…thx

  • Thank you so much for such a good quality video!

  • First explains the programmer thinks of things as layers and you need one layer to build the other but later on, in the final story, assumes database is already done so bottom layer is already there.

  • If you are customer focused it is inevitable that you will want to get the User Interface done first. It is 99% sure that the customers will want significant changes. You do NOT want to spend two years perfectly writing the wrong code to the wrong specification. It is incredible hard to start out with a blank piece of paper and describe the perfect finished system. If you have the technical knowledge to write a software specification it is unlikely you have the domain knowledge to know what needs to be done., Users are non-software people and may have in depth domain knowledge (correcting an error in the general ledger after the monthly statement has been closed out) but look at the world very differently than software developers who have to worry about "how do I do that?" If you start out with "how do I do that?" you will end up with an ugly "what do I allow people to do and how do they do it". Amazon and Google have nearly invisible interfaces because they have really looked at how users want to use something. Not how the software is structured to accomplish the objective.

Leave a Reply

Your email address will not be published. Required fields are marked *