Fear of decision making often leads teams to exhibit one or more of the dysfunctional symptoms of Agile ADHD. This tutorial will help agile practitioners overcome the fear of decision making by first embracing that there are no right or wrong decisions. Agile development is ultimately driven by a series of decisions, all of which are made in the face of uncertainty. Tutorial participants will take away principles and practices that enable their team to embrace uncertainty and be proactive in making better decisions at the most responsible moment.

Over the life of a product, Product Owners maintain an ever-evolving Product Backlog. As features rise in rank, the PO breaks them down into stories, eventually sized small so the team can deliver increments of valuable functionality in an iteration. In this tutorial, we will explore examples of how to evolve a product backlog from vision to iteration acceptance. Participants will practice breaking stories down, with an emphasis on understanding the considerations that guide that process. We will provide several examples from different types of projects/products.

How do agile teams account for backlog items that do not fit the user story paradigm? Aside from user stories, what are ways you can represent product needs? Teams struggle with incorporating quality attributes (sometimes called “quality of service” requirements), external interfaces, design and implementation constraints, and team or technical “stories” into their backlogs. Without these items, you will not build the right product, or build it right. This tutorial will introduce you to ways that agile teams represent these nonfunctional requirements and other items in the backlog.

By now, your company has made the transition to Agile. “Sprints”, “backlogs”, and “retrospectives” are everyday words, but you’re also discovering the serious challenges that software agility brings to product management. The Product Owners, who have been scattered across multiple teams, are not cohesively aligned around the same prioritized set of corporate initiatives and strategies. In addition, there are cross-product dependencies that are not being effectively recognized and addressed. My company’s solution was to build a single, enterprise level, Unified Backlog.

When my Scrum-style backlog grows up, it wants to be an FDD feature list … or is it the other way round?’ Why does Feature-Driven Development (FDD) organize its feature lists into a hierarchy? Why does FDD use a specific template to name the items in a feature list? While a Scrum-style backlog for a single team may never grow to more than a couple hundred items, backlogs serving multiple teams may easily do so and become hard to work with. We compare Scrum-style backlogs and FDD-style feature lists, and consider the relative merits of different ways of working with large backlogs.