Are we there yet? This is a difficult question to answer when no one agrees on where exactly “there” is. In an Agile world full of cloud-based solutions, there’s no shrink-wrapped container full of widgets that truly signifies completion. And, there’s always an opportunity to ship code that is far from a “finished” product. That’s why agreeing on what we call the “Definition of Done” is of critical importance to achieving a consensus on when projects, initiatives, and features are actually complete. Show It all starts with a common vocabulary—if people aren’t speaking the same language there’s ample room for confusion, frustration, and mixed signals. To avoid this scenario, product teams should take the time to work with their engineering and testing counterparts to agree on what qualifies as “done” in different cases. To get on the same page, here’s a quick guide to deconstructing agile product management. Defining the definition of doneThe Definition of Done is an agreed-upon set of items that must be completed before a project or user story can be considered complete. It is applied consistently and serves as an official gate separating things from being “in progress” to “done.” While the particulars vary from organization to organization, a typical definition of done consists of a checklist containing items such as:
Different companies and development groups will come up with their own variant, but they all tack back to the same ideal: the code does what it’s supposed to and doesn’t break anything else. Making every feature/release/sprint go through these steps to ensure done-ness is important most of all to ensure consistent quality and completeness. There should also be an element of transparency since everything can be tied back to that done-ness checklist. If a release or feature hasn’t checked off all the boxes, then it can’t move forward and everyone knows why. Who defines done?The engineering organization is typically the lead player in defining the Definition of Done since much of it is to guarantee that things work well and meet basic technical requirements. The definition might be lead by the Scrum Master or the head of engineering. But, it should be a collaborative exercise to agree on what qualifies as “done.” Without input and approval from product, quality assurance, and other stakeholders, there won’t be widespread acceptance of whether something is actually done or engineering just says it is. “Think about all of the tasks that must be done to put the story into production. Be imaginative and include everything, even tasks that might be out of your team control,” says product development consultant Luís Gonçalves. From this ideal vision of “done” you can whittle it down to a more realistic definition. Putting it into practiceDefining done is a timesaver in the long run since it reduces unnecessary revisions later on. When the code meets the definition, everyone has assurances that it is ready for prime time. “The definition of done (DoD) is when all conditions, or acceptance criteria, that a software product must satisfy are met and ready to be accepted by a user, customer, team, or consuming system,” says Derek Huether of ALM Platforms. “We must meet the definition of done to ensure quality. It lowers rework, by preventing user stories that don’t meet the definition from being promoted to higher-level environments. It will prevent features that don’t meet the definition from being delivered to the customer or user.” Once the definition is in place, it applies to everything, ensuring consistency and quality. “These rules apply to every single work item that goes through our task boards, so long as it involves code. Whether it’s a large user story with multiple dependencies or a tiny bug fix, the person doing the work is expected to run through these checklists,” says Danny Smith of CharlieHR. “That doesn’t mean that everything on the checklists has to be ticked off for every work item, though — a tiny technical improvement is unlikely to need a marketing email written about it, for example. It does mean that everything in the checklist must be considered for every work item. We trust our engineers to use their judgment.” Why product managers should care about the definition of doneLeaving whether or not something is “done” open to interpretation can cause conflict, misunderstandings, and lead to negative user experiences and revenue impacts, which is a good reason to settle on that criteria before the Sprint ever begins. Sharing a common vision for what the end result should be is a good place for any project to start, and agreeing on the gates a feature must pass through to reach completion creates a consensus of expectations. An additional benefit of not giving every single project its own measure of being “done” is also a big-time saver and lets people focus on innovation and execution versus definition, so investing a little time in creating a baseline understanding of what done means to everyone is a worthy endeavor. With the ambiguity removed, everyone can concentrate on their core responsibilities instead of arguing later on in the process about fitness for release. Also, although a feature might appear done on the surface, if the technical team hasn’t dotted the i’s and crossed the t’s behind the scenes, those resources will be continuing to circle back to those “done” projects to clean things up and address open issues. “Incomplete work has a nasty habit of mounting up, and without visibility of how much effort truly remains, the deficit can quickly get out of hand,” says Ian Mitchell of proAgile. “The tyranny of work which is nearly done, but not really done, can put a team in servitude to technical debt.” Definition of done vs. acceptance criteriaIf you’re beginning to wonder why this is a product management issue and not a quality control topic for the technical team, that’s in part due to the difference between a general Definition of Done and the specific acceptance criteria for a particular user story. DoD is universally applied (with a few exceptions) to everything the engineering organization is attempting to ship. While a product management “OK” might be one of the items on the checklist, it’s a fairly generic definition. Acceptance criteria, however, are unique to the user story or feature in question. These criteria should be defined by product management, with input from the technical team on any specific use cases or parameters that must be met to green light this item before it’s considered done. Since DoD is considered for everything, product management should review the definition and make sure they agree that it is comprehensive enough. However, the ownership and management of the definition doesn’t necessarily need to be the responsibility of product management. As long as product is satisfied that “done” items pass the tests spelled out in the DoD, they can largely leave it be. But a shipped product or feature can hardly be considered done in the eyes of product, either. “For a product manager, you’re not done with a product (or feature) until you’ve put it out to pasture,” says Adam Sigel of Hometap. “Once it’s launched, you begin the long tail of customer support, price changes, bug fixes, and compatibility updates. Once you’re done supporting it, it’s time to sunset it. Then, and only then, are you done with a product.” Where to beginThe defining process shouldn’t happen in a vacuum, it should be collaborative between stakeholders and those actually doing the work. Whether it starts with brainstorming or a straw man suggested by the technical team, there should be ample opportunity for comment and unanimous support for the final product. Assigning owners to each criteria is also a good idea, as they can be the arbiter if there’s a disagreement amount a particular items ability to check that box. This reinforces consistency and removes any doubt from the equation. And like all well-intentioned methodologies, a Definition of Done should be as simple and short as possible. The idea is to create consistent quality and not bureaucratic hurdles that slow things down unnecessarily. “The DoD is a contract between the product owner and the team, so it’s tempting to want to fit as many items in the DoD as possible in order to ensure the quality of the product. But this can backfire,” says Yves Riel of Okapya. “When teams are confronted with too many DoD items, they either work only on a subset or try and fail to do all of them, eliminating the value of establishing the DoD in the first place.” Your mileage may varyThe Definition of Done primarily deals with code and its fitness for being released. But for the product team, you’re definitely not done when something ships, so you’ll need to create your own definition that extends much further into the product’s lifecycle. Metric-based goals such as adoption, usage, retention, or revenue could be signifiers that a feature is “done” or it could be as simple as the requesting customer agreeing that it meets their requirements. And given that user feedback and analytics may drive additional development—not to mention UX feedback or changes in business models—the engineering team should be prepared to revisit items they previously deemed “done.”
Learn for Professional Scrum Master PSM1 Certification with real questions and answers QuizThere are two quiz modes: Learning Mode – Each question has an immediate explanation. No time limit. All quiz questions are available. Pass it several times and you will be prepared well for the real assessment. Real Mode – It is very similar to the real assessment. No correct answers and explanations. There are 80 randomly selected questions and 60 minutes. Try it and get the feeling of the real assessment! If you have further Questions, email to get answers. Question: 1 How is management external to the Scrum Team involved in the Daily Scrum?A: The Scrum Master speaks on their behalf.B: The Product Owner represents their opinions.C: The Development Team self-manages and is the only management required at the Daily Scrum.D: Management gives an update at the start of each Daily Scrum.E: F: Answer:B Question: 2 A new developer is having continuing conflict with existing Development Team members and creating a hostile environment. If necessary, who is responsible for removing the team member?A: The Product Owner is responsible, because he/she controls the return on investment (ROI).B: The Development Team is responsible, and may need help from the Scrum MasterC: The hiring manager is responsible, because he/she hired the developer.D: The Scrum Master is responsible. because he/she removes Impediments.E: F: Answer:B Question: 3 What is included in the Sprint Backlog?A: User StoriesB: TasksC: Use CasesD: TasksE: Any of the abover (or others) which are a decomposition of the selected Product Backlog items.F: Answer:E Question: 4 Which Scrum Value is affected by a lack of trust in the Scrum Team?A: FocusB: RespectC: OpennessD: CourageE: CommitmentF: All of the aboveAnswer:F Question: 5 When many Development Teams are working on a single product, what best describes the definition of Done?A: It depends.B: Each Development Team defines and uses its own. The differences are discussed and reconciled during a hardening Sprint.C: All Development Teams must have a definition of Done that makes their combined work potentially releasable.D: Each Development Team uses its own but must make their definition clear to all other teams so the differences are known.E: F: Answer:C Question: 6 As the Sprint Planning meeting progresses, the Development Team sees that the workload is greater than they can handle. which two are valid actions?A: The Development Team works overtime during this Sprint.B: Cancel the Sprint.C: Recruit additional Development Team members before the work can begin.D: The Development Team sensures that the Product Owner is aware, starts the Sprint, and monitors progress.E: Remove or change selected Product Backlog items.F: Answer:D,E Question: 7 When a Development Team determines that it will not be able to finish the complete forecast, who has to be present when reviewing and adjusting the Sprint work selected?A: The Scrum Master, project manager and Development Team.B: The Development Team.C: The Product Owner and all stakeholders.D: The Product owner and the Development Team.E: F: Answer:D Question: 8 Who should know the most about the progress toward a bussiness objective or a release?A: The Scurm MasterB: The Product Owner.C: The Development Team.D: The Project ManagerE: F: Answer:B Question: 9 Which two of the following are true about the Scrum Master role?A: The Scrum Master is responsible for updating the Sprint Burndown.B: The Scrum Master teaches the Development Team to keep the Scrum Meetings to their time-box.C: The Scrum Master assigns tasks to Development Team members when they need work.D: At the Sprint Review, the Scrum Master identifies what has been done and what hast not been done.E: The Scrum Master helps those outside the team interact with the Scrum Team.F: Answer:B,E Question: 10 what is the main reason for the Scrum Master to be at the Daily Scrum?A: He or she does not have to be there; he or she only has to ensure the Development Team has a Daily Scrum.B: To write down any changes to the Sprint Backlog, including adding new items, and tracking progress on the burn-down.C: To make sure every team member answers the three questions.D: To gather status and progress information to report to management.E: F: Answer:A Question: 11 When multiple teams work together on the same product, each team should maintain a separate Product Backlog.A: TRUEB: FALSEC: D: E: F: Answer:B Question: 12 Who creates the definition of Done?A: The Scrum Master as he/she is responsible for the Development Teams productivity.B: The Scrum Team, in a collaborative effort where the result is the common denominator of all members definitions.C: The development organization ( or Development Team if none is available from the development organization).D: The Product owner as he/she is responsible for the products success.E: F: Answer:C Question: 13 what is the accountablitiy of the Product Owner during Sprint 0?A: Gathering, eliciting, and analyzing the requirements that will be inserted into the Product Backlog.B: There is no such thing as Sprint 0.C: Make sure enough Product Backlog items are refined to fill the first 3 Sprints.D: Determine the composition of the Development Teams so they have the capacity to deliver the completed forecast.E: F: Answer:B Question: 14 Which best describes the Product Backlog?A: It is baselined to follow change management processes.B: It is allowed to grow and change as more is learned about the product and its customers.C: It contains all foreseeable tasks and requirements from which the Scrum team can develop and maintain a complete project plan.D: It provides just enough information to enable a Scrum team to start the design phase of a product.E: F: Answer:B Question: 15 when might a Sprint be abnormally cancelled?A: when it becomes clear that not everything will be finishes by the end of the Sprint.B: when the Sprint Goal becomes obsolete.C: When the sales department has an important new opportunity.D: when the Development Team feels that the work is too hard.E: F: Answer:B Question: 16 Why should the Product Owner be present at the daily scrum?A: To represent the stakeholders point of viewB: He/she does not need to be thereC: To hear about impediments in functionality.D: To participate as a Scrum team member.E: F: Answer:A Question: 17 Which statement best describes the Sprint Review?A: It is a demo at the end of the Sprint for everyone in the organization to check on the work done.B: It is when the Scrum Team and stakeholders inspect the outcome of a Sprint and figure out what to do next.C: It is used to congratulate the Development Team if it did what it forecast, or to punish the Development Team if it failed to meet its forecast.D: It is a mechanism to control the development Teams activites during the Sprint.E: F: Answer:B Question: 18 When does a Development Team member become the sole owner of a Sprint Backlog item?A: At the Sprint planning meeting.B: Never. All Sprint Backlog Items are "owned" by the entire Development Team, even though each one may be implemented by an individual development team memberC: Whenever a team member can accommodate more work.D: During the Daily Scrum.E: F: Answer:B Question: 19 When many Development Teams are working on a single product, what best describes the definition of "Done?"A: Each Development Team defines and uses its own. The differences are discussed and reconciled during a hardening Sprint.B: Each Development Team uses its own but must make their definition clear to all other teams so the differences are knownC: All Development Teams must have a definition of "Done" that makes their combined work potentially releasableD: It depends.E: F: Answer:C |
When multiple Scrum teams are working on a product what best describes the definition of done?
zusammenhängende Posts
Urheberrechte © © 2024 frojeostern Inc.
