Scrum Events Next: Sprint Planning As we learned in a previous section, Scrum is an empirical approach to managing work. That means that each of the Scrum events is meant to increase transparency, so that the team can reliably inspect their progress, and adapt their plans to better reach a desired outcome. In this section, we’ll…
Scrum Roles Next: Scrum Events Scrum defines three roles within the Scrum Team. The Product Owner, The Development Team, and the ScrumMaster. The Product Owner is responsible for maximizing the value of the product and the work of the Development Team. One of the primary ways the Product Owner manages this work is through the Product…
Cross Functional and Self-Organizing Teams Next: Scrum Roles Scrum Teams are self-organizing and cross-functional. These characteristics are often misunderstood, so let’s talk about what they mean in the context of Scrum. A Scrum Team is self-organizing, meaning that the team chooses how best to accomplish their work, rather than being directed by others outside the team.…
Scrum Values Next: Cross functional and self-organizaing teams For an individual, team, or organization to realize the benefits of Scrum, the structural components of the framework are an important, but incomplete, factor. The components of the framework are the visible, logical system of Scrum. Since Scrum is meant to be used by people who have complex,…
Scrum Theory Next: Scrum Values Scrum (n): A framework within which people can address complex adaptive problems, while productively and creatively delivering products of the highest possible value. This definition is from the Scrum Guide*, the official document created and regularly updated by Scrum’s co-creators, Jeff Sutherland and Ken Schwaber. In this video, we will explain…
This free online Scrum Foundations course is based on the Scrum Alliance® Scrum Foundations Learning Objectives that are aligned with the Scrum Guide. It's a 14 part video series covering Scrum theory and values, Scrum roles, Scrum events, and Scrum artifacts. Participants who are about to take a Certified Scrum Foundational class like the ScrumMaster® (CSM®)…
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…
Check out the video below of David Horowitz presenting on "7 Secrets of Highly Effective Retrospectives" at the Washington DC Scrum User Group (DCSUG). David reveals seven secrets that lead to effective retrospectives including the best way to ensure your retrospectives lead to real change, the "pledge" everyone on your team must take before participating, how…
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…
Check out the video below of Art Moore presenting on "The Agile PMO" at the Washington DC Scrum User Group (DCSUG). Art looks at Program Management Offices (PMOs) in the new (and not so new) Agile world. Art explores if they are needed, what exactly do they do, the fundamental differences with today’s PMOs and how…
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…
At AgileDC2015, I presented on Lean Discovery, Agile Delivery and a DevOps mindset. Below is the abstract of the talk, along with links to the Digital Service Delivery blog series and the presentation slides. Abstract: More and more organizations and teams are adopting Agile, however most stay focused on just the development part. They maintain a…
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…