Agile catalog of story smells


Published on

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

  • Be the first to comment

  • Be the first to like this

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

Agile catalog of story smells

  1. 1. User Stories Applied: For Agile Software DevelopmentCh 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. 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 discussionDiscussion Stories too small symptom Splitting too many stories!! Including user interface detail too soon!! Too many details!! Stories too large [Interdependent stories]
  3. 3. Discussion symptom(I)–Small, many detailsToo 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. 4. Discussion symptom(II)–Split more/hard to splitSplit 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. 5. Mental activity(I) about developer & customer Developer CustomerGold 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. 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!!” • Solution1. A user can start the application without noticeable lag while connecting to the database. – Let the customer off the hook2. 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. 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 responsibilityRef: Agile solutions (step by step) Choose your tool, How to write, gather ideas,estimate the approach, planning an iteration