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 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.
