It is a common occurrence with Scrum teams that they incorrectly slice user stories along application-layer or piecemeal lines rather than along functional-boundaries. What I mean by this is that teams will have a natural tendency to write backlog items that either 1) build the feature application-layer by application-layer or 2) describe what the user is going to do in piecemeal fashion, step-by-step. For example, in the case of a backlog item that represents a user searching for a flight and purchasing tickets (highly simplified, mind you), many inexperienced Scrum teams will slice out the items like this:

Application-Layer

1. Write the GUI pages to collect destination and origin cities, dates of travel, meal preferences, frequent flyer information, etc.
2. Write the GUI pages to show the user the flights that matched their criterion.
3. Write the GUI pages to collect credit card information.
4. Write the GUI page(s) to display the receipt for the user.
5. Write the scripting to validate the data.
6. Create the airline schedule database tables
7. Query the airline schedule database using the information collected from the user
8. Submit the user’s flight selection to the airline for validation and ticketing
9. Charge the user’s credit card.

Piecemeal Fashion

1. The user provides origin and destination cities, dates of travel, meals preferences, frequent flyer information, etc.
2. The system provides a list of flights for the user to view.
3. The user selects the desired outbound and return flights and selects “purchase.”
4. The user provides credit card payment information.
5. The system charges the card the requisite amount and provides a printable receipt for the user.
6. The user prints the receipt.

When the team sits down in their Sprint to complete these backlog items, they’re going to run into some problems. Let’s look at some of the problems generated by the “Application Layer” approach. First, they’ll discover that it’s far easier to work on two or three items at the same time — and before you interrupt me and say, “Why isn’t working on two or three stories at the same time a good thing?” consider what will happen when Harry the GUI builder finishes all of the GUI pages and then discovers there’s a UI standard he’s supposed to be following. That’s right — he has to go back into all of those stories and rework them. Chances are pretty good, however, that if the team had demonstrated a complete function, from UI to database, the Product Owner might have caught the UI standards issue. Then Harry would only have one item to fix, not all of them.

Here’s another scenario. Harry is a versatile developer; he can work on anything. In the current Sprint, he’s decided to work on the database set-up first, defining all of the tables needed for the airline flight schedules. He works diligently, setting up indices to maximize performance. He has to go back a few times to restructure the schema because of new data that has to be stored with regard to the flight schedules. Unfortunately, when he finally starts building the GUI, the Sprint ends. What does Harry have to show for his work? Nothing but an untested database and the beginnings of the GUI.

Here’s one more scenario. Let’s say Harry and his pals on the Scrum team spend two Sprints building a beautiful GUI and wonderfully performing database. At the beginning of the third Sprint, the team decides to begin addressing the integration with the airlines to check seat availability and then their customers a seat on the airplane (they’ve stubbed out the integration up until now by putting some temporary code there that acts like everything is working properly). That’s when they discover that they need to collect fifteen more pieces of information in order to actually reserve the seat! Now what? Now they have to go back and modify their database and modify their GUI all over again just to get to the point where they have real, working software. Which, now that I think about it, they haven’t really had during the first two Sprints either, since the integration with the airlines wasn’t real.

But that’s not how Scrum works! The end of a Sprint should have real, working software!

The piecemeal approach doesn’t work well either (since I’ve accosted Harry enough already, I’ll switch to Harriette for a while).

Harriette and her Scrum team are building the same functionality, but they sliced their stories in a piecemeal fashion. So, during the first Sprint, they plan on completing the part where the user provides enough information for the system to go query the flights. Right away, the team runs into a problem. The content of the single story that the team is focusing on is disparate, that the team members have to split up, each addressing different pieces of the item. While Harriette works on the GUI, another team member addresses the code changes necessary to support the feature, another works on writing test cases and acceptance tests, while the last team member updates the database schema to support the feature. The team has a little difficulty during the Sprint making sure that everyone understands the data being collected and makes the right changes to the tests and the database schema but, in the end, they finish the item.

Unfortunately, when they demonstrate it to the Product Owner during the Sprint Review, all it does is collect information and stick it in the database. The Product Owner is, to say the least, disappointed. What the team has completed during the Sprint has very little value because it doesn’t finish anything that the customer might find useful or interesting.

Its very, VERY important that Scrum teams focus on achieving end-to-end functionality by the end of the Sprint.

But how do we make this happen? We’ll talk about that in the next entry.

Happy Scrumming!