Often when we think about an MVP, we think about a barebones version of our product that we can use to validate any hypothesis that we can dream up. But,…
Often when we think about an MVP, we think about a barebones version of our product that we can use to validate any hypothesis that we can dream up. But, despite the pervasiveness of this idea, it's backward thinking.
To understand why, let's consider the purpose of an MVP, in the first place. Remember that much more than merely testing our product, the true purpose of an MVP is to validate a hypothesis in the style of the scientific method.
But building your MVP before you choose your hypothesis is akin to designing your experiment before you consider what hypothesis you want to test. If you haven't chosen the hypothesis that you want to test, then how will you know what kind of experiment will best suit your needs?
To build great products, you must first start by deciding what hypothesis you want to prove and then designing the experiment that's purpose-built to validate that hypothesis.
Finding Your Next Hypothesis
So, where you do you find your next hypothesis? From your hypothesis backlog, of course. Your hypothesis backlog is a running list of unproven assumptions that you currently have about your product, which still need to be validated. These assumptions might include things like outstanding risks, unanswered questions, or unvalidated ideas.
Just like working from your regular product backlog, working from your hypothesis backlog is merely a matter of prioritizing by whichever hypothesis is the most important to you and then designing the MVP that best validates that specific hypothesis.
Making the Most of Your MVPs
But does this mean that you can have only one MVP per hypothesis? Not at all. While each of your MVPs should be purpose-built to test a given hypothesis, with a little upfront planning you can design an MVP that lets you simultaneously test multiple, closely related hypotheses.
The idea is not to limit each MVP to a single hypothesis, but instead to start with your hypotheses first and then design the MVP that is best suited to testing those specific hypotheses.
For example, in the image below you can see how Hypothesis1 and Hypothesis2 each map to a corresponding MVP. However, Hypothesis3 and Hypothesis4 are presumably so closely related that they can be validated using only a single MVP.
Creating a Culture of Intentional Experimentation
The key to shipping to successful products is not only to create an ongoing culture of experimentation but also to create a culture of intentional experimentation.
Teams who simply experiment wildly with little thought for how those experiments will contribute to their overall strategy rarely stumble onto the right product that makes their business successful. But, teams who take an intentional approach to experimentation and take the time to design MVPs that are best suited to validating each hypothesis are in a much better position to discover how to make their product successful and to do so much more quickly.
Are you new to the Product Owner role and are just trying to find your way? Or, are you an experienced Product Owner who has your feet wet but now you're ready to take your craft to the next level? Check out my course series, Using the Scrum Framework from Pluralsight, to learn how to set yourself apart as a Product Owner and help your team reach their highest potential.
Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.
At some point, every good Product Manager falls in love with their product. And after all, to truly realize your product’s full potential you often have to be its biggest…
At some point, every good Product Manager falls in love with their product. And after all, to truly realize your product's full potential you often have to be its biggest advocate.
But no matter how passionate you may be about your product, you must be careful not to confuse your product with your business.
Let's take a moment to understand the difference between the two.
Understanding Your Business Model
Put simply, your business, or more specifically your business model, is your means of generating the income you need to make your business successful. At a minimum, your business model describes the problem you're trying to solve, how you will solve it, and why solving it will be beneficial for your company. To understand this better, let's look at an example.
Imagine that you start a business reselling used textbooks to university students. To do this, you plan to purchase used textbooks from students at the end of each semester, store those textbooks over the semester break, and then resell those same textbooks at a 20% markup to a new group of students the following semester.
This approach is the essence of your business model.
Finding Your Product
But astute readers will notice one glaring omission from the model above: despite being a fully complete business model, there's not a single mention of a product. This is because the product that will implement this model is distinct from that model.
Let's consider what kinds of products might enable this model. One product might be a mobile app with a built-in bar code reader. A prospective seller might use that app to scan their textbook's bar code and instantly receive a buyback offer from your store. On the other hand, a prospective buyer might use this same app to scan the bar codes of books needed for their upcoming classes to check the availability and pricing of those books from your store.
But a mobile app is only one possible product that might enable this business model. Another possible product might forego the idea of a mobile app altogether in favor of a simple web app. Prospective sellers might enter their book's ISBN into this app to receive a buyback offer while prospective buyers could easily search your store's online inventory using an author's name or book title.
Each product has its own advantages and disadvantages. For example, the mobile app might be stickier for your user base leading to increased user engagement and ultimately higher sales. On the other hand, the web app might be more cost-effective to develop and maintain resulting in lower overall sales but a higher margin on those sales.
But despite their differences, what both of these products have in common is that either will fully enable the business model described earlier. So how do you know which product is the right choice for your business?
The Right Product at the Right Time
The right product for your business model will depend on many factors. For example, understanding how competitive the market is that you're moving into might influence how vital UX is to your product. Or, your business's financial constraints might impact how much capital you're able to expend on your product at the outset. Whatever factors may be in play in your business, those factors will influence which product is the right choice to bring your business model to reality.
But it's also important to realize that the right choice of product for your business is likely to change over time. For instance, a business that's light on cash may choose to initially enter a market using a product that's less compelling, but cheaper to develop. However, in the future, that same business may decide to replace that product with a more robust and feature-rich version once that business's revenue is stable enough to fund the development of that version. However, in either case, the specific product that the business developers is distinct from the actual business model that product enables.
Learning to Love Again
A hallmark of a successful Product Manager is a deep-seated love for their product. However, the product that you love today may not be the right fit for your business tomorrow.
Therefore, as a successful Product Manager, you must learn to love your product, but be careful not to fall in love with your product. Because while products may come and go, your business must be what truly lasts.
Are you new to the Product Owner role and are just trying to find your way? Or, are you an experienced Product Owner who has your feet wet but now you're ready to take your craft to the next level? Check out my course series, Using the Scrum Framework from Pluralsight, to learn how to set yourself apart as a Product Owner and help your team reach their highest potential.
Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.
This post originally appeared on the PivotalTracker blog. Ever get the feeling that your team is working on more than what’s actually in their backlog? Even with the best-laid plans, there…
Ever get the feeling that your team is working on more than what’s actually in their backlog? Even with the best-laid plans, there are still many tasks that can lie between the cracks, distracting your team from the work at hand. But even though you can’t see these tasks on your backlog, you can still feel their effects when your team struggles to accomplish the work already planned for the Sprint. In fact, because these tasks are often felt before they are seen, we refer to them as dark matter tasks.
In this post, we’ll learn how to bring these tasks out of the darkness and into the light so you can finally see which ones are holding your team back—and decide what to do about them.
Identifying the Symptoms
Although the existence of dark matter tasks may not be obvious at first, the effects of dark matter on your team are there if you know where to look.
One symptom of dark matter tasks is that your team seems to frequently refer to work that’s *not* visible on your Sprint Backlog during your daily standup. Or conversely, if your team restricts their discussion to items that are *only* on the Sprint Backlog, then you might find that they simply don’t have much to say at all.
You may also notice that much of the conversation that occurs naturally in the team room seems to focus on ideas outside of your team’s Sprint Goal. If this occurs, then this can also be a symptom that your team is occupied with other work.
Finally, another more obvious symptom is that your team regularly fails to achieve your predetermined Sprint Goal or forecasted velocity. In this case, if your team is regularly distracted by tasks that are not reflected on their Sprint Backlog, then you’ll often find yourselves without enough capacity to successfully deliver their defined Sprint Goal. However, remember that there can be many other reasons why a team might miss their stated velocity or Sprint Goal beyond dark matter tasks, so it’s important to thoroughly investigate any pattern of misses before assigning blame to a single root cause.
Bringing Those Tasks Into the Light
But once you’ve recognized that you have a problem with dark matter tasks in your team, how do you solve it?
If you’ve worked with agile methodologies before, then it should come as no surprise that the key to solving this problem is to make the work visible. And the best way to do this is by encouraging your team to add any tasks you’re working on to the Sprint board (if they aren’t already reflected there).
However, as simple as this sounds, teams are sometimes hesitant to do this. This often stems from a common myth that once a Sprint has started, it can’t be changed. But no matter how pervasive this myth is, it couldn’t be more wrong. Although we want to avoid changing the overarching goal for the Sprint after the Sprint has begun, regularly revisiting and refining the Sprint plan can actually be quite useful. Remember that the Sprint backlog is the formalization of your team’s plan to achieve their Sprint goal, if your team happens to discover a more effective way to reach that goal after the Sprint has begun, then why would we not change that plan in the interest of becoming more agile?
For this same reason, your team should not be shy about adding tasks that are distracting you from your Sprint goal, as doing so has two major benefits. First, adding a task to the backlog makes it visible, creating a more accurate picture of where your team is spending your effort, better enabling you and your stakeholders to make more informed decisions. And second, once estimated, the addition of this task forces both you and your stakeholders to recognize the impact that this new task has on your existing Sprint backlog. This can force the conversations necessary to decide whether this additional task is truly worth both the effort it will require, as well as the additional risk that your team will incur in your efforts to meet the Sprint goal.
Understanding the Impact of Dark Matter
At the completion of the Sprint, your team and stakeholders can collaborate to review any new tasks that were added to the Sprint, as well as which tasks were pushed to future Sprints as a result of those additions.
If even after adding these new items your team was still able to achieve your Sprint Goal, then your team is adapting your Sprint Backlog to meet emergent needs successfully. However, if the team missed your Sprint Goal after adding these new tasks, then your team and stakeholders need to have a frank discussion of the impact of doing so.
And remember, even though some of these tasks may seem small and inconsequential, don’t fall into the trap of assuming that they’re simply too small to add to your Sprint Backlog. Even small tasks can add up and the sum of those tasks can put your Sprint Goal at serious risk. Remember, If it costs money for your team to deliver, then it needs to be on your team’s backlog.
Encouraging Transparency with Your Team
A key tenet of all agile practices is transparency. But this transparency cannot be achieved without a clear picture of what your team is actually working on.
However, this picture can only emerge when your team’s Sprint Backlog accurately reflects the work you’re doing and how you’re spending your time. But by diligently adding these tasks to the backlog and surfacing them for all to see, we can bring these dark matter tasks into the light.
Want to learn more about how to make agile work on real teams? Check out my course, Agile in the Real World from Pluralsight, for tips and techniques to help your organization get the most out of their agile adoption.
Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.
Today, there’s no shortage of discussion about the need for Minumum Viable Products, or MVPs. However, where MVPs might fit in your own product development process is often unclear. Remember…
Today, there's no shortage of discussion about the need for Minumum Viable Products, or MVPs. However, where MVPs might fit in your own product development process is often unclear. Remember that rather than validate your product itself, an MVP validates whether the need for your product exists, in the first place.
But if an MVP only validates the need, then how do you find the best solution to solve that need?
Every individual need can be filled with many possible solutions. So it's up to you to choose the best solution for both your customers and your organization. Finding the right solution is where a Minimum Marketable Product, or MMP, comes into play. While an MVP validates a specific need, an MMP validates your solution for filling that need.
Discovering Your Solution
A great way to discover that solution is to create several lean MMPs, each of which can be validated separately. How your users respond to each MMP can help you decide which MMP may lead to the best solution to your problem, and which MMPs may not be the right fit.
However, an MMP is much more than a vehicle for merely validating how your users respond to your solution; it can also validate the viability of actually delivering that solution to the market.
For example, your MMP might validate concerns such as the best distribution channel for your product, the technology stack for building your product, or the hosting platform on which your product will reside.
However, in addition to delivery concerns, your MMP is also an excellent vehicle for validating the broader economic concerns of your product. For example, your MMP can help you project the total capital expenditure required to bring your product to market. Armed with this information you can better decide whether investing in your product is likely to yield a positive return for your organization, or if there are other opportunities out there that may yield better results.
But remember that your investment in a product doesn't stop when that product ships. A successful product is a long-term commitment, and that commitment will likely require an ongoing operational cost to remain viable in the market, such as ongoing maintenance, customer acquisition, or hosting costs. The lessons that you learn from your MMP regarding concerns such your chosen technology stack or hosting platform will better inform your projections for the operational expenses required to keep your product happy, healthy, and humming along in the market.
Seeing This in Action
To better appreciate where an MMP might fit in your product development strategy, let's look at an example.
Imagine that you're interested in creating a product to help food connoisseurs find great new ways to indulge their palettes. You've already gone through several rounds of MVPs and have discovered that a validated need exists to connect adventurous diners with new and ambitious restaurants in their area. However, identifying the problem isn't enough, now you need to find the solution.
Learning From Your Early Experiments
For the first version of your MMP, you attempt to solve this problem with a single mobile app targeted at both restaurant customers and restaurant owners. While restaurant customers loved the convenience of a mobile app, especially the ability to find new restaurants while they were already out for the evening, restaurant owners struggled with the user experience of a mobile interface. In particular, many restaurant owners found the process of updating their own listing using the small form factor of a mobile device frustrating.
Learning from this experiment, in the next version, you decide to split the experience for restaurant customers and restaurant owners across two separate products. Specifically, you decide to keep the restaurant customers on the mobile experience that they responded to so well, but move the restaurant owner's experience to a traditional website that can be accessed more easily from a computer. This larger form factor and more familiar user experience, allows restaurant owners to update their listings more efficiently, which leads to increased engagement with your platform.
Looking Beyond the Product
However, the first two versions of your MMP have only helped to discover the best platform for filling the need identified by your MVP. Whether that platform is economically viable, remains to be seen. Moreover, this is exactly what you hope to solve with the next version of your MMP.
Early user interviews ruled out the possibility of your restaurant customers paying for access to your platform since from their perspective; your platform is simply an additional form of advertising benefiting the restaurant owners.
This realization places the burden of paying for your service directly on the shoulders of your restaurant owners. However, exactly how they are willing to pay for that service remains to be seen.
In the next version of your MMP, you decide to test a pricing model based on bulk advertising rates. In this model, your customers pay a bulk advertising rate, similar to the rate that they might pay for an ad in their local newspaper, to be listed in your app. The familiarity of this model, coupled with favorable pricing, leads to strong early adoption by your restaurant owners. However, the initial findings from this MMP reveal that while this model may be popular with your restaurant owners, the revenue that it generates is simply too small to support your platform. Therefore, you're forced to eliminate this pricing model as economically unviable.
Finding a More Promising Path
The results of this experiment show you that to support your platform, you need to charge premium advertising rates. However, your restaurant owners are resistant to this as they find it challenging to actually measure the impact of their advertising dollars on their business. But rather than give up, this revelation actually leads you to the underlying hypothesis for your next MMP.
In your next MMP, rather than charging your restaurant owners an up-front fee to appear in your platform, you instead charge them a referral fee for every customer who expresses an intent to make a reservation with their restaurant after discovering it in your platform. In this model, you present restaurant customers with a button in their mobile app which allows them to click through to a restaurant's preexisting online reservations service. This click-through allows you to track referrals of restaurant customers who show an intent to book with the restaurant, which demonstrates clear value for your platform to the restaurant owners and justifies the premium advertising rates necessary to evolve your offering from just a compelling product to an economically viable and sustainable business.
Delivering a Viable Product
While your early MVPs can be very adept at identifying a need that's ready to be filled, MVPs often aren't refined enough to identify what product will best fill that need in a sustainable way.
However, by building on your early MVP experiments with a series of MMPs, you can more effectively learn which product will best meet that need, for both you and your customers, as well as determine how to deliver that product in an economically viable and sustainable way.
This is because in the competitive world of product development, simply identifying the need is never enough. To truly find success with your product, you have to identify the solution that will enable you to build a successful business for the long term.
Want to learn more about how to create great products with your teams? Check out my course, Agile in the Real World from Pluralsight, for tips and techniques to help your team deliver great products to your customers.
Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.
Today, everyone is talking about Minimum Viable Products, or MVPs. Startups are planning their first MVP to bring to market. Established organizations are deciding when the MVP of a new…
Today, everyone is talking about Minimum Viable Products, or MVPs. Startups are planning their first MVP to bring to market. Established organizations are deciding when the MVP of a new initiative will be ready to launch. And even individual teams are wondering how many sprints it will take for them to reach their MVP.
But despite the number of people talking about MVPs, the entire concept of an MVP is often misunderstood.
The biggest reason for this is that we too often think of MVPs only as products. And this should come as no surprise, after all, since the name Minimum Viable Product even has Product in the name. But, in actuality, an MVP doesn't have to be a product, at all.
Identifying an Opportunity
Often, we think of MVPs as validating whether or not a product will be successful in the marketplace, but MVPs can actually come into play much earlier than this.
Great product managers know that before you can have a successful product, you must first identify an addressable need. An addressable need is merely a gap in the market that your organization is well-equipped to fill. Often this is done in the discovery phase of our product development lifecycle, but these findings can occur throughout the lifetime of your product.
But how do you validate whether not you've identified an addressable need? Luckily there are many ways to do this. The easiest way is to sit down one-on-one with the individuals whom you believe represent your target demographic and share your vision with them. To help facilitate this, you can share wireframes or paper prototypes of the product you envision, slide decks describing the needs your product will fill, or simply bring a list of questions designed to help you better understand the problems your target demographic is facing.
None of these techniques require you to write a single line of code, because none of these techniques require a functioning product. However, in every case, the artifact that helps enable that conversation, whether it be a napkin drawing, a slide deck, or even just a list of questions can be considered an MVP.
That's because the job of an MVP is not to validate a finished product, but instead to validate your next hypothesis, in the simplest way possible.
Addressable Needs, Prototypes, and Deep-Fried Dough
To better understand where an MVP might fit in your own product development lifecycle, let's look at an example.
Imagine that you've just moved to a new town and discovered, to your horror, that there's not a single donut shop in town. But, being the enterprising individual that you are, you sense an opportunity. You could open your own donut shop and bring donuts to your own corner of the world.
But where do you start? Well, as tempted as you might be to immediately build the donut shop of your dreams and stock it with your favorite flavor: A Triple-Strawberry Frosted Donut with Cream, you take a breath. Maybe there's a reason there's no donut shop in this town already. Perhaps the townsfolk don't care for donuts, or their stomachs can't tolerate fried dough. Or, perhaps the key ingredients are simply too expensive to import to this out-of-the-way borough. Whatever the reason might be, before breaking ground on your brand new donut shop you decide first to test whether there's even a need for donuts here.
Validating the Need for Your Product
How do you do this? Well, a donut is nothing more than a mass of fried dough. So, you first need to test whether your town has an appetite for fried dough, in the first place. The easiest way to do this is to simply create a ball of fried dough and offer it to your townspeople.
This ball of fried dough is your MVP. It's not a donut and certainly bears no resemblance to the donut you envision, but it does test the essence of a donut: deep-fried dough.
In this case, your MVP for a donut shop is not a donut but rather a device that tests the need for a donut, because without first validating the need for a product there's no reason to move on to validating the actual product in any form.
This is where an MVP really shows its value since MVPs are most valuable at validating the need for a product, rather than the product itself.
Filling the Need
After a short test, you discover that your MVP was successful…almost. While your customers loved the taste of fried dough, you made an unexpected discovery. The majority of townsfolk simply can't tolerate gluten; therefore donuts as you traditionally think of them are not an option.
However, this obstacle isn't insurmountable. With only a slight tweak to your favorite recipe, you discover that you can create gluten-free donuts. The result is a ball of fried dough that's not only tasty but also accessible to your entire customer base. What's even better, is that you discovered this before creating hundreds of your favorite, gluten-rich donut.
But as much as the townsfolk love the taste of your new gluten-free fried dough on their lips, you can't build a successful business on fried dough alone. You need a real product. You need a reason for customers to come through your doors. You need a donut.
But is now the time to bring your Triple-Strawberry Frosted Donut with Cream masterpiece to the world? Not quite. As encouraging as the results of your MVP were, you've only validated that there's a need for fried dough in your town. You still need to validate whether a donut is the right product to fill that need. So, in the spirit of taking small steps to maximize your potential for learning, you introduce the most basic donut you can think of: the Plain Glazed.
This Plain Glazed donut is your Minimum Marketable Product, or MMP. The MMP is often confused with the MVP but, in practice, they're actually quite different. While the MVP most often validates that a need for your product exists, the MMP validates that your product is the right solution for that need. However, as the name implies, rather than being your top-tier offering, your MMP is the simplest product that can validate that your product might be successful.
To design your MMP, you must first consider what the essential qualities of a donut are. They are made of fried dough, they can be held in one hand, and they have that oh-so-sweet donut taste that can't be found anywhere else. Your Plain Glazed MMP checks all of these boxes, so it's an ideal candidate for filling the need identified by your MVP.
Unleashing Your Product on the World
Once again, your MMP was a hit with your customers…almost. While your customers loved the taste of the donut and the ability to eat the donut with one hand, you discovered that most of your customers indulge their craving for donuts on the way to their workplace. Therefore, they can't risk the sticky glaze getting stuck on their fingers before an important meeting. But luckily for you, there's a simple fix. By simply removing the glaze from the outside of your donut, your customers can enjoy your delicious treats anytime and anywhere without the risk of a sticky mess.
Now that your MMP has proven successful it's time to move on to your product and unleash your Triple-Strawberry Frosted Donut with Cream masterpiece on the world. This is the moment where your wildest visions for your product can become a reality. And the success of both your MVP and your MMP have paved the path to this moment.
In some cases, your end product might closely resemble the first visions for your product that you had at the outset. However, in other cases, the lessons you learned throughout the entire process are likely to have influenced and helped to evolve your end product along the way. Regardless of where your path leads, clearly understanding the differences between your MVP, MMP, and your product will help ensure that your end product is something both you and your customers will truly love.
Do you want to use this image with your own teams? Click here to download a full resolution version of the donut image above.
Want to learn more about how to make agile work with real products? Check out my course, Agile in the Real World from Pluralsight, for tips and techniques to help your organization get the most out of agile product delivery.
Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.
This post originally appeared on the PivotalTracker blog. Let’s try an experiment. Open your Sprint Backlog and take a look at the stories that are slated for your current Sprint. Do…
Let’s try an experiment. Open your Sprint Backlog and take a look at the stories that are slated for your current Sprint. Do you see a theme that ties each of them together?
Too often, the set of stories that teams select for their Sprint has no overarching theme or focus. In fact, while these stories may be individually valuable, at times their selection can appear almost random.
But high-performing agile teams begin each Sprint Planning session by defining an overarching goal that they would like to accomplish by the end of that Sprint. This shared planning helps the team select a cohesive set of stories that will help them reach that goal. However, there’s also another advantage to crafting a great Sprint goal.
A great Sprint goal helps your team understand why it’s embarking on the Sprint in the first place. This context not only better positions your team members make more informed decisions during the sprint, but it also gives them guidance in the event that they need to adjust their Sprint plan during the Sprint to react to unexpected developments.
How Are Great Sprint Goals Crafted?
Crafting great Sprint goals is easier than you may think. The best time to craft your Sprint goal is at the beginning of each Sprint Planning session. Doing this at the outset will help set the context for what the team will be tackling over the next Sprint and better equip your team to select the stories that will support that goal. While the process of crafting a sprint goal is typically led by the Product Owner, ideally the entire team should be involved in this process. This will create a shared understanding of the goal that the team is trying to accomplish and create buy-in towards that goal.
When crafting your Sprint goal, remember that the best goals are specific enough that there will be no ambiguity as to whether or not the team accomplished the goal, but also are not so specific as to constrain the team’s flexibility to adapt their Sprint plan in pursuit of deciding how to best achieve that goal.
For example, Increase the number of social login options available to the user is a great example of a Sprint goal, since it defines a clear direction but leaves the flexibility to the team to decide how to best achieve that goal.
As another example, while Improve the long-term maintainability of the reporting framework is a great Sprint goal, Reduce technical debt is not. This is because while the former gives the team a clearly defined and high-level objective to aim at, the latter is vague and tough to quantify. This can make it hard for the team to clearly decide at the end of the Sprint whether or not they actually achieved their goal.
Planning From the Top Down
So where do Sprint goals come from, you ask?
When first creating a Sprint goal, many teams are tempted to just select stories as usual during their Sprint Planning session and then simply derive a Sprint goal from any common themes they spot in those stories.
While at first, this approach may seem better, it often leads to vague Sprint goals that merely describe the lowest common denominator found in every story selected for that Sprint. As a result, it can be hard to quantify whether these goals were achieved at the completion of the Sprint or even whether completing the goal actually yielded any value to the organization and the overarching release.
The best Sprint goals are often derived from your overarching release goals. Specifically, if you’ve defined a high-level goal for your release, you can begin by decomposing that goal into roughly Sprint-sized chunks, of which each chunk will become the starting point for a Sprint goal. Don’t worry if you’re not sure how to decompose your high-level goal into Sprint-sized chunks as this is a great opportunity to involve your technical team early so they can help you understand how large each chunk of work is likely to be. Not only will this increase the likelihood that your initial chunks of work fit together well, but the early involvement of your team will also help to create a shared understanding of what the goals of the release are, as a whole.
Seeing the Bigger Picture
Crafting clear Sprint goals helps your team understand how the work they are doing in each Sprint is a part of something bigger. Helping your team see the bigger picture not only equips them to make better-informed technical decisions during the Sprint, but it also gives them valuable insight into the overall vision for their product as well as how the work they are doing today contributes to that vision.
Curious to try this for yourself? Invite your team to collaborate with you during your next Sprint Planning meeting to set a Sprint goal that moves your team closer to success. Then, after the end of that Sprint, let us know in the comments below how it went! I’d love to hear how this worked for you and your team!
Want to learn how to deliver the work that matters most to your users? Check out my course series, Using the Scrum Framework from Pluralsight, to learn how to set yourself apart as a Scrum Master or Product Owner and to help your team reach their highest potential.
Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.
Often when we talk about the responsibilities of the Scrum Master role one of the first topics that come to mind is coaching. But too many Scrum Masters believe that…
Often when we talk about the responsibilities of the Scrum Master role one of the first topics that come to mind is coaching. But too many Scrum Masters believe that their responsibility for coaching stops at the Development Team. While coaching of the Development team is important, Scrum Masters must not forget that they also have a responsibility to coach their Product Owners.
However, despite the importance of this responsibility, many Scrum Masters find themselves uncomfortable with the idea of coaching their Product Owners. One reason for this is that the responsibilities of the Product Owner role focus on Product Management, which is an area with which few Scrum Masters have any practical experience.
But there's also another, more insidious reason. In many organizations, the Product Owner is likely to hold a senior title in the organization, such as Director or Vice President. In most cases, these titles are far more senior than the Scrum Master's own title. To make matters worse, while Scrum Masters often come from technical or project management backgrounds, Product Owners may hail from strange lands such as sales or marketing. These lands are likely to be foreign to not only the Scrum Master but to the rest of the Development Team, as well.
This seniority, combined with the unfamiliarity of the role, can put the Scrum Master in an awkward position when they're asked to coach their Product Owner. However, both the Scrum Master and the Product Owner must always remember that inside the walls of the Scrum team…everyone is equal.
Helping Your Product Owner Communicate Their Vision
The good news is that there are plenty of opportunities for Scrum Masters to coach their Product Owners that are not dependent on seniority level or a deep knowledge of Product Management.
One such opportunity is helping the Product Owner understand how they can best communicate their intent to the Development Team. There are many techniques to accomplish this, such as product visioning, product roadmapping or release planning. However, one of the most powerful tools for helping your Product Owner get the details of their vision out of their head and in front of your Development Team is the product backlog.
Scrum Masters often tell their Product Owners that they are responsible for the management of their product backlog. However, those same Scrum Masters are often silent on exactly how to do this.
One area that's ripe for coaching is helping your Product Owner understand how they can better convey their intent through user stories. A Scrum Master can provide invaluable feedback on what the right level of detail is in those user stories to accurately communicate the Product Owner's intent without constricting the Development Team's implementation options. In addition, an adept Scrum Master can also provide advice as to how the right level of detail might change depending on where that item falls in the product backlog.
And speaking of backlog ordering, a Scrum Master can also help their Product Owner understand the different backlog prioritization strategies that are available to them and when it might make sense to choose one strategy over another.
Finding The Right Touch With Your Product Owner
Another common area of coaching is helping your Product Owner understand how they can make themselves more available to the Development Team and why this is important.
Striking a balance between building a strong rapport with the Development Team and micro-managing the team's every move is an act that requires finesse. This can be an excellent opportunity for a Scrum Master to add value as an astute observer who can provide feedback on the Product Owner's interactions with their team.
Being Your Product Owner's Conscience
And finally, an excellent but often-overlooked opportunity for coaching is for the Scrum Master to serve as the Product Owner's conscious. Earlier we mentioned the importance of helping the Product Owner develop a clear vision for the product that your team will deliver. However, even with a clear vision, it can still be easy to be led astray.
In the fast-paced world of product development, new opportunities arise quickly. Key customers may demand capabilities specific to their own business, sales teams may pressure teams for functionality necessary to close a large deal, and competitors may unveil more than enough new features to make any Product Owner jealous.
When these new opportunities arise, it's important for the Scrum Master to help the Product Owner stay true to their original product vision, even in the face of temptation.
One way for a Scrum Master to do this is to continually ask “The 3 W's”:
Who is this feature for?
What need will it accomplish for that person?
Why are we as an organization investing in filling that need?
But merely asking these questions isn't enough. A skilled Scrum Master must also help their Product Owner evaluate whether the answers to these questions match the stated vision for their product, and if they do not, determine whether it's time for that vision to change in response to a previously unforeseen opportunity.
Embracing Your Role As Coach
As a Scrum Master, it's your responsibility to coach your entire team, including your Product Owner.
While this coaching arrangement may at first feel uncomfortable, investing the effort to do so will help improve both the working relationship of your entire team as well as improve the chances that what your team delivers will ultimately provide value to your organization.
Do you want to learn more about how to grow your team through coaching? Check out my course series, Using the Scrum Framework from Pluralsight, to learn how to set yourself apart as a Scrum Master and help your team reach their highest potential.
Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.
This post originally appeared on the PivotalTracker blog. We’ve all had that sprint planning meeting. Your team spent the entire session arguing over which stories to include in the next sprint…
We’ve all had that sprint planning meeting. Your team spent the entire session arguing over which stories to include in the next sprint and you never even made it to sizing. By the time the session was over, you were no closer to having the next sprint planned and all that you’ve gained for your trouble is a frustrated and disheartened team.
If this sounds familiar, then it might be time to consider backlog refinement. Backlog refinement is a practice intended to help you keep the top of your backlog in a refined state so you can have better sprint planning sessions. But despite the value backlog refinement can yield, there is no officially prescribed approach for how to do it. However, if you’re looking for a simple way to introduce this practice to your team, then don’t despair: there’s an easy approach that you can use with your team today.
Blocking and Tackling Your Backlog
The *blocking and tackling* approach consists of two separate refinement meetings spaced evenly throughout each sprint. For example, if your team operates on two-week sprints, then you might hold the first session on the first Wednesday of the sprint and the second session on next Wednesday of the sprint.
Blocking
In the first session, known as *blocking*, your goal is to select the stories that you expect your team to work on in the next sprint. Your selected stories will be a function of both your planned goal for the next sprint and your team’s forecasted capacity for that sprint. If your backlog has already been prioritized so your most important stories are near the top, and these stories already have a rough estimate applied to them, then this process tends to be relatively straightforward. However, it’s still helpful to do this session with the help of your team for two reasons.
First, sharing more detail about your goal for the next sprint and which stories you believe will enable that goal helps your team better understand the bigger picture of what they are trying to create. This understanding will allow them to make decisions in the current sprint that will put them in a better position to accomplish the work selected for the next sprint.
Second, while your team will save their final estimates for the next sprint planning meeting, they can often share their impression of whether or not the work selected seems too large for the next sprint—or even too small. If it turns out that the work you selected isn’t quite the right fit, then you have the rest of the sprint to decide how to adjust your selection accordingly.
The rest of the session is saved for discussion. Introducing the stories you’ve selected to your team often leads to questions and discussions about alternative approaches…many of which you may not have considered. Surfacing these questions before the sprint planning meeting allows you to take time before the next refinement session to find the answers your team needs to confidently move forward.
Tackling
The second session, known as refinement, is where the real work happens. During this session, you will work with your team to further refine the selected stories to ensure that they’re ready for the next sprint planning meeting.
This session begins with you reviewing the selected stories for the next sprint to help refresh your team’s memory of what was selected. This is also a great opportunity to call out any changes that were made to your story selection to better fit your team’s forecasted capacity.
Next, take the time to provide any answers to questions you were unable to answer in the previous session. Not only does this help further refresh your team’s memory of their concerns regarding each story, but it also improves the chances of productive discussion later in the session.
Once you’ve answered any outstanding questions, give your team the opportunity to ask any questions that may have occurred to them since the last refinement session. Your team has now had several days to more thoroughly consider their approach to these stories; therefore, a few questions are to be expected. This is their chance to pose those questions to you before the deeper discussion begins.
Finally, the remainder of session is focused on ensuring that the selected stories are in a *ready state* for the next sprint planning session. Many high-performing teams already have a checklist in place of what they consider necessary for a story to be ready for discussion in an sprint planning meeting. The contents will vary, but at a minimum they often specify that a story must have a brief description of its objective, acceptance criteria, and a rough estimate.
If your team doesn’t have a checklist of its own yet, then the INVEST criteria is a great place to start. INVEST specifies six qualities that are often associated with well-refined stories. Try comparing each of your selected stories against the INVEST criteria to see what gaps it exposes. After several sprints of this, you’ll likely start to recognize which qualities seem to add value to your team and which qualities do not. Once this happens, feel free to adapt the INVEST criteria to your own set of criteria that makes the most sense for your team.
Getting the Results You Need
Regularly holding backlog refinement sessions will result in smoother sprint planning meetings and, ultimately, more predictable sprints. However, the approach outlined above should be considered a starting point, so don’t be afraid to adjust this practice to better fit the needs of your team.
Regardless of how you ultimately approach backlog refinement for your team, what’s important is that your team is always ready to start the next sprint and that you or your team never have to suffer through a painful sprint planning meeting again.
Are you a Product Owner who wants to help your team better understand your vision for your product. Or do you want to understand how you can work more effectively with your development team? Check out my course series Product Owner Fundamentals, part of the Using the Scrum framework learning path from Pluralsight, to learn how you can use Scrum to help your team deliver great products that your customers love.
Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.
“Can’t we just combine the Scrum Master and Product Owner roles?” If you’ve been around new Scrum teams for any period of time then you’ve likely heard this question more…
“Can’t we just combine the Scrum Master and Product Owner roles?”
If you’ve been around new Scrum teams for any period of time then you’ve likely heard this question more than once. In fact, it might even sound as if it makes sense. After all, at first glance, the roles actually appear very similar. So similar, in fact, that one might believe that there may even be efficiencies to be gained by doing so.
But, if we look closer, many of these similarities only appear because these two roles are the only roles on a Scrum team which are not developer roles. In fact, that’s where the similarities end.
Creating a balance
While the roles may at first appear similar, in actuality they have very different focuses. The Product Owner is focused on the value that the team will produce and how to select the work that will ultimately enable that value. The Scrum Master, on the other hand, is focused on how to enable the team to deliver the work that the Product Owner chooses most effectively. This means that separating these roles between two individuals helps to strike a productive balance. This balance enables the team to produce value for their organization but to do so in such a way that ensures the long term creation of that value, such as working at a sustainable pace and keeping the level of technical debt in check.
On the other hand, when these roles are combined into a single individual often that individual will gravitate towards the role they are most comfortable with while starving the responsibilities of the other role. For example, if the individual is most comfortable in a technically-oriented role then they may gravitate towards those responsibilities of the Scrum Master that support and enable the Development team while ignoring the value maximizing responsibilities of the Product Owner.
Making the most of two roles
While ensuring that the Scrum Master and Product Owner roles are properly split across two individuals is a necessary ingredient to creating a high-performing Scrum team, there’s more to making the most of these roles than simply splitting them.
Often the tension created by attempting to balance the competing priorities of these roles leads to teams viewing the roles themselves as competitors. However, this simply isn’t true. While a healthy tension should exist between a skilled Scrum Master and Product Owner, these roles should complement each other rather than compete.
But, it’s also important to remember that the Scrum Master is not simply an assistant to the Product Owner, either. While the Scrum Master may help the Product Owner fulfill certain responsibilities, if both agree that doing so would be effective, this in no way implies that the Scrum Master should be subservient to the Product Owner. All members of a Scrum Team are considered to be equal which means that regardless of their roles in the organization, in the context of the Scrum team, the Scrum Master and the Product Owner are peers.
Resisting the temptation
While the temptation may exist to combine the Scrum Master and Product Owner roles, remember that these roles were intentionally designed as separate roles. Respecting this separation of responsibilities helps to ensure that your team will benefit from the the full value that each of these roles are designed to provide, which will bring them one step closer to becoming a high-performing Scrum team.
Want to learn more about how to overcome the most common problems faced by agile teams? Check out my course, Agile in the Real World, for tips and techniques for making agile really work with your team.
Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.
We’ve all experienced this. Your team seems to be working hard. In fact, you know your team is working hard because you’re right there in the trenches with them. But,…
We’ve all experienced this. Your team seems to be working hard. In fact, you know your team is working hard because you’re right there in the trenches with them. But, no matter how hard your team works, they never seem to actually get anything finished.
If this sounds familiar, then you’re not alone. Most teams face this problem at some point in their development. However, despite how common this problem is it’s actually quite easy to overcome.
Why It Happens
To overcome this problem you first have to understand why it happens, in the first place. Most often this is due to two reasons.
First, it can happen because your team is accepting work from outside of the Sprint. This is the “can’t wait” work that wasn’t planned for during your team’s Sprint Planning, but reared it’s head after the Sprint has begun. Sometimes this happens because the Scrum Master is unable to head off a major stakeholder. Or sometimes the Scrum Master simply can't make that stakeholder understand the impact that this new work will have on the team’s outcome. Or even other times, the Scrum Master may not even be aware of the unplanned work, in the first place.
But regardless of the reason, if your team is spending time working on unplanned work instead of the work they had planned for the Sprint, then they may look busy but they’re unlikely to finish what you expect them to.
Second, it can happen because your team is working on too much work at once. This can be counter-intuitive at first, but if your team decides to tackle all of their work at once then the team will make surprisingly little progress on any of their work. This is because the team’s total effort will be spread across a much wider surface area resulting the in team making very little forward progress.
In addition, on many teams when the amount of work in progress is not closely tracked, it can be common for some individuals to begin work on one item and then move to a second item before the first item is complete. Once again, this can create an image of very busy individuals on a team, but with very little actual work in result.
Luckily, there are solutions for both of these situations that will get your team back on track and back to finishing the amount of work that you know they’re capable of.
Make It Visible
In the first case, where the team is continuing to work on items outside of the Sprint, work with your team to craft a clearly defined Sprint Goal that describes the goal that the team should accomplish with the work in the next Sprint. Once your team is in agreement about the goal, share the goal with your stakeholders so that everyone understands what your team plans to accomplish during the next Sprint and how this Sprint Goal contributes to your overall product goals. Then, when outside work begins to appear during the Sprint, you can work with your stakeholders to evaluate how that work maps to the goal the team has selected for the Sprint and what effect accepting the work may have on that goal.
If you’re still unable to prevent the work from being worked on during the Sprint, then make a special effort to estimate the newly accepted work and add it the Sprint board. You can even dedicate a reserved row of the Sprint board for this type of work, or use a different colored card so the unplanned work is immediately obvious. This visual differentiation will make visible the impact that the unplanned work is having on the work that was originally planned in pursuit of the Sprint Goal. In addition, the estimated points will allow you to better communicate to your stakeholders during the Sprint Review what percent of the team’s effort was spent on work that didn’t directly contribute to the Sprint Goal.
Both of these actions will help your stakeholders stop thinking of the Sprint as an empty bucket that work can simply be poured into, and instead begin to think of the Sprint as a strategically planned batch of work that moves the team closer to a stated goal.
Limit Your Throughput
In the second case, where the team is working on too much work at once, work with your team to establish work in progress limits, commonly known as WIP limits, on the key states of your Sprint board.
A WIP limit restricts the number of items that can be in a given state at any time. For example, in the image below, a WIP limit of 3 has been assigned to the Development column and a WIP limit of 2 has been assigned to the Testing column. This means that at any given time, no more than 3 items can be in development at one time and no more than 2 items can be in test at one time.
What happens if the WIP limit is reached? Then your team must work together to figure out how to complete the items in the column where the limit has been reached to make room for new work, thus allowing more work to flow through the process.
For example, imagine that a developer on your team completes the an item and attempts to move it to the Testing column. However, the Testing column has already reached its limit. The developer must work with your team’s testers to understand how they can help clear the existing the items from the Testing column. This may mean that the developer needs to assist the tester with their work so they can complete the items currently waiting to be tested, or that that team as a whole needs to make a greater investment into automated testing so that the testing process is more efficient overall. Regardless of the solution, the new item cannot be added to the Testing column until the existing items have been cleared.
While at first, WIP limits may seem as if they would cause a team to move slower, the opposite is actually true. WIP limits incentive your team to move work to completion, rather than to simply start it. This results in more work being completed by your team which allows them to reach their goals faster.
Focus on Finishing
Many teams look busy but surprisingly few actually complete the amount of work that may be expected of them. But, by defining clear goals for each Sprint that your team can aim for, and then incentivizing them to focus on finishing the work required to complete those goals, you can ensure that your team actually delivers the value that your stakeholders expect.
Do you want to learn more about how you can help your team deliver work more efficiently? Check out my course series, Using the Scrum Framework, to learn how you can help your team reach their highest potential and deliver a great product to market.
Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.
