What is Waterfall Development? When most of us think about traditional project management, we're picturing waterfall development. It's that step-by-step approach where you finish one phase completely before moving to the next one. Winston Royce wrote about it back in 1970, and teams have been using it ever since. But here's the thing: as markets move…
The Definition of Done often gets confused with the Acceptance Criteria. Acceptance Criteria Acceptance Criteria is specific to a user story and it will differ from one user story to the next as it’s tied to a particular functionality or feature. The acceptance criteria further clarifies the feature by proving context and intent. It helps manage…
The Scrum Guide defines Product Backlog Refinement as the act of breaking down and further defining Product Backlog items into smaller more precise items. This is an ongoing activity to add details, such as a description, order, and size. Product Backlog Refinement is a key activity in Scrum that is often overlooked. If a team finds…
Many teams struggle with breaking up or splitting a user story into smaller ones. Here are the top 13 patterns to split a user story that you can use when clarifying user stories with the team during product backlog refinement. Start by asking: 1. By Business or User Perspective Can a business stakeholder understand the user…
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? Is it the Who, What, Why, How, or Acceptance Criteria? The How 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…
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. 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…
This post summarizes the Digital Service Delivery blog series by focusing on 10 essentials for successfully using Lean Discovery practices, Agile Delivery techniques and a DevOps mindset to build solutions our customers love. Lean Discovery practices help us ensure that the solutions we are building are not only viable from a business perspective and feasible from…
To truly succeed in Lean Discovery and Agile Delivery practices and techniques, an organization must adopt an Agile and DevOps mindset. This is more than technical practices to automate our deployments. This requires a culture change aligned with Agile values and principles. This culture change is about focusing on continuously delivering high value working features on a…
In the Lean Discovery blog we saw how these practices help us narrow our focus on an MVP and ensure we are building the right thing. Agile Delivery practices help us build the thing right. Moreover, nothing beats true validated learning than having a feature released to a subset of our user base and measuring specific…