The growing demand for Scrum Masters has created an influx of new Scrum Masters into the role. And while most of those Scrum Masters have loved their new career, many…
The surge in demand for Scrum Masters has led to a wealth of available job opportunities for motivated Scrum Masters. This means that if you’re a budding Scrum Master anxious…
There’s no doubt that the Scrum Master role has been in the spotlight lately, even being named one of the top 10 most promising careers. This has garnered so much…
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.
One of the most common questions new Scrum teams face is how to handle stories that were not completed in one Sprint and must be rolled into the next Sprint….
One of the most common questions new Scrum teams face is how to handle stories that were not completed in one Sprint and must be rolled into the next Sprint. While there is no universally-agreed-upon guidance for how to handle this, here is an approach that I've found that seems to work well for most teams.
Dealing with Stories That Roll Into the Next Sprint
Whenever your team finds an incomplete story at the end of the Sprint, simply roll that story, in its entirety, into the next Sprint. When this happens, no points should be awarded to the team, for partial completion of the story.
Furthermore, I recommend that teams do not re-estimate the remaining effort of the story in the next sprint. However, I do recommend that the team take this opportunity to reevaluate their estimate for the entire story. For example, to consider whether anything has been learned during the previous Sprint that would indicate that the story is more or less complex than the team previously thought. This is also an excellent chance to consider whether the team may now see a simpler, alternative approach that wasn't obvious before.
However, if the estimate for the story does change remember that the estimate should represent the complexity of the entire story, not just the portion that remains.
Seeing This in Action
To better understand how this approach works, let's look at an example. Imagine that your team began work on a story that was estimated at 8 points in Sprint 1. However, rather than completing the story in its entirety, your team only gets 70% of the way through the story before the Sprint ends and then must roll that story into Sprint 2.
At the end of Sprint 1, your team is awarded no points for the story in question, even though your team reports that the story is 70% complete. Instead, the story is rolled into Sprint 2 with the full 8 point value. Once the remaining 30% of the story is completed in Sprint 2, the team is awarded the full 8 points for completing the story.
Understanding the Benefits of This Approach
There are several benefits to this approach. One of the most important is that failing to award teams “partial credit” for work completed reinforces to your team their goal is to deliver value, not to simply stay busy. In most cases, a story that's 70% complete doesn't deliver 70% of that story's potential value; it delivers no value. As a result, it shouldn't yield any points for the team.
Now taking this approach is likely to upset your team, but arguably that's a good thing. One reason is that taking this approach will further focus your team on value delivered, rather than the effort expended. Another reason is that this approach will encourage your team to continue to break their work into smaller stories.
Smaller stories have a multitude of benefits over larger stories, such as less complexity and therefore less risk, but they also tend to be easier for your team to understand. But despite these benefits, some teams resist the shift towards smaller stories. However, feeling the pain first hand of losing a significant amount of points in a Sprint simply because a story is almost complete is an excellent way to incentivize your team to look for seams to break their largest stories into smaller stories which can be delivered in the space of an entire Sprint.
Seeing the Bigger Picture
When following this approach don't be surprised if you hear complaints from your stakeholders that carrying over so many points from Sprint to Sprint is likely to skew your team's velocity. For example, depressing your team's velocity in the first Sprint only to artificially inflate it in the next Sprint.
However, this is an excellent opportunity to shift the conversation with your stakeholders from focusing on your team's velocity at the individual Sprint level to instead thinking of your team's velocity in aggregate across several Sprints. Not only will this shift in thinking better equip your organization to plan for the long term, but the variations in velocity from Sprint to Sprint will better average out across multiple Sprints.
Moreover, just as with your team, this is also an excellent opportunity to begin shifting your stakeholders' attention away from points closed and towards value delivered.
Seizing the Opportunity to Reevaluate Priorities
As a final note, I want to emphasize that no story should ever simply be rolled into the next Sprint without the Product Owner first taking a moment to consider whether continuing to invest in that story is even still the best use of the team's time.
A Product Owner is accountable for ensuring that the organization's investment in the team is made so in a way that will yield the most significant return for that organization. To this end, when planning the coming Sprint, the Product Owner should be considering whether each story selected is truly the highest value item on which the team should be working.
This means that even though a story might have been considered the best use of the team's time at the beginning of the last Sprint, that doesn't necessarily mean that will remain true in the next Sprint. Perhaps higher value work has emerged since the previous Sprint was planned or perhaps there has been a development in the marketplace which has deemed that story no longer necessary.
Or, perhaps the story in question is still important to the organization, but upon closer inspection, the Product Owner realizes that the work the team has done thus far is enough to add the value needed. As a result, the remaining work is simply no longer necessary or at least can be deferred.
Whatever the outcome, the Product Owner should always take the opportunity to evaluate whether continuing to invest in an in-progress story is truly the best use of the team's time or if there is now more impactful work that the team should be pursuing. In either case, the key is to avoid falling into the fallacy of sunken cost and simply continuing to pursue a story to completion simply because work on that story has already begun.
Continuously Inspecting and Adapting
Remember that every Sprint is an opportunity to inspect and adapt the work the team is pursuing. Part of that process is continuously inspecting the work that the team is currently tackling and adapting that work if it’s deemed to no longer be the best use of their time.
By regularly re-evaluating the stories the team is rolling from Sprint to Sprint and shifting the focus from “staying busy” to actually delivering value, the entire team can help to ensure that they are in a position to deliver the most value for their users as well as their organization.
Are you looking for a Scrum Master for your team? Check out my Scrum Master Assessment on Kand.io, the leading tech-talent assessment platform. This assessment will help you find the perfect Scrum Master to help your team get to the next level.
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.
Today there’s no shortage of organizations undertaking an agile transformation. However, when you ask many of those organization’s leaders why they are pursuing an agile transformation in the first place,…
Today there's no shortage of organizations undertaking an agile transformation. However, when you ask many of those organization's leaders why they are pursuing an agile transformation in the first place, more often than not their answer is “agile makes us go faster.”
But, despite the pervasiveness of this answer, it has one glaring problem:
Agile does not make you go faster.
In fact, it's not uncommon for agile teams to begin to slow down early in their agile adoption. This can be due to a multitude of reasons, such as teams learning to work together in a new and different way, teams adjusting to the world of adaptive planning, or teams placing a greater focus on quality at the point of creation, rather than holding quality concerns until the end.
But, then what does it do?
But if agile doesn't make you go faster then what's the point? The point is that agile lets you get to market sooner, which is actually much more powerful.
An agile approach encourages your team to work in smaller batches, which allows you to release those batches to market more frequently. This ability to release to market more frequently brings a host of other, much more important, benefits beyond simply letting you go faster.
One such benefit is that a more frequent release cycle enables you to respond to customer requests and feedback more often since the lead time between request and delivery is shortened significantly. This also means that you can respond to other developments much more quickly, such as unexpected developments in the marketplace or surprise moves by your competitors.
Another benefit is that you can now start to realize a return on your investment much sooner than compared to a traditional release cycle. By getting your product into market sooner, or at least a small slice of it, you now have the opportunity to begin to generate revenue from each newly released slice of product. That revenue can help to repay the cost of initially developing your product's first release as well as help to fund the development of later releases. This can be of significant benefit since creating a product that at least partially funds later iterations of its own development can significantly change the economics of that product.
The common of theme across each of these benefits is that while each can make your team appear to be moving faster, none of them will actually cause it to do so.
Discovering the right path
But shorter release cycles coupled with a decreased time to market actually bring with it another, less often cited benefit.
If your team were to simply go faster then the chances are good that they'll realize their objective sooner. However, simply going faster makes no guarantee that that objective is actually the right objective.
But increasing your number of releases also increases the number of learning opportunities for your entire organization. This means that not only do you now have more chances to discover what the right objective of your team is, but you also have the opportunity to do so further upstream. This is because each release to market is an opportunity to inspect the results of that release, both in terms of market acceptance and customer response, and then to determine how to adapt your product accordingly before the next release.
Becoming a learning organization
Intentionally creating additional learning opportunities as a result of releasing your product to market more frequently is the first step to helping your organization become a fully capable learning organization. Moreover, this change can be incredibly powerful because as the marketplace becomes both more dynamic and more competitive, only those organizations who have successfully embraced their future as a learning organization will survive.
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.
This post originally appeared on the PivotalTracker blog. Prioritizing a single set of work for your team can be hard; prioritizing work across multiple sets of work can be nearly impossible….
Prioritizing a single set of work for your team can be hard; prioritizing work across multiple sets of work can be nearly impossible.
As a product matures, product managers often find themselves contending with multiple themes of work in their product backlog. This can happen as a product begins to serve different personas, or even begins to find itself in different markets. As a result, product managers often find themselves having to shape each release to appease each type of persona.
Differentiating between themes and epics
A theme is a group of related stories that you’ve identified for your product. While at first this may sound the same as an epic, they’re actually two different concepts. While epics and themes are both comprised of sets of related stories in your product backlog, they differ in one key aspect: An epic will provide no significant business value to your product until all stories in that epic have been released; a theme, on the other hand, can be partially released and still provide some value. In fact, each story in a theme is capable of standing on its own and still providing value.
Let’s look at an example. Imagine that you’re a product manager for a product that helps companies track their users’ engagements with their website. You’ve just designed a feature for your product that tracks how many times a given user visits a website over a certain time period. This feature will help companies understand how many times a user is likely to return to the site before they become a paying a customer.
With the help of your team, you’ve created an epic comprised of four stories that represent this feature:
Tag a new visitor when they visit the website
Identify and log a returning visitor when they return to the site
Analyze each user’s engagements with the website over a given time period
Report the outcome of this analysis to product managers in an easily digestible way
Representing this feature as a series of smaller stories will make those stories easier for your team to understand and develop. However, while each story may be developed and delivered individually, these stories will provide no actual business value until the entire epic has been delivered. For example, having the ability to track a user’s visits and analyze the patterns of those visits will provide no value until the results of that analysis can be surfaced to the product’s end users in the form of a report.
Recognizing themes in your product
Compare this to a theme that may still consist of related stories, but stories that are not *so* closely related that they can’t provide value by themselves. As an example, let’s once again imagine that you’re the product manager of the product described above. While your users have been generally pleased with the value your product provides, many have complained about various performance problems with the product. For example, maybe your product’s reports can be slow to generate and even slower to respond. Or maybe the tracking code that your product provides for your users’ websites has impacted those websites’ performance. This feedback has led you to create a theme about improving performance that you’d like to tackle in future a release of your product.
With your team, you’ve created an initial cut of stories that will comprise this theme:
Improve the rendering performance of the Visitor Behavior report
Improve the filtering performance of the Visitor Behavior report
Reduce the performance impact of the tracking code on customer websites
Increase the frequency of visitor behavior aggregation from nightly to hourly
While these stories *are* related, there is a critical difference between them and the stories in our epic example: any of these stories could be released independently and still provide some value to your users. For example, while your users may prefer that you improve both the rendering and filtering performance of the Visitor Behavior report, they’ll still appreciate you improving at least the rendering performance of this report. And while reducing the performance impact of your product’s tracking code on your users’ website would no doubt be a welcome improvement, you would never consider withholding the performance improvements to the Visitors Behavior report if the tracking code performance wasn’t finished.
And herein lies the key trait of a theme: while the value of the stories that comprise a theme may increase as more stories in that theme are delivered, those stories are still perfectly capable of delivering value on their own.
Prioritizing the themes across your product
Now that you understand what themes are, let’s talk about how we can prioritize them.
The challenge of prioritizing work across multiple themes is ensuring that all themes are represented in each release. While you occasionally may want to favor a certain theme above others in the interest of creating a more coherent release, in general you’ll want a well-balanced release that appeals to all of your user personas. But how do you do this?
First start by drawing a series of concentric circles, each of which represents an upcoming release. Your nearest release should be in the center, with further releases progressing towards the outer rings of the circle. You can even consider the region outside of the largest circle as future releases that haven’t been planned yet.
Next, for each theme in your product, draw one line from the center of the chart to the outer edge of the largest circle. For example, if you’ve identified five themes in your product, then you would have five lines evenly spaced around the series of circles.
Finally, begin working through your product backlog by placing each story on the appropriate theme. In general, each story should not belong to more than one theme. If you have a story that seems to belong to more than one theme, that may be a sign that either the story is too large and should be split, or that two of your themes are closely related and may need to be combined. In addition, don’t be surprised if some of your stories don’t seem to belong to any theme. This can often be true for stories that represent a specific request from a customer and don’t really match the rest of your product. In these cases, simply place any stories that don’t match a certain theme in the space between the theme lines on the chart.
Time to plan your releases
Now that you have each of your stories assigned to themes, it’s time to begin planning your release. To do this, you can begin by spreading your stories out across your upcoming releases according to your team’s expected capacity.
You can use this chart to understand how balanced each of your releases are. For example, do you have a certain release that seems overly biased towards a certain theme at the expense of others? Or do you have certain complementary stories identified for different releases that would make a greater impact if they were delivered together?
While this exercise can be valuable, you likely won’t need to repeat it when planning every release. However, periodically plotting your releases can reveal insights into what themes are becoming dominant in each release and what steps you can take to restore balance and deliver a release that will appeal to all of your product’s users.
Want to learn more about identifying and planning for the themes in your product? Check out my course, Creating Effective User Stories from Pluralsight, for easy techniques that will have you writing better user stories today.
Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.
As someone who spends a majority of his time working with Scrum teams and Scrum Masters, one of the most common questions that I’m asked is “how many teams can…
As someone who spends a majority of his time working with Scrum teams and Scrum Masters, one of the most common questions that I'm asked is “how many teams can a Scrum Master work with?”.
However, despite how common this question is, there is no simple answer. The Scrum Guide, often our first stop in our journey for questions about the Scrum framework, is silent on this matter. And while a quick internet search will turn up plenty of opinions on the subject, those opinions are usually based on the commenter's unique experience in their specific situation rather than applicable to a wide range of situations.
The fact is that there is no universal answer to this question. The right answer for your organization is going to depend on many factors, such as the skill of your Scrum Master, whether or not that Scrum Master is focused on the Scrum Master role full-time, the maturity of the team that the Scrum Master is assigned to, and of course, the maturity of the overall organization.
However, despite the uniqueness of each situation, there are some rules of thumb that seem to apply in the majority of situations. We can use these rules as a starting point, and then adapt our approach based on what we discover about our specific environment.
Laying the Ground Rules
As a general rule, a skilled Scrum Master can work effectively with 2 to 3 teams. However, there are a few caveats with this generalization.
The first caveat is that I'm assuming that this individual is focused on the Scrum Master role full-time. This means that the individual is not splitting their attention between the Scrum Master role and another role on the Development Team, such as coding or testing. Individuals described by the latter statement can only work with one team at a time: their own.
The second caveat is that I'm assuming that the Scrum Master has a reasonable level of experience and has grown their skills while acquiring that experience. While I'm hesitant to recommend a specific amount of experience, 2 to 3 years of experience across various teams seems to give Scrum Masters the opportunity to grow the skills they need to be successful in a majority of situations. In any case, you should be wary of assigning more than one team to a first time Scrum Master.
The Dangers of the Extremes
Let's dive a bit deeper into the recommendation of 2 to 3 teams to understand better from where this idea comes. First, let's look at the extremes.
For a full-time Scrum Master who is reasonably skilled, working with only a single team is often not enough to keep that individual from becoming bored with their role.
In some cases, this will simply lead to the Scrum Master becoming disengaged and neglecting their responsibilities to the team and their organization. However, in other cases, the Scrum Master may try to invent responsibilities to fill their excess time, often creating low-value work for themselves and, by extension, their teams. The number of metrics that a Scrum Master has conceived of for their teams is often a good indicator of this situation. While some metrics can provide value to the overall planning and tuning of a Scrum team, metrics covering every square inch of available wall space are often a sign of a Scrum Master with too much time on their hands.
Now let's take a look at the other extreme. Generally speaking, when a Scrum Master is asked to work with more than 3 teams they often find themselves spread too thin to add value to any of those teams.
To be truly effective with their teams a Scrum Master must be embedded in those teams. This embedding not only gives the Scrum Master the opportunity to spot friction points or opportunities for improvement, but it also helps the Scrum Master build empathy for those teams by experiencing first-hand the trials and tribulations that the rest of the team experiences on a daily basis.
If a Scrum Master is spread between any more than 3 teams, then it's highly unlikely that they will spend enough time with those teams for those things will happen.
Finding the Sweet Spot
As a result, the sweet spot for Scrum Masters who work with multiple teams is usually between 2 and 3 teams.
Giving a Scrum Master the opportunity to work with multiple teams helps that Scrum Master grow in their craft more quickly, as they have the opportunity to deal with a wider range of challenges as well as see different perspectives on how each team implements the Scrum framework.
But there's also another, more subtle benefit. When a Scrum Master works with multiple teams, they're also more likely to shift their perspective from that of an individual team towards a more holistic view of their entire organization. As a result, the Scrum Master is better able to seek out opportunities to apply the Scrum framework in their broader organization, therefore improving the lives of more teams than simply their own.
Diving Deeper Into a 2 to 3 Team Scenario
Now that we have a better understanding of why 2 to 3 teams may be the sweet spot for a Scrum Master working with multiple teams let's unpack of the details of each of these scenarios to understand better how each may work.
More often than not, a Scrum Master working with 2 teams is the sweetest of the sweet spots. In this scenario, the Scrum Master can spend significant time with each team and truly immerse themselves into the challenges those teams are facing.
Ideally, in this scenario one of the teams will be more mature than the other, which allows the more mature team to operate with more independence giving the Scrum Master more time to focus on the team that's more likely to struggle. In addition, this also provides the Scrum Master the opportunity to consider the juxtaposition of the two teams which can inspire new lines of thought or experimentation.
Expanding on the concept of working with teams of different skill levels, in a 3 team scenario ideally one, if not two, of those teams, are already mature and relatively independent. This allows the Scrum Master to serve in more of a support role for the two maturing teams which frees them to focus on the immature team. However, as the move from 2 teams to 3 teams can be more challenging than you might originally expect, having a highly-skilled Scrum Master in the mix is even important in this scenario.
Note that in both the 2 and 3 team scenarios, the Scrum Master is intentionally electing to spend less time with their more mature teams. While at first, this might surprise you, remember that at all times a Scrum Master should be preparing their teams to operate more and more independently, therefore, lessening their dependence on their Scrum Master. Intentionally lessening their involvement with their teams, while still remaining available to provide support where necessary, is a great first step in this direction.
Finding Your Own Sweet Spot
Remember that above all, the scenarios that I've outlined above are nothing more than guidelines. Every organization is different, every team is different, and most importantly, every Scrum Master is different.
While I'm hopeful that this guidance may be of some help in your own planning for the Scrum Master role remember that, as with all things agile, the only sure path to success is through constant experimentation and learning. You'll need to experiment in your own organization to find the optimal arrangement for your teams as well as expect the most optimal arrangement to shift over time as your teams evolve.
The guidance above should be considered nothing more than a starting point. Only your teams can tell you which approach will work the best in your organization.
Are you looking for a Scrum Master for your team? Check out my Scrum Master Assessment on Kand.io, the leading tech-talent assessment platform. This assessment will help you find the perfect Scrum Master to help your team get to the next level.
