Story Pitfalls WWWW
Stories that are too big
Stories should never last longer than 1-2 manweeks.
It should be easy to see what needs to be accomplished and this requires short times.
When stories are too big, we will struggle to complete them within our sprint (in Trello, they will sit in the “in progress" column for a long time).
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.
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.
Technical tasks that were written as user stories
There is a reason that user stories containing tasks and not 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.
The community 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 community. If the user story is written without the product owner really understanding the business value that this story will add to the client/user, how can he make a real and effective prioritization process? To be able to make an effective prioritization process, the stakeholder must understand the community value of each story and why it was originally requested.
Stories that were written without collaboration
Collaboration among the relevant stakeholders is the main key to succeeding at writing great stories.
Each role can contribute his own knowledge and experience that will most likely help to create improved and efficient stories.
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/deliver to meet the community request?
- What is the community 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.