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 User Stories | The complete Review

The main sections of this presentation
1. Overview
2. Story Points vs. Time Estimations
3. The responsibilities
4. The benefits of using stories
5. How to write great stories
6. The mistake you can do when writing stories
7. A Template for writing stories
8. Key components of stories

Agile User Stories | The complete Review

  1. 1. AGILE USER STORIES THE COMPLETE STORY DAVID TZEMACH WWW.DTVISIONTECH.COM FEB 9 2016
  2. 2. WHAT IS A USER STORY…? • STORIES ARE ADDED TO THE PROJECT “BACKLOG” AND FROM THERE TO THE “SPRINT BACKLOG”. • AFTER IMPLEMENTATION, EACH STORY SHOULD ADD VALUE TO THE OVERALL EFFORT. • EVERY STORY SHOULD BE VISIBLE AND UNDERSTANDABLE TO EACH TEAM MEMBER. • THE STORY SHOULD BE WRITTEN BASED ON THE CLIENT PERSPECTIVE. • A STORY IS A BASIC DESCRIPTION ABOUT WHAT THE CUSTOMER WANTS TO ACCOMPLISH DURING THE APPLICATION DEVELOPMENT CYCLE. • EACH STORY PROVIDES AN ALTERNATIVE VISION FOR MANAGING THE REQUIREMENTS OF THE SOFTWARE.
  3. 3. USER STORY – STORY POINTS VS. TIME ESTIMATIONS • EACH USER STORY WILL BE ESTIMATED BY “STORY POINTS” INSTEAD OF HOURS. • EACH TEAM MEMBER HAVE THE POWER TO AFFECT THE ESTIMATIONS BY USING IS VOTE. • THE ESTIMATIONS ARE MADE BY THE SCRUM TEAM MEMBERS. • THE PRODUCT OWNER IS NOT PART OF THE VOTING CYCLES. • STORY POINTS CAN BE TRANSLATED INTO : • SHIRT SIZE (XS -> S -> M -> L -> XL -> XXL). • FIBONACCI SEQUENCE (1 -> 2 -> 3 -> 5 -> 8 -> 13 -> 21) • NUMERIC NUMBERS BETWEEN 1-10
  4. 4. USER STORIES – THE RESPONSIBILITIES
  5. 5. THE BENEFITS OF USER STORIES
  6. 6. THE BENEFITS (1) • THE PROCESS OF WRITING “USER STORIES” IS A GREAT WAY TO INCREASE THE COLLABORATION BETWEEN THE TEAM MEMBERS. • USER STORIES WILL HELP TO CREATE A BASELINE OF KNOWLEDGE AND EXPECTATIONS AMONG THE TEAM MEMBERS.
  7. 7. THE BENEFITS (2) • USER STORIES ARE GREAT WHEN YOU ARE WORKING WITH AGILE METHODOLOGY THAT EMPATHIES SHORT ITERATIONS/SPRINTS. • USER STORIES WILL HELP TO DETERMINE THE TIMELINES AND EFFORT OF EACH SPRINT.
  8. 8. THE BENEFITS (3) • USER STORIES WILL HELP TO UNDERSTAND THE SCALE OF THE PROJECT. • THE CLIENT DESCRIBES THE EXACT DEMANDS OF THE APPLICATION. • USER STORIES WILL HELP THE TEAM MEMBERS TO MONITOR THE PROJECT PROCESS.
  9. 9. HOW TO WRITE AN EFFECTIVE STORIES
  10. 10. THE GUIDELINES (1) • THE SIZE OF THE STORY SHOULD BE SMALL ENOUGH IN A WAY THAT IT CAN BE DEVELOPED AND TESTED IN A SINGLE SPRINT. • EVERY STORY SHOULD ADD VALUE TO THE OVERALL EFFORT. • A GOOD STORY IS THE ONE THAT YOU CAN ESTIMATE (TIMELINES, EFFORT ETC.).
  11. 11. THE GUIDELINES (2) • EACH STORY SHOULD BE INDEPENDENT (DEPENDENCIES MAY AFFECT THE PRIORITIZATION AND TIME ESTIMATIONS). • THE STORY SHOULD BE FLEXIBLE TO CHANGES. • THE USER STORY SHOULD BE TESTABLE.
  12. 12. THE MISTAKES YOU CAN DO WHEN WRITING STORIES
  13. 13. THE MISTAKES YOU CAN DO (1) • STORIES THAT ARE WRITTEN WITHOUT A PRELIMINARY CONVERSATION. • STORIES THAT ARE WRITTEN FROM A TECHNICAL PERSPECTIVE ONLY. • TOO MUCH DETAIL ON A SINGLE STORY (KEEP IT SIMPLE).
  14. 14. THE MISTAKES YOU CAN DO (2) • STORIES THAT DOESN’T CONTAIN THE “ACCEPTANCE” CRITERIA. • STORIES THAT DOESN’T CONTAIN THE “DONE” CRITERIA. • STORIES THAT DOESN’T CONTAIN THE REQUIREMENTS AND SPECIFICATIONS
  15. 15. THE MISTAKES YOU CAN DO (3) • STORIES THAT ARE TOO BIG TO HANDLE ON A SINGLE SPRINT • STORIES THAT HAVE TOO MANY DEPENDENCIES • STORIES WITH HIGH UNCERTAINTY
  16. 16. MY SUGGESTED TEMPLATE FOR WRITING USER STORIES
  17. 17. STORY TEMPLATE (TITLE) • THE TITLE IS BUILT FROM MAX OF 12 WORDS, AND SHOULD DESCRIBE THE MAIN GOAL OF THE STORY. • THE TITLE SHOULD BE UNIQUE TO THIS STORY SO THE SCRUM TEAM CAN DIFFERENTIATE IT FROM OTHER STORIES THAT APPEAR ON THE BACKLOG.
  18. 18. STORY TEMPLATE (DESCRIPTION) • THE BASIC DESCRIPTION CAN FOLLOW THIS TEMPLATE: AS A <USER>, I WANT <TO ACHIEVE SOME GOAL> SO THAT <I CAN ACCOMPLISH…>. • THE DESCRIPTION SHOULD FIT TO THE INDEX CARD.
  19. 19. ACCEPTANCE CRITERIA WHAT ARE THE PRELIMINARY REQUIREMENTS THAT NEED TO FULFILL PRIOR TO THE TEAM CAN START TO WORK ON A STORY. EXAMPLES: • ALL BUGS THAT AFFECT THIS STORY ARE NOW FIXED AND VERIFIED. • DEPENDENCIES ON OTHER TASKS ARE NOW REMOVED. • THE AVAILABILITY OF REQUIREMENTS
  20. 20. THE REQUIREMENTS FOR THIS STORY EVERY STORY SHOULD INCLUDE THE REQUIREMENTS, THAT DETERMINES HOW THE TEAM SHOULD DEVELOP AND TEST THE STORY.
  21. 21. THE “DONE” CRITERIA • WHAT ARE THE CRITERIA THAT DEFINE IF THE TEAM ACCOMPLISHED THE STORY..? • THE “DONE” CRITERIA CAN BE CHANGED DURING THE CYCLE (BASED ON THE CHANGED EFFORT PER STORY). • A STORY CAN MARK AS “COMPLETED” ONLY WHEN THE TEAM ACCOMPLISH THIS CRITERIA.
  22. 22. EXAMPLES OF “DONE” CRITERIA THERE ARE MANY DIFFERENT STORIES THAT YOU NEED TO ACHIEVE DURING EACH SPRINT, THIS ARE FEW BASIC EXAMPLES OF WHAT CAN BE USED AS “DONE” CRITERIA: • THE FUNCTIONALITY IS READY FOR RELEASE. • THE CODE IS COVERED BY UNIT TESTS. • DESIGN DOCUMENTS WERE CREATED. • THERE WHERE NO REMAINING BUGS. • CODE REVIEW WAS DONE. • THE TESTING WAS DONE. • AUTOMATION IS READY.
  23. 23. FOR ADDITIONAL KB’S PLEASE VISIT MY BLOG WWW.DTVISIONTECH.COM

×