In my public and private Agile and Scrum workshops (click here for a schedule of courses) participants create a parking lot of Agile and Scrum questions. I’m going to make answering those questions a regular feature of this blog. Check back each week to see what questions people are asking. This particular set of questions comes to us from attendees in Dallas, TX
Q: How is the product backlog groomed with multiple Scrum teams?
A: The same way it’s groomed with one team. There’s just more people in the room for the group grooming session.
Q: What is the difference between “Definition of Done” and “Acceptance Criteria”?
A: “Definition of Done” usually refers to product wide contraints. The things that must be true of any backlog item to consider it done (e.g. tested and fully integrated). “Acceptance Criteria” usually refers to the specific things that must be true of an individual story for it to be considered done (e.g. game mechanism must be play tested by a sample of no fewer than 3 users)
Q: Are “Definitions of Done” tasks on each story?
A: Not really, Mike Cohn describes them as “conditions of satisfaction”. I would say they represent “the finish line” (i.e. how will we know we’re done) I focus on what goal I’m trying to help my users accomplish by implementing their story. Using the board game example from class an reasonable acceptance criterion for the “chance mechanism” user story was “Player can move ahead of leading player solely due to luck (i.e. without answering a trivia question)” That criterion will probably lead to a bunch of tasks, but is not a task itself. It describes an end state of the game.
Q: What about Change Control Boards?
A: A change control board is a misguided attempt to limit scope in order to manage costs. Usually the question is “Is this really necessary and kind we afford it?” You need that only if you’re taking a plan driven approach that tries to identify the entire scope of a project up front and doesn’t consider business value/ROI on a feature by feature basis. Scrum is a value driven approach that asks different questions “Is this more valuable than something else we planned to do (but haven’t done yet) and do we have the time and money to do both?” The framework itself IS change control so a CCB becomes unnecessary.
Q: What is a PMO’s role (if any) in an Agile-based environment?
A: What is a PMO’s role in a traditional environment? A PMO defines and maintains standards, usually for project management processes. It also documents the standards, provides guidance to project managers about those standards and keeps metrics of project performance. If an organization is completely Agile a PMO is probably unnecessary because Agile processes are so lightweight they don’t need near as much documentation and knowledge of them is shared organically, usually through regular retrospectives and information radiators. Given that a PMO might become the much lighter weight Community of Practice and would likely be one of many CoPs in an organization dedicated to each discipline
Jimi Fosdick
CST