User Stories Applied:

For Agile Software Development

Ch 14. Catalog of “bad smells” stories

Chen Jing Fung @iii

2011/7/19

??? ???

Developer

Customer

???

???

Ref: Agile solutions (step by step) Choose your tool, How

to write, gather ideas, estimate the approach, planning an

iteration

Story Smells Catalogue

• The most important of user stories is talking

among customers/ developers/ stakeholders

– What’s discussion symptom?

– What’s mental activity?

Stories too small

Splitting too many stories!!

Including user interface detail too soon!!

Too many details!!

Stories too large [Interdependent stories]

Before / btw discussion

Developer Customer/

Stakeholder

Trouble prioritizing?

Afraid to take

responsibility!! Thinking too for

ahead !!

Mental

activity

Discussion

symptom

Gold plating?

Discussion symptom(I)–Small, many details

Too Small Stories

• Symptom: – Revise estimates frequently

• Example:

– Overlapping work btw 2 stories

– Time spent on one story will reduce the time on the other

• Solution: – Combine stories for planning

purposes

– Done out of an iteration => split them

Too Many Details - content

• Symptom: – Gather detail more before story

being implemented

– Writing stories than talking

• Solution: – Force to write stories on

smaller card.

Search results may be saved to

an XML file

Search results may be saved to

an HTML file Including UI Detail early

• Symptom: – Early in a project (especially a new

product) => include detail about user interface (UI)

A Job Seeker can

view information about the hiring company

from the Job Description page

When viewing details about a job, a Job

Seeker may view information about the hiring

company

interface

Discussion symptom(II)–Split more/hard to split

Split more stories

• Symptom: – Frequently splitting stories

during iteration planning

• 2 reasons for the problem – Story is too large in the

iteration

– Story contains both high & low sub stories

• Customer only wants high priority sub-stories

• Solution – Split to the team’s

observed velocity

– Taking a pass to split the other stories

Hard to split stories <= interdependent stories

• Symptom: – Dependencies btw stories =>

difficulty to plan in an iteration

– Look at how interdependent stories appear to be separated

• According to functionality

• Ex: involve functionality from all layers of the application

A B relative

if too small A A B

New story

if ~ appropriately size A

Mental activity(I) about developer & customer

Gold plating

• Symptom – Add unnecessary features

– interpret stories liberally

• Why? – Like “wow” the customer

– Brief chance to escape the pressure (a spring)

– Enjoy putting their own mark

• Find it!! – Btw iteration: daily meeting

• Visibility of the tasks ↑

– End-iteration: demo new functionality

– QA help identify out

Thinking too far ahead

• Symptom – Stories are hard to fit on note cards

– Capture all details in a story template (team size or location)

– Give finer estimate (hours)

• Spend more efforts to large upfront “requirements”

• Overcome method: – Refresher course on the stories

(re-choose stories to fit the approach)

– Through repeated iterations to add amount of details

• Impossible to identify all requirement in advance (problem!!)

– The team need to remind itself • Their prior development process to

adopt stories

Developer Customer

Rough

estimate

Mental activity(II) for customer

Customer – trouble prioritizing

• Symptom – Difficulty to priority

• Why? – Stories too large => split it!!

– Not write/clear the business value => rewrite!! (not just task)

• Example

Customer – not write & prioritize the stories

• Symptom – Get behind responsibility

• Why?

• Solution – Let the customer off the hook

– Show to get fully charge!! • Private conversation

1. A user connects to the database via a

connection pool.

2. A user can view detailed error information in a

log file.

1. A user can start the application without noticeable

lag while connecting to the database.

2. Whenever an error occurs, users are given enough

information to know how to correct the error.

Business value

In a blame-filled org.

To avoid all

responsibility

Want nothing to do

Feedback: “It’s not my

problem!!”

Can’t fail!

I can take

Summary • Affect our project to correct approach!!

– Customers or developers have responsibility to detect any bad smells

• Bad smells will happen during discussion – Stories too small write on card!!

» Split to many stories, include user interface too soon, too many details

– Stories too large re-election stories!!

» Interdependent stories

• Bad smells will be from some moon btw developers & customers

– Developers: gold plating QA measure it in this iteration & (backlog) next iteration planning can talk it

– Developers & customers: think too far away rough estimate!!

– customers:

» trouble priorities show business value!!

» reject to take responsibility I can take all responsibility

Developer

Customer

Ref: Agile solutions (step by step) Choose your tool, How to write, gather ideas,

estimate the approach, planning an iteration