User stories used in scrum to manage the customer requirements in software development projects, the importance of writing a good user stories is crucial to the success of the projects and therefore they must be written correctly (Small, Informative, Spark conversation Etc. ) to allow the scrum team to reduce misunderstandings and focusing on delivering value to the customer. Writing user stories may seem to be simple but believe me that they are not; there are many ways you can mess it up (Incomplete, inconsistent or missing valuable parts such ass acceptance criteria/DOD), to avoid this common mistakes, I created this list of the most common pitfalls you must avoid while creating your stories.

1. DAVID TZEMACH
MAR 14 2018
THINGS TO AVOID WHEN
WRITING USER STORIES

2. USER STORIES USED IN SCRUM TO MANAGE THE
CUSTOMER REQUIREMENTS IN SOFTWARE
DEVELOPMENT PROJECTS, THE IMPORTANCE OF
WRITING A GOOD USER STORIES IS CRUCIAL TO THE
SUCCESS OF THE PROJECTS AND THEREFORE THEY MUST
BE WRITTEN CORRECTLY (SMALL, INFORMATIVE, SPARK
CONVERSATION ETC. ) TO ALLOW THE SCRUM TEAM
TO REDUCE MISUNDERSTANDINGS AND FOCUSING ON
DELIVERING VALUE TO THE CUSTOMER.
WRITING USER STORIES MAY SEEM TO BE SIMPLE BUT
BELIEVE ME THAT THEY ARE NOT; THERE ARE MANY
WAYS YOU CAN MESS IT UP (INCOMPLETE,
INCONSISTENT OR MISSING VALUABLE PARTS SUCH ASS
ACCEPTANCE CRITERIA/DOD), TO AVOID THIS
COMMON MISTAKES, I CREATED THIS LIST OF THE MOST
COMMON PITFALLS YOU MUST AVOID WHILE CREATING
YOUR STORIES.

3. LARGE STORIES THAT INCREASING THE WORK EFFORT
ALTHOUGH THE AGILE METHODOLOGY PROVIDES SOME GREAT
PROCESS AND TOOLS TO HANDLE DELAYS AND BOTTLENECKS
THAT MAY ARISE DURING THE ITERATION (MOVE IT TO THE NEXT
ITERATION, REWORK AND MODIFY THE STORY ETC.), WE WANT
AVOID THIS SCENARIOS BY CREATING STORIES THAT WILL ALLOW
THE TEAM TO TAKE COMMITMENTS THAT BASED ON SHORT
UNITS OF WORK. STORIES THAT CREATED WITH THE ORIGINAL
SCOPE THAT DETERMINED BY THE TEAM DURING THE PLANNING
MEETING AND MODIFIED DURING THE ITERATION MAY INCREASE
THE SCOPE OF THE STORY IN A WAY THAT WILL REDUCE THE
PERCENTAGE OF THE TEAM TO MEET THEIR ORIGINAL
COMMITMENTS.
STORIES THAT ARE CHANGED THROUGHOUT THE ITERATION ARE
MORE THAN WELCOME, THIS IS AGILE ALL ABOUT (WE EMBRACE
CHANGES IN REQUIREMENTS TO SATISFY THE EXACT NEEDS OF
THE CUSTOMER). HOWEVER, THERE IS A WAY TO HANDLE THESE
REQUIREMENTS BY SPLITTING THE ORIGINAL STORY INTO TWO
(OR MORE) STORIES THAT WILL ALLOW THE TEAM TO FOCUS ON
THEIR ORIGINAL COMMITMENTS AND THEN HANDLING THE NEW
STORIES.

4. LACK OF VISIBILITY
STORIES THAT ARE NOT VISIBLE
TO THE RELEVANT
STAKEHOLDERS CAN LEAD TO
MANY PROBLEMS SUCH A LACK
OF COMMUNICATION, FAILURE
TO UNDERSTAND THE “BIG”
PICTURE AND MOST
IMPORTANTLY THE ABILITY TO
MAKE AN EFFICIENT
PRIORITIZATION.

5. TECHNICAL TASKS THAT WERE WRITTEN AS USER
STORIES
THERE IS A REASON THAT USER STORIES
CONTAINING TASKS AND NO THE OPPOSITES,
TASKS SHOULD NOT BE ADDED TO THE
PRODUCT BACKLOG IN A MAKEUP OF USER
STORIES; THIS PITFALL IS MAINLY RELEVANT TO
NEW TEAMS THAT ARE NOT FAMILIAR WITH
THE DIFFERENT ARTIFACTS OF SCRUM.
AS A RESULT, THE TEAM MEMBERS ADD
TECHNICAL TASKS AS USER STORIES, WHICH
MAY LEAD TO CONFUSION AMONG THE
STAKEHOLDERS ONCE THEY NEED TO
PRIORITIZE THE PRODUCT BACKLOG OR
DETERMINE WHICH STORIES WILL BE ADDED
TO THE NEXT ITERATION.

6. THE BUSINESS VALUE IS NOT TAKING INTO CONSIDERATION
WE SHOULD ALWAYS REMEMBER THAT THE
IMPORTANCE OF THE USER STORY IS MAINLY
BASED ON THE VALUE THAT IT ADDS TO THE
CUSTOMER IF THE USER STORY IS WRITTEN
WITHOUT THE PRODUCT OWNER REALLY
UNDERSTAND THE BUSINESS VALUE THAT THIS
STORY WILL ADD TO THE CLIENT, HOW CAN HE
MAKE A REAL AND EFFECTIVE PRIORITIZATION
PROCESS?
TO BE ABLE TO MAKE AN EFFECTIVE
PRIORITIZATION PROCESS, THE PRODUCT
OWNER MUST UNDERSTAND THE BUSINESS
VALUE OF EACH USER STORY AND WHY IT WAS
ORIGINALLY REQUESTED BY THE CUSTOMER.

7. STORIES THAT WERE WRITTEN WITHOUT COLLABORATION
COLLABORATION AMONG THE RELEVANT
STAKEHOLDERS IS THE MAIN KEY TO
SUCCEEDING AT WRITING GREAT STORIES.
BOTH THE PRODUCT OWNER AND THE
TEAM (DEVELOPERS, TESTERS ETC.) SHOULD
ALL COLLABORATE PRIOR TO WRING A USER
STORY.
BUT MAKING THIS COLLABORATION, EACH
ROLE CAN CONTRIBUTE HIS OWN
KNOWLEDGE AND EXPERIENCE THAT WILL
MOST LIKELY HELP TO CREATE IMPROVED
AND EFFICIENT STORIES.

8. STORIES THAT DO NOT PROVIDE ANSWERS
TO WRITE A GREAT USER STORY, THE CREATOR SHOULD
PROVIDE ANSWERS TO SOME BASIC QUESTIONS:
• WHAT SHOULD THE TEAM DEVELOP TO MEET THE
CUSTOMER REQUEST?
• WHAT IS THE BUSINESS VALUE OF THIS STORY?
• WHAT IS THE ACCEPTANCE CRITERIA THAT THE TEAM
MEMBERS SHOULD FOLLOW PRIOR TO STARTING THE
STORY?
• WHAT IS THE DEFINITION OF DONE THAT THE TEAM
SHOULD ACCOMPLISH PRIOR TO THEM TO MARK THE
STORY AS “DONE”?
FAILURE TO PROVIDE ANSWERS TO THOSE BASIC
QUESTIONS WILL LEAD TO CONFUSIONS THAT WILL
AFFECT BOTH THE QUALITY OF THE TEAM DELIVERABLES
AND COMMITMENTS.

9. CONTACT INFO
• EMAIL: DZCOMP@GMAIL.COM
• LINKEDIN: IL.LINKEDIN.COM/IN/DAVIDTZHMACH
• FACEBOOK: FACEBOOK.COM/DAVID.TZHMACH
• PHONEN: +972 526982298
• TWITTER: @DAVIDTZHMACH
• GOOGLE+: +DAVID
FOR ADDITIONAL KB’S PLEASE
VISIT MY BLOG
WWW.MACHTESTED.COM