10. Managing Backlog and Stakeholder Expectations
What should the Scrum team build next?
One of the most difficult aspects of the product manager job is determining what is the list of items that your Scrum Team needs to work next.
As a Product Manager, you will often end up dealing with multiple requests and different competing priorities throughout the day. By learning how to evaluate these different types of requests in a consistent way, using a prioritisation framework, you will be able to manage the different types of backlogs such as product and sprint and also manage stakeholder expectations effectively.
The items often come in different sizes and priority, and may be completely different from each other since the criteria used to evaluate them may vary based on the request.
For example, a request from the top sales or account manager may be getting a lot of attention from the head of sales or the head of customer success, because it is blocking the closing a large deal with a prospect. Does this mean you need to focus on developing that request right away? No, not necessarily.
Prioritizing Product and Sprint Backlog
The Scrum team that is involved in developing and testing the product typically consults the product backlog that contains the prioritised list of features for detailed information.
This quadrant helps to prioritise across different stakeholders. The 2 axis are time and who the work helps most. Typically features that support new customers should take up around 50% of the teams capacity, 20% for technical debt or bug fixing. Once an agreement of the percentage of capacity to spend on each area, then stakeholders for each quadrant need to prioritise what is their most important way to spend their percentage of the teams capacity.
Another way to look at it is the quick wins vs the hard slogs.
Technical Debt
Technical debt (code debt and design debt) is a term used to describe the incremental consequences of a technical design or development choice made for a short-term benefit. For example, writing suboptimal code to meet a deadline, knowing that the code will have to be rewritten later to make the software maintainable.
Technical debt may have one or more causes, such as:
- Time pressures
- Overly complex technical design
- Poor alignment to standards
- Lack of skill
- Suboptimal code
- Delayed refactoring
- Insufficient testing
Over time, these factors result in the accumulation of technical inefficiencies that need to be serviced in the future. Unchecked technical debt may make the software more expensive to change than to re-implement.
Technical debt can be minimised by avoiding shortcuts, using simple designs, and refactoring continuously.
When there’s technical debt, the team should make the items visible by registering entries in the product release backlog, where the matters will be evaluated and prioritised for resolution.
Can the Sprint Backlog be changed mid Sprint?
The Sprint Backlog represents the work that a Development Team needs to pull from the Product Backlog to achieve the Sprint Goal. The Sprint Goal is an objective set by the Scrum Team during Sprint Planning, and although the Sprint Goal is fixed during the Sprint, the Sprint Backlog is not fixed.
The core premise of Scrum: we can’t create detailed plans for the future. Even if that future is a single Sprint, it is entirely possible that new insights or impediments emerge as the Development Team works through the Sprint Backlog.
A team might learn that a technology they picked does not perform as expected. Or a key feature needed to reach the Sprint Goal was missed during the Sprint Planning. As issues emerge, changes to the Sprint Backlog may be warranted in order to reach the Sprint Goal. The Development Team will then re-negotiate the Sprint Backlog with the Product Owner.
A Sprint Backlog is flexible, as long as changes do not distract from the focus on the Sprint Goal.
- Conducting customer interviews, include a member of the design and development teams so they can hear from a customer directly instead of relying on the product manager’s notes. It will also give them the chance to probe deeper while the topic is fresh in the customer’s mind.
- Make developing and using customer personas a team effort. Each team member has unique perspectives and insights, and needs to understand how the personas influences product development.
- Make issue triage and backlog grooming a team sport as well. These are great opportunities to make sure everyone is on the same page, and understand why the product owner has prioritized work the way they have.
Prioritisation Framework
An effective prioritisation framework helps the Product Manager identify key factors to consider while evaluating the feature request or project. When these factors are then combined methodically to calculate a score for the project or feature request under consideration, different ideas can be compared with each other in a consistent manner.
The RICE scoring model is designed to aid Product Managers compare different items (roadmap initiatives, feature requests, new ideas) by scoring them based on four factors: reach, impact, confidence, and effort. The framework enables Product Manager to make objective decisions that are void of personal biases, and defend the rationale.
Prioritisation Frameworks enable a Product Manager to handle competing priorities and make objective decisions that are void of personal biases and give your team a prioritised backlog to focus while delivering value to customer and building a winning product.
OKR’s
Another way to prioritise over a slightly longer term (quarterly) is to develop OKR’s. The power of OKRs is that they act like a “North Star” by which you can set priorities, every quarter.
OKRs translate your company strategy into a digestible way that allows every team member to know they’re working on the right thing. There are a few best practices and pitfalls you need to watch out for if you want to get the most out of bringing OKRs into your company..
OKRs are made up of two distinct parts:
- Objectives: What you want to accomplish
- Key Results: How you’re going to measure the success of your work
This formula is the best way to describe what an OKR really is:
I will (Objective) as measured by (Key Results)
Objectives: Memorable, qualitative descriptions of what you want to accomplish in a given time-frame (quarterly). Ambitious objectives that feel somewhat uncomfortable. They should be short, inspirational, and public so everyone knows what everyone else is working on.
Key Results: A set of 2–5 metrics that measure your progress towards the Objective. They should describe an outcome, not an activity (i.e. “increase coverage to 100%”, “decrease churn x%, maintain customer acquisition cost of under £x, etc”). Key Results should be numerically based and easy to grade with a number.
The “Sweet spot” for OKR success should be somewhere between 60—70%.
Triaging Bugs
A bug is an issue that prevents the product from behaving or functioning as designed. This is different from the product behaving in a way that the users don’t expect it too. A common misconception is new functionality development trumps bug fixing. This is not the case since Product Managers evaluate the bugs on a case by case basis to determine whether the bug needs to be fixed now vs. later. The first step is confirming whether the reported issue is a bug or a mismatch in user expectations. If the reported issue is a bug, then determine whether it’s reproducible every time. Let’s take an example: Imagine using any messaging app and you are unable to include an emoji in the text. When you tap on the emoji it shows as selected but doesn’t appear in the text you typed. This issue is reproducible every time an emoji is selected regardless of whether the user tries to add it at the beginning, mid-sentence or end of the sentence.
We will spend the next few minutes understanding how does an issue’s severity determines the priority to fix the bug.
- Performance e.g Response time, latency, throughput
- Scalability e.g Scale up, Scale down
- Reliability and Disaster Recovery
- Auditability requirements driven by regulations, legal and compliance
- Accessibility
- Support to run experiments and analytics tracking
- Browser and device compatibility
- Others include Security, Internationalisation, etc Reliability, Availability, Usability, Maintainability
Non-functional requirements can be seen as “constraints” put on the system. If a product owner said, “this system must perform adequately with 250,000 concurrent users,” the product owner is putting a constraint on the development team.
The product owner is effectively saying, “Develop this software any way you’d like as long as you achieve 250,000 concurrent users.” Each constraint we put on a system narrows the engineers choices; calling these “constraints” rather than “non-functional requirements” helps us remember this. Fortunately constraints/non-functional requirements can be easily handled as user stories. Here are a couple of examples:
- As a customer, I want to be able to run your product on all versions of Chrome.
- As the CTO, I want the system to use our existing primary database rather than create a new one, so that we don’t have one more database to maintain.
- As a user, I want the site to be available 99.999 percent of the time I try to access it, so that I don’t get frustrated and find another site to use.
- As someone who speaks a Latin-based language, I might want to run your software someday.
- As a user, I want the driving directions to be the best 90 percent of the time, and reasonable 99 percent of the time.
If requirement simply said: “Must use existing primary database,” it would be possible the engineers wouldn’t remember why we should be constrained in that way. We’d ask the product owner if they care if we used a secondary database, and they say they have no objections. And we’d make a mistake of using one.Embedding the person who wants something can be very useful.
Inputs for Prioritisation
Reputation risk, while subjective, can be quantified. When internal stakeholders or customers see an issue with lower severity as a reputational risk , then the priority of the issue is “HIGH”
Frequency of occurrence of the issue increases the priority of an issue.
Isolating the impact helps you to determine if this occurs across multi-platforms and devices. This is very important and different from the frequency of occurrence. The impact of an issue is larger when the product is available across multiple devices or used across different browsers. Similarly, you want to isolate if the impact spans across different features, or affects a subgroup of user types. These factors are important to consider and determine the priority of the bugs.
Determine the priority of a bug
There are different tiers of priority:
