I presented on The Art of Storytelling - User Stories Smells and Anti-patterns at the Agile2016 conference held in Atlanta, GA. I'd previously presented variations of this talk at 2015 Global Scrum Gathering in Pargue, Czech Republic and the 2015 Agile Development Practices Conference in Las Vegas, NV. Below is the abstract, along with the slides…
1. Thinking that everything is a user story Many mistakenly believe that if you are Agile or using Scrum, then you must use user stories and no other format is acceptable. User stories are not required in Scrum. Product Backlog Items can take any format. User stories are a recommended technique due to some benefits over…
Looking at the user story template, which part of the user story is the most important part? Is it the Who, What, Why, How, or Acceptance Criteria? Let’s first look at the How – It’s important to note that the user story does not contain details about the How. Generally, the how are technical tasks that…
When splitting user stories, we should always split them vertically as if we are slicing a piece of cake. The whole cake is a cake and each vertical slice is a piece of cake with all it’s layers. A horizontal slice might just have the icing, or maybe just the filling, or just the crust and…
Product Backlog Items (PBIs) or user stories should be small. Small stories provide focus for the team and gives members the flexibility to adjust and adapt to changes. The larger the story, the higher the risk of team members getting lost in the details and creating bottlenecks as members are busy and unavailable to collaborate and…
Here are the top 3 reasons to split a user story: Size – Large user stories need further refinement to break them down into more manageable pieces. Key indicators that a user story is too large are if the estimate is greater than the Sprint duration, or if the estimate is greater than the remaining time…
Bill Wake came up with the INVEST acronym to help us remember guidelines for writing effective user stories: Independent, Negotiable, Valuable, Estimatable, Small, and Testable. Independent: As much as possible, try to make sure that stories are not interdependent as this might lead to prioritization and planning problems. Independent is different from logical order of developing…
Before we look at why use user stories, let’s first start by looking at other common requirement gathering techniques. 1st, there is the IEEE 830 with “The system shall… “, The system shall do this…, the system shall do that, and my favorite, the system shall be bug free 😊. We typically start out with an…
A user story is one way of representing requirements in a Product Backlog. Mike Cohn defines a user story as a simple, clear and short description of customer valued functionality. It is composed of 3 parts: a written description used for planning, conversation to flesh out the details, and tests to determine completeness. Similarly, Ron Jefferies…