You create iterations from a backlog of user stories managed via a taskboard with a simple “workflow” from “todo” to “done.” You use Continuous Integration. But in your source control system you’ve just got files and branches. You could create a branch for every story, but that’s a lot of branches to manage! How can you ask the source control system which versions/files correspond to the stories that are done in order to build the “done” version and do exploratory testing? This session will show how to manage changes using stories and how to use branches to represent your workflow.

This tutorial teaches how to use a simple 5 component model to identify and prioritise stories on a project. The five elements to the model are: Business Objectives (value and goals) Business Actors (who does this) Business Events (when does this happen) Business Process (what needs to be done) Business Objects (what do we do it with - information and/or tools) The tutorial introduces the model as a tool for understanding current (“as is”) and future state (“to be”), identifying the stories for the future state and teaches the participants how to use it on a mock project.

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.

This talk will look at the product owner role on an Agile team from a Pragmatic product management perspective. Many software development companies rely on their product management organizations to represent the needs of customers and the market. Concentration on problems, the people who have them, and the circumstances under which they experience those problems is what makes the marriage of Pragmatic product management and Agile so valuable. This presentation will describe how the Pragmatic approach to the MRD gives the Agile product owner a headstart and the entire Agile team an edge.