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.