Agile Certification Professional (PMI-ACP) Certification is the most coveted agile certification for project managers offered by the reputed PMI Institute. PMI-ACP certification is globally acknowledged and is valid across industries. Prepare for PMP exam with Simplilearn and make us a part of your success story. Simplilearn brings to you online PMI-ACP exam prep course that gives you the liberty to study at your pace and from your own place. This PMI-ACP presentation provides you a complete overview of basics of agile certification. Each slide covers PMI-ACP topics based on PMI-ACP exam syllabus and is prepared by our certified agile practitioners who have years of experience in agile environment. Get an understanding of PMI-ACP framework, agile methodologies, agile principles and its implementations in various projects. Cited examples and practice questions based on agile course and industry specific subjects provide better insights on each topic improving your confidence and knowledge towards attaining the agile certification goal.
The Speculate phase product backlog expands and refines the one developed in the Envision phase—identifying and listing the features and stories from feasibility or marketing studies, requirements-gathering efforts, and product visioning. For existing products, customers, developers, product managers, and customer support staff constantly make suggestions about product enhancements that add to the backlog. This backlog list, is maintained by the product manager and is the major inputs for release, wave, and iteration planning. Feature details evolve over the development phases. In the Envision phase the team creates a preliminary feature or product breakdown structure in which features are identified. In the Speculate phase, the team expands this list, and for each feature creates one or more "story" cards that contain basic descriptive and estimating information. During the Explore phase, in the specific iteration in which a story is planned for implementation, the requirements are determined in detail, and the story is built and tested. The results of the requirements specification process, whatever the engineering discipline involved, should be documented as a hierarchy such as product, platform, group, and component. For business software applications, these categories could be application, business area, capability, feature, and story. Small software products might use only the story level, whereas large industrial products may use the entire hierarchy. For a growing number of computer, instrumentation, and electronic products, a feature hierarchy includes both hardware and software features. Part of the design process involves determining whether low-level features will be implemented in hardware or software. Products that were once considered "hardware" products with rudimentary embedded software now have such a large set of software features that they could be considered software products with supporting hardware. In just a few years, for example, cell phones have progressed from hardware with minimal software to hundreds of thousands of lines of software code that drive (or "support," depending on whether you are a hardware or a software engineer) all aspects of the hardware. From the list of potential stories, the product team and the engineering team need to discuss prioritization and scheduling issues during the assignment of stories to iterations within the release plan. One characteristic of agile projects is the volatility of the stories on the backlog. During the planning for each iteration, the list of stories to be included in that iteration can change from the original release plan. A feature or story is defined as a piece of a product that delivers some useful and valuable functionality to a customer. Features for a software product (the ability to check a customer's credit rating) or an airplane (a comfortable seat for the passenger) are very different, but they both focus on delivering value to the customer. The basic difference in a story and a feature is that a story is a small piece that delivers useful functionality, but may not deliver a complete function. Using the customer credit check feature, for example, the complete checking "feature" may take several weeks of effort, whereas a "story" should be on the order of 2–10 days of effort for effective iteration planning. So in this case, several stories would be needed to deliver the complete feature, as illustrated in Figure 7-1. That said, capabilities, features, and stories are primarily used as a hierarchical structure to manage increasing product size. Prioritizing will help the team to set an order and timeline towards the total work.