Managing Products with Agility

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.

Managing Products with Agility – Forecasting and Release Planning

Forecasting is a calculation about the future completion of an item or items that include both a date range and a probability.

A calculation leading to a date range
A probability of reaching this date range

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:

A prioritized and estimated Scrum Product Backlog
Measured velocity of the Scrum Team
Success criteria (goals for the schedule, scope, resources)

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

Feature-Based 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.

Date-Based Release Planing

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.

A mix of Feature-Based and Date-Based Release Planning

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.

Tips for Release Planning

Focus on goals, benefits, and results
Take dependencies and uncertainty into account
Release early and often!
Only release work that is ‘Done’
Get ownership over the release process
Improve the release process continuously
Create at least one releasable Increment per Sprint
Don’t release for the sake of releasing + Make releasing a business decision
Take the context and your audience into account

Managing Products with Agility – Product Vision

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.”

Format of Vision Statement

For (target customer)
Who (statement of need or opportunity)
The (product name) is a (product category)
That (what is the key benefit or reason to buy)
Unlike (competitor)
Our product (primary differentiation statement)

Creating a Vision Statement is usually done by answering a few critical objectives of the project.

Who is going to buy the product? Who is the target customer?
Which customer needs will the product address?
Which product attributes are critical to satisfying the needs selected, and therefore for the success of the product?
How does the product compare against existing products, both from competitors and the same company? What are the product’s unique selling points?
What is the target timeframe and budget to develop and launch the product?

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.

Tips for a good Vision Statement

Describe the Motivation behind the Product
Look beyond the Product
Distinguish between Vision and Product Strategy
Employ a Shared Vision
Choose an Inspiring Vision
Think Big
Keep your Vision Short and Sweet
Use the Vision to Guide your Decisions

Managing Products with Agility – Product Value

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.

Managing Products with Agility – Product Backlog Management

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:

Clearly expressing Product Backlog items.
Order the items in the Product Backlog to best achieve the goals and missions of the organization.
Optimizing the value of the work the Development Team performs in each Sprint.
Ensuring that the Product Backlog is visible, transparent, and clear to all, and shows what the Scrum Team will work on next.
Ensuring the Development Team understands items in the Product Backlog to the level needed.

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:

Write user stories (it is possible to build a Product Backlog “from scratch” in a series of one or more Story Time sessions)
Break down user stories that are too big (epics to user stories)
Improve user stories that are poorly written
Estimate backlog items
Add acceptance criteria
Look deeper into the backlog to do longer-range technical planning

The goal is to make sure the product backlog is always DEEP:

D – Detailed appropriately so that items at the top of the list have more detail than those at the bottom.
E- Estimated – Each product backlog item, or at least those involved in the next release, should be estimated by story points or time. As your team gets more work under its belt, its velocity – the rate at which it finishes items from the product backlog – will become clearer and make estimating easier.
E- Emergent – This means the product backlog is adapted to new items or information that emerge.
P- Prioritized – All items on the product backlog are ordered with the most important ones at the top.

MoSCoW Method Product Backlog Prioritization

Must (Mo) – The requirements that are critical and must be applied to a product as a matter of priority. Even if one of them is not taken into account, the release is considered to be unfulfilled.
Should (S) – Requirements important but not critical for the release. Such requirements are not very sensitive to time.
Could (Co) – Desirable but not mandatory requirements for your release. These are usually low-cost improvements for the product.
Would (W) – These are considered the least critical or may not correspond to the product strategy at all. They can be ignored and revised for future releases.

A user story should have the following characteristics (INVEST)

I – Independent – Stories should not overlap and ideally can be implemented in any order.
N – Negotiable – The story captures the essence but not the details, which are agreed upon by the participants.
V – Valuable – The story offers clear value to the customer.
E – Estimable – You are able to assess the effort involved. This might be a time estimate or in what are called story points, an arbitrary unit of measurement that rates relative complexity (such as XS, S, M, L, XL, or 1, 2, 3, 5, 8).
S – Small – “Good stories tend to be small,” Wake said. This means that the story should be accomplished in (at most) a few 40-hour work weeks by a dedicated person, or divided among team members.
T – Testable – The user story should be measurable or actionable in some way.

A user story should have the following characteristics (SMART)

Specific: Everyone will have the same understanding as to what the goals are.
Measurable: We can objectively determine if the goals have been reached.
Achievable: The stakeholders agree as to what the goals are.
Realistic: We shall be able to achieve the goals for the project with the resources we have.
Time-Based: We will be given enough time to achieve the goals.

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

Increase transparency
Clarify value
Break things into consumable pieces
Reduce dependencies
Forecasting
Incorporate learning

Managing Products with Agility – Business Strategy

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.

Managing Products with Agility – Stakeholders and Customers

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

Users or customers.
Clients.
Managers.
Organizational leaders.
Suppliers.
Sponsors.
Third parties and vendors.
Other teams

Responsibilities

The Stakeholder has to keep a healthy relationship with the Product Owner in order to share every detail regarding his project.
The Stakeholder is responsible for conveying his wishes and concerns to the product owner or else the product owner would not be responsible for his project quality and time duration.
The Stakeholder has to provide regular input to queries from the Product Owner.
Prioritizing the work effectively with the Product Owner is another job that the Stakeholder has to do to ensure his project development.
Keep taking updates or keep giving updates regarding any change in the plans.

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.