Blog

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. Invest 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 the logical order of…

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…