How Thin is Thin? Effective User Story Slicing

How Thin is Thin? Effective Story Slicing

Gatineau-Ottawa Agile Tour November 21, 2016

1


Who is this guy?

2

•Software Development Manager at You.i TV

•Recovering Developer & Agilist, but frequently falls off the wagon

•Coding since C wasn’t even a teenager yet and Java was something you drank

•Part of the Agile community for this entire century


But enough about me! Who are you?

3

• Product Managers? • Product Owners? • Business Analysts? • ScrumMasters? • Developers? • QA? • UX? • Architects? • Management? • ???


4

Why Use Small Stories?

• Better flow • Better focus • Reduced risk • Improved visibility


5

Why Small?


6

So What Does Thin Mean?

User Interface

Web Server

Application Server

Business Logic

Database

Story

• A single “slice” through all layers of a system

• Just enough functionality to provide value to the Product Owner

• The Team can easily identify what has to be done to deliver the story


7

DatabaseRemote API

What About non-Web Systems? There’s no difference!

User Interface

Business Logic

Database

Story

User Interface

Business Logic

Story

API Gateway

Business Logic

Story


8

A “Real World” Example - The Point of Sale (POS) System

•Client was building a web-based POS system for salespeople taking orders in the field

•The orders would be stored in the POS database, but they would also be sent to the Oracle back-end eBusiness Suite

•Customer and Product data would come from the Oracle eBusiness Suite


9

The First Story

• Used Personas and Story Mapping to identify how the system would support the work of the salespeople

• The Product Owner determined that the most fundamental aspect of the system was to create orders


10

The First Story

TOO BIG!

• Used Personas and Story Mapping to identify how the system would support the work of the salespeople

• The Product Owner determined that the most fundamental aspect of the system was to create orders

So what do we really need?


12

For the first Story...


13

For the first Story...

• Didn’t create tables for the Customer or Product

• Used hard-coded values for both

• No validation of those values

• Simple web page with “Create Order” button

• Second page to show that the order was created (could have even been validated with an SQL query!)


14

Was This Story “Thin”?

User Interface

Web Server

Application Server

Business Logic

Database

Story


• Required work in all layers and created the foundation for all later stories


• An Order was created


• Very small, easily verified


15

The Next Story...


16

The Next Story...

• Still using a hard-coded value for the Product

• Customer ID is entered manually

• Still no validation of those values

• Web page now has a text field for the Customer ID as well as“Create Order” button



17

Still “Thin”?

User Interface

Web Server

Application Server

Business Logic

Database

Story



• An Order was created with the specified Customer ID




18

The Next Next Story...


19

The Next Next Story...

• Still using a hard-coded value for the Product

• Customer is selected from a list of valid customers, but hard-coded into the page

• No validation of the product, but the customer will be valid

• Web page now has a drop-down list for the Customer as well as the “Create Order” button



20

Are we still “Thin”?

User Interface

Web Server

Application Server

Business Logic

Database

Story



• An Order was created with the selected Customer ID




21

The Stories Continue...


22

The Stories Continue...

• The Product ID is entered in a text field


• No validation of the product, but the customer will be valid

• Web page now has a drop-down list for the Customer, a text field for the Product and a “Create Order” button

• Second page to show that the order was created


23


User Interface

Web Server

Application Server

Business Logic

Database

Story




• An Order was created with the selected Customer ID and a Line Item was added for the Product ID entered




24

Let’s Skip Ahead A Bit…


25

Let’s Skip Ahead A Bit…

• We can now enter multiple Products selected from a list, hard-coded into the page


• Both the product and customer will be valid

• Web page now has a drop-down list for the Customer, multiple drop-down lists for the Products and a “Create Order” button

• Second page to show that the order was created


26


User Interface

Web Server

Application Server

Business Logic

Database

Story




• An Order was created with the selected Customer ID and Line Items were created for each of the Products




27

Ahead even further…


28

Ahead even further…

• Both stories use the back-end Product and Customer services to fill the drop-down lists

• The lists are valid as of the time the page is rendered since they’re using the most up to date data

• The page is now a classic master/detail view with line items for the products


29


User Interface

Web Server

Application Server

Business Logic

Database

Story



• An Order was created using valid Customers and Products from the back-end services




30

All of that from One Story!

• We built out Create Order using many small, valuable slices

• Each one delivered value

• Each one further reduced risk

• Each one was tested:

• JUnit microtests at the code level

• Cucumber scenarios at the story level

• Each one allowed incremental delivery of the system architecture


So what did we just see?

• We used hard-coded values to simplify by excluding any processing of user data entry

• A simple UI was used that was barely sufficient to support the stories

• No validation of data entered before it was really required • A story that had no “child” records was followed by a story with

one child then a story with many children • Although the final system would have an interface with the

Oracle back-end services, we deferred using that interface until it was necessary

31


32

Story Splitting Patterns

• Hard coding values; • Simple interface; • Defer validation; • Zero, then One, then Many (with the Products); • Defer complexity (with the back-end Services).


Exercise: The Digital Personal Video Recorder (PVR)

33

•Process: •Break out into groups of 6-10 (e.g. your table) •Don’t worry about hardware details, focus on the stories about

someone will use the PVR •Brainstorm the high-level functionality that should exist •Brainstorm the stories that will deliver that functionality iteratively and

incrementally


• The system downloads program information over Ethernet. • The user can configure the following:

• Maximum number of episodes to record • Finding the same show on other channels • Time to keep the episodes before automatically deleting them • Record only new or new and repeat episodes

• Shows can be rated when watched. This information is anonymously fed to an online service that tracks ratings.

• The system makes recommendations based on what you like compared to what other people like (all anonymously).

• The system integrates with social media like FaceBook, Twitter, etc.

Exercise: The Digital Personal Video Recorder (PVR)

34


Resources & Further Reading

• Story Splitting Patterns

• User Stories - An Agile Introduction

• How to Enable Estimate-Free Development

• It’s Just a Feature-for-Feature Port

35

• Questions about the session? Contact me at [email protected]

• Interested in changing the world of video? We’re hiring at You.i TV!

http://agileforall.com/wp-content/uploads/2012/01/Story-Splitting-Flowchart.pdf

http://www.agilemodeling.com/artifacts/userStory.htm

http://blog.daverooney.ca/2014/09/how-to-enable-estimate-free-development.html

http://blog.daverooney.ca/2015/04/its-just-feature-for-feature-port.html

mailto:[email protected]?subject=GOAT%202016%20Question

http://www.youi.tv/about/careers/