The Commitment Process
Trust is an important part of Agile. Product Owners need to trust that if a team commits to completing a set of Stories within Sprint that the team will deliver on that commitment. Otherwise, if the Product Owner doesn't trust the team to deliver regularly then they may feel compelled to do nasty things like ask for changes mid-Sprint or cram more Stories into the Sprint than the team can handle. But how does a team set itself up for success and earn the Product Owner's trust by ensuring that they don't commit to something that they can't deliver? In this presentation we'll review the various checks and balances built into the Agile planning process that help ensure that Stories assigned to Sprints are properly vetted with the Product Owner and understood by the team before the team commits to building them. This is an example of how a well-implemented Agile process is both rigorous and pragmatic.
Outline/structure of the Session
In this talk I'll walk through the basic flow of a Story from being added to the backlog to the Review and Demo meeting where the Product Owner provides feedback on what the team has built. Along the way I'll point out the checks and balances built into the process that teams can use to minimize the risk of not being able to deliver on a committed Story.
I've specified 40 minutes but could easily fit this talk into a 60 minute slot also.
Attendees will gain a better understand of:
- The Agile requirements management process
- How Stories are vetted and screened, and what to do when a Story doesn't pass a check point
- Sprint Planning and Delivery
This talk is generally suited to anyone.
Some knowledge of basic Agile planning processes would be helpful, but I'll cover the essentials as part of the presentation.