1. Strategy
2. Quality
2.1. product
2.1.1. The Product Quality is all about creating the right product— the right set of features and functionality.
2.2. technical
2.3. It is the Development Team’s responsibility to make sure that the developed product is always in good shape without technical debt and in a “Done” and releasable state.
2.4. Quality needs to be built into the product from day one; quality cannot be tested into the product at the very end.
2.5. If your only test strategy is manual, before you know it your regression tests will take up more of your Sprint than actual development. That is when you have a big problem.
3. Techniques
3.1. Story Mapping
3.1.1. Product Backlog and Story Mapping
3.2. Impact Mapping
3.2.1. Each of the team’s activities is clearly focused and aligned toward one of those clear business objectives.
3.2.2. Mapping PBIs and outcomes
4. Product Backlog Management
4.1. что может быть в Бэклоге Продукта?
4.2. Big User Stories
4.2.1. splitting
4.2.1.1. I’ve started instead to ask them about the acceptance criteria for the epic story. In no time at all, they rattle off a dozen different things that are important to the stakeholders and therefore have supplied a dozen different ways to break down the epic.
4.3. Done
4.3.1. If it takes two weeks to do regression testing, then likely you cannot complete it within a Sprint.
4.3.2. Your Scrum Team should be focusing on all the elements in the “Release” level and asking what practices they can put in place to move them up.
4.3.3. Difference between DoD and Acceptance Criterias
4.3.3.1. The definition of “Done” is for the whole Increment. Acceptance criteria are specific to a single Product Backlog item.
4.3.3.2. In other words, the definition of “Done” is the global acceptance criteria.
5. Scrum
5.1. Sprint Goal
5.2. Sprint Reiview
5.2.1. how it goes
5.3. Scaling
5.3.1. When it comes to scaling, too many organizations attempt to scale Scrum to multiple Development Teams before they are even able to get just one Development Team to reliably create a “Done” Increment each Sprint. All they really end up doing is scaling their dysfunction and reducing their overall velocity
6. Validation
6.1. MVP
6.1.1. Promotional
6.1.1.1. Visions
6.1.1.2. Mockups
6.1.1.3. Viral Campaigns
6.1.2. Mining
6.1.2.1. PoCs
6.1.2.2. Surveys
6.1.2.3. disposable when after you mine data
6.1.3. Landing Page
6.1.4. Wizard of Oz
6.1.5. Single Feature MVP
6.2. Kano-analysis
7. Value
7.1. there is only one way to deliver Value - to release
7.2. Evidence-Based Management
7.2.1. Metrics
7.3. Feedback Cards
7.3.1. In this questionnaire I ask the developers on the Development Team about their happiness in various areas. The “Product Owner” and “Scrum Master” happiness questions are set, while the other questions depend on the context. This enables me to discover trends and take action early on.
7.4. Release frequency is constrainted with your Undone (stabilization)
8. The Product Owner
8.1. Градиенты Владельцев Продукта
8.1.1. This is the reason Scrum names the role Product Owner and not System, Feature, or Component Owner.
8.1.2. Remember, the ideal Product Owner is an entrepreneur— a single voice for the vision of the product, regardless of its size. A company has just one CEO, whether it has 100 or 100,000 employees.
8.1.3. This is referred to as the Santa Claus rule. No matter how busy Santa gets, he does not bring on other Santas. How does he cope? Elves.
8.1.3.1. As Santa, you can delegate responsibility, but you still remain accountable for the success of Christmas.
8.1.4. As products scale, Product Owners should find themselves less involved with the day-to-day tactics of product development and more involved with strategy and direction.
8.2. Scaling Product Owner
8.2.1. Value Domains (Areas, Value Areas)
9. Agile Product Management
9.1. Product Mindset
9.1.1. This product mindset (see Figure 1-2) is an “outside in” approach that uses external measurements to actively guide the development of the product to maximize value.
9.2. Product Management Vacuum and 3V
9.2.1. True product management is about embodying agility throughout the whole organization from the top down to the bottom and thereby filling the Product Management Vacuum. Done right, this creates a true competitive advantage.
9.3. A product is anything that can be offered to a market that might satisfy a want or need.
9.3.1. Every product has a customer
9.3.1.1. Consumer: Anyone who gets value from your product, whether or not they pay for it
9.3.1.2. Buyer: Anyone who pays for your product, whether or not they use it
9.3.2. Every product has a producer who receives a core benefit through:
9.3.2.1. Revenue increase
9.3.2.2. Cost decrease or avoidance
9.3.2.3. Societal benefit
10. Vision
10.1. Characteristics of the good vision
10.1.1. Focused
10.1.1.1. is. If you take the time to create a business model, it will provide you with a good place to start crafting a vision. Your business model outlines all possible customers and the value propositions to them. Now you need to make some tough decisions about which ones are the most important.
10.1.2. Emotional
10.1.3. Practical
10.1.3.1. practical vs. emotional
10.1.4. Pervasive
11. Budgeting
11.1. two-phase budgeting
11.1.1. This part of the product should address anticipated features or technical risks as you want real data to drive a go/ no-go decision. The cost of this learning is relatively easy to calculate: It is the number of members of your Development Team for the length of the learning period (see Figure 8-24). Usually, just a few Sprints should allow for enough empirical data to drive an informed decision.