Managing Products with Agility results in products that provide valuable business outcomes, increased flexibility to respond to change, and greater transparency for investment decisions in product development. Key focus areas are Forecasting and Release Planning, Product Vision, Product Value, Product Backlog Management, Business Strategy, Stakeholders, and Customers.
Forecasting is a calculation about the future completion of an item or items that include both a date range and a probability.
In Scrum, Developers are now asked to forecast the specific work that can be done in a Sprint, rather than “commit” to it. This allows teams to focus on the things that matter in professional software development like quality, value, and continuous improvement, rather than satisfying an arbitrary obligation.
Release planning ensures that the product is moving in the right direction and it connects strategy and tactics. It visualizes high-level planning for multiple Sprints, usually between three to twelve Sprints, or so-called Product Increments. Every organization must determine the proper cadence for releasing features to its customers. A release plan represents how much scope that team intends to deliver by a given deadline. It provides answers to questions like “When will we be done?” “Which features can I get by the end of the year?” or “How much will this cost?”. To create a Release Plan the following things have to be available:
The outputs of release planning are collectively referred to as the release plan. The release plan communicates, the level of accuracy that is reasonable given where we are in the development effort when we will finish, what features we will get, and what the cost will be. This plan also communicates a clear understanding of the desired MRFs for the release. Finally, it frequently will show how some of the product backlog items map to sprints within the release.
There are three types of release planning
Available Data: Velocity, Features
Output: How long do we need to deliver these features?
Sum of user story points of the selected items for release divided by the team velocity. The result will be the number of sprints required for the final delivery of the product.
Available Data: Velocity, Delivery Date
Output: What features can we deliver by the deadline?
Multiply the team velocity by the number of Sprints we have until the release date. So the result will be the estimated total number of user story points the Scrum Team can deliver until the release date.
Available Data: Velocity, Requested Features, Delivery Date.
Output: Can the Scrum Team deliver the requested features by the given deadline?
If this number from Date Based Release Planning is larger than the sum of user story points of features within a release, then this is good otherwise the velocity of the Scrum Team needs to be extended by adding extra team members.
The minimum plan necessary to start a Scrum project consists of a vision and a Product Backlog. The vision describes why the project is being undertaken and what the desired end state is. A vision statement identifies where the organization wants or intends to be in the future or where it should be to best meet the needs of the stakeholders. It should be unambiguous, clear, realistic, harmonized with org culture and values, shorter & easier to memorize. Every Scrum project needs a product vision that sets the direction and guides the Scrum team. It is the overarching goal everyone must share – Product Owner, ScrumMaster, team, management, customers, and other stakeholders.
Google’s corporate vision is “To provide access to the world’s information in one click.”
Creating a Vision Statement is usually done by answering a few critical objectives of the project.
Answering these five questions also gives us the information to create a business case. It allows us to decide if and how the project should proceed.
Product Value is the benefit that a customer gets by using a product to satisfy her needs minus associated costs. There are two types of value, absolute value, and relative value. Absolute value quantifies how well a product meets customers’ needs whereas relative value puts the product value in the perspective of the available solution alternatives. Products typically consist of a set of features that, combined together, deliver total product value.
Product Backlog Management is the act of maximizing the value of the Product and stakeholder management. The Product Backlog is the single source of truth that contains all the work to be done on the Product. Product Backlog management is an ongoing activity that includes:
Product Backlog Refinement is the act of adding detail, estimates, and orders to items in the Product Backlog. The output of this is a prioritized list of work that emerged. A Backlog Refinement/Grooming session can be used to:
The goal is to make sure the product backlog is always DEEP:
MoSCoW Method Product Backlog Prioritization
A user story should have the following characteristics (INVEST)
A user story should have the following characteristics (SMART)
The items will be sorted based on their value, so less valuable and unclear items are at the bottom of the Product Backlog. The Product Owner may do the above work, or delegate some of his/her responsibilities to the Development Team. However, the Product Owner remains accountable.
Product Backlog Prioritization considers the below-mentioned values
Business value: For user stories that represent features, then this is relatively clear. For tasks, research spikes, re-factoring work, training, bug fixes, etc. the distinction isn’t quite so clear, but it’s equally important. Therefore, the business value needs to be carefully weighed against a wide range of work.
Time value: If you view the backlog as a representation of a project schedule, the timing of delivery truly matters. For example, if you need to perform some work on testing infrastructure, then doing it too late in the release sequence simply devalues its impact on the project; just as deferring any critical bug fixes until the final sprint is a poor strategy.
Dependency value: While we desire independence (the “I” in INVEST) as a prerequisite for good user stories, the harsh reality is that there will be strong dependencies that come into play for meaningful execution. These will need to be accommodated as you plan for delivery. A good example of this is a set or theme of stories that implement a specific customer workflow for a release. They will all need to be delivered together to realize the value. Another good example is to have multiple teams working on sets of stories that have cross-team dependencies, at the same time. Then the stories would need to be integrated to realize their full value or potential.
Technical value: If you’re collaborating effectively with your team, you realize that their opinions on technical flow are important. So, when you implement features from a development perspective considering architecture or infrastructural dependencies, ease of implementation, the natural flow of implementation, ease of testing, and team member availability; all of which fundamentally matter from an efficiency and cohesion perspective. It also helps team morale if you listen to, and consider, their expertise and overall availability.
Product Backlog Refinement benefits are
Business Strategy describes how the Product Vision will be executed in a broader context. A well-formulated strategy clearly communicates what it means for the company to win, states where the company should invest in solving problems for customers and maps how they’ll solve these problems with solutions drawn from their competitive core.
Stakeholder: a person external to the Scrum Team with a specific interest in and knowledge of a product that is required for incremental discovery. Represented by the Product Owner and actively engaged with the Scrum Team at Sprint Review. In other words, anyone who has any stake in the project or will be impacted by the product in one way or another.
A few examples of stakeholders are
Customer: An individual or the organization that acquires the project’s products and services. For any organization, depending on the project, there can be both internal customers (i.e., within the same organization) and external customers (i.e., outside of the organization).
User: An individual or the organization that directly uses the project’s products and services. Like customers, for any organization, there can be both internal and external users. Depending on the project, customers and users may be the same.
Sponsor: An individual or organization that provides resources and support for the project. The sponsor is also the stakeholder to whom everyone is accountable in the end.
A well-maintained product backlog is crucial for successful product development. It serves as a single…
Incremental value to the customer refers to the gradual delivery of small, functional parts of…
A Product Market refers to the group of potential customers who might be interested in…
The Professional Agile Leadership - Evidence-Based Management (PAL-EBM) certification offered by Scrum.org is designed for…
The Professional Agile Leadership (PAL I) certification, offered by Scrum.org, is designed to equip leaders…
Choosing the right Scrum Master Certification depends on your current experience and career goals. If…