Story mapping Dreadful Dungeons. Agile practices beyond workplace
Agile catalog of story smells
-
Upload
fungfung-chen -
Category
Business
-
view
2.523 -
download
1
description
Transcript of Agile catalog of story smells
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