Affect our project to correct approach!! Customers or developers have responsibility to detect any bad smells...

1. User Stories Applied:
For Agile Software Development
Ch 14. Catalog of “bad smells” stories
???
??? ??? ???
Developer
Customer
Chen Jing Fung @iii
2011/7/19
Ref: Agile solutions (step by step) Choose your tool, How
to write, gather ideas, estimate the approach, planning an
iteration

2. Story Smells Catalogue
• The most important of user stories is talking
among customers/ developers/ stakeholders
– What’s discussion symptom?
– What’s mental activity?  Trouble prioritizing?
 Afraid to take
Mental  Gold plating? Thinking too for responsibility!!
activity ahead !!
Developer Customer/
Stakeholder
Before / btw discussion
Discussion Stories too small
symptom Splitting too many stories!!
Including user interface detail too soon!!
Too many details!!
Stories too large [Interdependent stories]

3. Discussion symptom(I)–Small, many details
Too Small Stories Too Many Details - content
• Symptom: • Symptom:
– Revise estimates frequently – Gather detail more before story
being implemented
• Example:
– Writing stories than talking
Search results may be saved to • Solution:
an XML file – Force to write stories on
Search results may be saved to smaller card.
an HTML file Including UI Detail early
• Symptom:
– Overlapping work btw 2 – Early in a project (especially a new
stories product) => include detail about
user interface (UI)
– Time spent on one story will
reduce the time on the other A Job Seeker can
view information about the hiring company
• Solution: from the Job Description page
– Combine stories for planning interface
purposes
– Done out of an iteration => When viewing details about a job, a Job
split them Seeker may view information about the hiring
company

4. Discussion symptom(II)–Split more/hard to split
Split more stories Hard to split stories <=
• Symptom: interdependent stories
– Frequently splitting stories • Symptom:
during iteration planning – Dependencies btw stories =>
• 2 reasons for the problem difficulty to plan in an iteration
– Story is too large in the relative
A B
iteration New story
– Story contains both high &
if A too small A B
low sub stories
• Customer only wants high
priority sub-stories if A ~ appropriately size
• Solution – Look at how interdependent
– Split to the team’s stories appear to be
observed velocity separated
– Taking a pass to split the • According to functionality
other stories • Ex: involve functionality from
all layers of the application

5. Mental activity(I) about developer & customer
Developer Customer
Gold plating Thinking too far ahead
• Symptom • Symptom
– Add unnecessary features – Stories are hard to fit on note cards
– interpret stories liberally – Capture all details in a story
template (team size or location)
• Why? – Give finer estimate (hours)
– Like “wow” the customer
– Brief chance to escape the
• Spend more efforts to large
pressure (a spring) upfront “requirements” Rough
– Enjoy putting their own mark • Overcome method: estimate
– Refresher course on the stories
(re-choose stories to fit the
• Find it!! approach)
– Btw iteration: daily meeting – Through repeated iterations to add
• Visibility of the tasks ↑ amount of details
– End-iteration: demo new • Impossible to identify all requirement
functionality in advance (problem!!)
– QA help identify out – The team need to remind itself
• Their prior development process to
adopt stories

6. Mental activity(II) for customer
Customer – trouble prioritizing Customer – not write &
• Symptom prioritize the stories
– Difficulty to priority • Symptom
• Why? – Get behind responsibility
– Stories too large => split it!! • Why? In a blame-filled org.
– Not write/clear the business Can’t fail!
value => rewrite!! (not just
task) To avoid all
responsibility
• Example
1. A user connects to the database via a
connection pool. Want nothing to do
2. A user can view detailed error information in a
log file.
Feedback: “It’s not my
Business value problem!!”
• Solution
1. A user can start the application without noticeable
lag while connecting to the database. – Let the customer off the hook
2. Whenever an error occurs, users are given enough – Show to get fully charge!!
information to know how to correct the error. • Private conversation I can take

7. 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!!
Developer
» Interdependent stories
Customer
• 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
Ref: Agile solutions (step by step) Choose your tool, How to write, gather ideas,
estimate the approach, planning an iteration