Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

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

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