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…