[ad_1]
Scrum is not a product management framework. But it can be tremendously valuable for product people: It can help you make the right product decisions and deliver great products if it’s correctly applied. In this article, I share ten tips to help you maximise value delivery with Scrum.
Listen to the audio version of this article:
1 Complement Scrum with a Product Discovery and Strategy Process
Scrum is a simple framework that helps teams develop successful products. It achieves this by using sprints to create product increments, collecting feedback from users and stakeholders, and adapting the product with the insights gained.[1]
As simple as this sounds, there is a catch: To create value with Scrum, you must understand who the users and customers are, why people would want to use and pay for the product, which business benefits it should generate, and, in the case of commercial products, which features differentiate it from competing offerings. Otherwise, you might ask the wrong people for feedback on the increments and hence draw the wrong conclusions. What’s more, you’ll struggle to determine the right product backlog items. How can you capture the right user stories, for instance, if you are unsure who the users are and why they want to use the product?
You should therefore do just enough product discovery and strategy work before you start using Scrum and before you add any items to the product backlog. But don’t stop there. Continue the discovery and strategy work while the product is being developed. This includes interviewing and observing users, using key performance indicators (KPIs) to track the value of the current product version, keeping an eye on the competition, and monitoring market trends.[2]
If this sounds complicated, then think about common everyday activities like riding a bicycle. Before you can set off, you first have to consider where you want to go and how you will get there—much like the initial discovery and strategy work I mentioned. To move forward, you’ll have to pay attention to the execution: push the pedals, keep your balance, and change gears. But this is not enough. To get to your destination safely, you’ll have to continuously look ahead, avoid obstacles, and possibly adjust the route.
Scrum is like a bicycle; it helps you move forward. But it doesn’t tell you where to go and how to get there—that’s what the discovery and strategy work does.
2 Use Scrum for Products that Experience Uncertainty and Change
Scrum is often seen as the standard way to create digital products, and I have met more than one company where the product managers were told to be agile and do Scrum. But like any tool, Scrum has its benefits and limitations.
I find that the framework is best suited for products that are affected by a significant amount of uncertainty and change. These are typically brand-new and young products as well as products that are experiencing a bigger change, for example, to extend their life cycle by addressing a new market segment or by replacing some of the technologies.
But if your product is in a steady state, for instance, if it is mature, and you focus on incremental enhancements and bug fixes, then you may find it more beneficial to use a Kanban-based agile process instead of Scrum.
To put it differently, there is no one right way to develop products and deliver solutions—just like there is no single bicycle that is perfect for every terrain. A road bike, for instance, is great for riding on smooth surfaces. But a mountain bike is better for riding offroad.[3]
3 Look beyond the Product Backlog and Use Additional Product Management Artefacts
The product backlog can be a great tool to capture the outstanding work to deliver a product. But it’s not enough on its own. To successfully manage your product and maximise value delivery, you should use additional artefacts including the following five:
- An inspiring vision that describes the ultimate reason for offering the product;
- A validated product strategy that captures your approach to realise the vision and make the product successful.
- An outcome-based, goal-oriented product roadmap, which shows how you intend to implement the strategy and states the specific benefits the product should create in the next, say, twelve months;
- KPIs that measure the value your product creates and help you understand if the strategy is working;
- A business model that explains how you intend to realise the desired business benefits and in the case of a commercial product, how it is monetised.
Note that none of the five artefacts is part of Scrum. But this does not mean that they cannot or should not be used in combination with the framework. As I mentioned earlier, Scrum is not a product management framework. It therefore offers only limited support for product people.
4 Take Advantage of Product Goals
I like to think of a product goal as the specific outcome that a product should achieve in the next two to three months, for example, to increase conversion, to decrease churn, or to future-proof the product by removing technical debt.[4] Using product goals offers you the following four benefits:
First, they focus and direct the product backlog. Many backlogs I have seen were too long and too detailed. But such a backlog is difficult to prioritise, refine, and update. It makes it hard to successfully deliver a product. Using a product goal addresses this issue: You only add an item to the backlog if it helps you meet the goal. Otherwise, you discard it, at least for now.
Second, product goals provide a continuity beyond the current sprint and help align everyone involved in delivering the product: Everybody should be working on the same product goal at a given point in time.
Third, product goals help you connect the product roadmap and the product backlog, assuming that you use a goal-oriented plan like my GO product roadmap. Choose the next outcome on the roadmap as your product goal and copy it into the product backlog.
Fourth, product goals help you discover the right sprint goals, which, in turn, direct the work of the development team. Simply ask yourself, “What is the next step we have to take to move forward and meet the product goal?”
5 Inspect and Adapt to Maximise Value
If applied correctly, Scrum removes most of the guesswork from delivering a product. Instead of writing down the requirements before any development has taken place and hoping that they are comprehensive and correct, you start with a sketchy product backlog, build a first increment, show it to users, customers, and stakeholders, and evaluate their feedback.
This enables you to quickly try out new ideas and learn which ones create value and which don’t. To put it differently, Scrum’s iterative nature allows you to make data-informed product decisions thereby maximising the chances of delivering a product that does a great job for the users and customers.
To successfully inspect and adapt your product, collect feedback early and often, for instance, by demoing or releasing product increments. Use the data you gather to validate your decisions and generate new ideas. Answering the following four questions with help you with this:
- Are you developing a product that is usable and beneficial for the users? Does it offer the right user experience (UX) and the right functionality?
- Can the product be successfully offered? For example, can it be effectively marketed, sold, and serviced?
- How can you further improve the product to maximise the value it creates, for example, by enhancing, adding, or removing a feature?
- What changes should you make to the product backlog? Will any of them impact the product roadmap and require an update?
Note that frequently adapting your product requires that it’s easy to modify the code. If the software is brittle and the code quality is poor, changing the product will take longer and be more expensive. It is therefore worthwhile to measure the code quality and minimise technical debt.
6 Fully Leverage the Product Backlog
I find it ironic that the only product management artefact Scrum offers is commonly misapplied. To take full advantage of the product backlog and leverage it to deliver a great product, follow these five tips.
First, use the product backlog for what it’s good at—as a tactical product plan that captures product functionality, for example, in the form of epics and user stories.
Second, use a product goal to direct the product backlog, as I recommended earlier. This will result in a concise and focused backlog that is relatively easy to manage and change.
Third, prioritise the product backlog. I like to use risk, cost-benefit, and dependencies to determine the right order, especially for a backlog that is governed by a product goal.
Fourth, regularly update the backlog by using the data you collect from users, customers, and stakeholders based on the latest product increment. Remove, add, and adjust items. Ensure that the high-priority items are ready to be delivered in the next sprint.
Fifth, involve the development team members in the backlog work. This leverages their expertise, it helps you discover technical risks, and it leads to better, clearer product backlog items.
7 Don’t Get Hung up about the Term Product Owner
As you probably know, the person in charge of the product is called product owner in Scrum. The idea behind the name choice is simple: The person who fulfils the role has to be empowered to make a product decision when no agreement can be reached. Figuratively speaking, they should “own” the product on behalf of the company.
But in my mind, it doesn’t matter if people refer to you as the product owner, product manager, or something else. What does matter is that you have the right decision-making authority, that you are committed to offering a product that benefits its users and the business, and that you show empathy and respect to the people who work with you.
8 Guide the Development Team
A development team in Scrum is more than a bunch of people writing software. It’s a cross-functional, self-managing group that incrementally delivers a usable and valuable product.[5] To help the team do a great job, follow these five tips:
First, involve the team members in the discovery/strategy work in addition to the product backlog refinement. While you might be concerned that this reduces the ability to deliver functionality, including team representatives in the discovery-related work allows them to acquire relevant knowledge about the users and to research new technologies and tools. This leads to better design and implementation decisions and a better product.
Second, use a sprint goal to describe the desired outcome of each sprint. Ensure that the team members agree with the goal and that it moves you closer to your product goal.
Third, allow the team to own the work in the sprint. Let the members freely determine what has to be done and how much work can be done. Additionally, don’t interfere with the team’s self-management. It’s the team’s responsibility to organise their work and reach the sprint goal, not yours.
Fourth, hold the team accountable for meeting the agreed sprint goal. Do not put up with a team that repeatedly over promises and under delivers. Address the issue in the next sprint retrospective and together determine the right improvement measures.
9 Align the Stakeholders
As the person in charge of the product, you usually need the stakeholders’ support to successfully deliver a product. The following four tips will help you align and guide them:
First, focus on the key stakeholders, the individuals who take an interest in your product and whose help you need to progress and provide it. For a commercial product, they are likely to include a marketer, a sales rep, and a customer service team member.
Second, engage the individuals early and regularly. The stakeholders should participate in the discovery and strategy work, and they should regularly attend the sprint review meetings. The latter allows them to see how the product is progressing, offer their feedback, and share their ideas.
Third, form a product team. Scrum is a team-based approach. While it promotes a Scrum team, this group does not include any stakeholders. I therefore recommend creating a larger team, which extends the Scrum team and includes the key stakeholders. I call this group the product team.
Fourth, don’t be afraid to say no to the stakeholders and hold them accountable for meeting agreed goals. A common mistake I see product people make is to believe that they have to please the stakeholders. But that’s wrong. Your job is to deliver a successful product and maximise the value it creates—not to make the stakeholders happy.
10 Don’t Do Scrum without an Effective Scrum Master
Having an effective Scrum Master truly is crucial when you want to use Scrum to maximise value delivery. Unfortunately, the role is often not filled. Other times, Scrum Masters are stretched too thinly, or they lack the necessary skills.
If that’s the case for you, then don’t make the mistake of taking on the role. This will make your job even more challenging and stressful. Instead, address the issue. If the role is not filled, then help the decision makers in your company understand that Scrum Masters are not optional.
If you have a Scrum Master, but you are not happy with their work, then share your perspective with them in a constructive, non-judgemental way. Offer your help, when possible and appropriate. If this does not improve the situation, then it might be best to look for another person who can play the role in a more effective way.
Bonus Tip: Practise Sustainable Pace
As the person in charge of the product, you have a demanding job with a range of diverse duties that compete for your time and attention. This makes it easy to work too hard and exhaust yourself. To stay healthy, motivated, and productive, look after yourself and practise sustainable pace. The following four recommendations will help you with this:
First, focus on your job. Don’t take on other responsibilities, at least not permanently, and only attend meetings that require your presence.
Second, delegate and share some of your work. For example, the development team might be happy to carry out some of the backlog refinement work on their own. Additionally, involve other product people and share the work if the product grows and the product management effort gets too much for one person.
Third, don’t neglect important, non-urgent tasks. It can be tempting to skip the continuous discovery and strategy work. But this usually means that you overlook opportunities and threats and therefore generate more work for yourself in the future.
Fourth, take regular breaks and don’t get into the habit of routinely working overtime. Use your lunch breaks and holiday allowance to recharge your batteries. This will enable you to deliver great products while being healthy and well.
Notes
[1] You can think of a product increment as a reusable prototype, as a step towards a new product or a new product version/release.
[2] While I’ve developed a product strategy framework and strategy tools like my product vision board that connects to an agile, Scrum-based process, I am certainly not the only person to recommend complementing agile delivery-oriented practices with discovery ones. Shout out to Ellen Gottesdiener and Gabby Benefield for their work.
[3] For simplicity purposes, I ignore the option to use Scrum to carry out discovery and strategy work using discovery sprints. As I explain in my book Strategize, I find that a Kanban-based process is better suited to manage the discovery and strategy work.
[4] Product goals are comparatively new addition to Scrum. They were first introduced in the 2020 Scrum Guide.
[5] The 2020 Scrum Guide has replaced the term development team with “developers.” But as you’ve probably noticed, I use the older, more established term in this article.
[ad_2]
Source link
