Jeremy Jarrell

Agile Made Simple

Tag: agile

7 min read
Uncategorized

Using an MMP to Discover the Best Solution for Your Problem

7 min read
No Comments on Using an MMP to Discover the Best Solution for Your Problem
7 min read

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.

Continue Reading
No Comments on Using an MMP to Discover the Best Solution for Your Problem
8 min read
Uncategorized

MVPs Don’t Validate the Product, They Validate the Need

8 min read
No Comments on MVPs Don’t Validate the Product, They Validate the Need
8 min read

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.

Continue Reading
No Comments on MVPs Don’t Validate the Product, They Validate the Need
4 min read
Uncategorized

Agile Does NOT Make You Go Faster

4 min read
No Comments on Agile Does NOT Make You Go Faster
4 min read

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.

Continue Reading
No Comments on Agile Does NOT Make You Go Faster
6 min read
Uncategorized

Dividing and Conquering: Finding the Right Size for Your Team

6 min read
No Comments on Dividing and Conquering: Finding the Right Size for Your Team
6 min read

This post originally appeared on the PivotalTracker blog. Your small team has been doing great. You’ve delivered significant value to your stakeholders. You’ve shown noticeable improvement in how you work together…

This post originally appeared on the PivotalTracker blog.

Your small team has been doing great. You’ve delivered significant value to your stakeholders. You’ve shown noticeable improvement in how you work together sprint after sprint. And you’ve proven to your organization that this whole “agile” thing can work. In fact, your team has done so well that your organization has decided to reward you by increasing their investment in your team.

After all, if your team has delivered this much value with only a few people, then a team three times that size should be able to deliver the same amount of value three times faster. Right?

Not so fast. While it can be tempting to increase the size of a new team after that team has shown some initial promise, simply increasing the size of an agile team isn’t always the best choice.

How big is too big?

Although it may seem surprising, simply increasing the size of an already successful team is not guaranteed to increase that team’s success—and it may even put that team’s chances of future success in jeopardy.

A team is a complex system and increasing its size increases that complexity even further. As a result, it can become more difficult for the team to continue to function in a high-performing state.

One of the most common areas where this becomes evident is in the increase of relationships and corresponding interpersonal communication pathways that are present on the team. Adding one additional team member doesn’t merely add one additional communication pathway—it adds one additional communication pathway between that team member and every other individual on the team. This increase in communication pathways can significantly increase the complexity of that team’s interactions, especially when that team is following an agile practice that emphasizes face-to-face communication.

Handling the influx of work

However, an increase in the complexity of team dynamics isn’t the only challenge faced by teams who have suddenly increased in size. Another surprising challenge is the ability to keep your new larger team busy.

If asked, most organizations will say that they have more work than they’ll ever be able to finish. In fact, this is often the impetus for increasing a team’s size in the first place. However, what many organizations take for granted is how much of that outstanding work is actually ready to be worked on.

Much of an organization’s outstanding work is vaguely defined or only partially conceived. While this can be perfectly acceptable for work far down a team’s backlog, when a team suddenly finds itself with a sharp increase in capacity, this vaguely defined work quickly makes its way to the top. When this happens, the team suddenly finds themselves tasked with work that seems to generate more questions than answers. As a result, the team cannot process this work as quickly as they expected and their new velocity fails to meet the expectations that the organization had for the larger team.

To complicate matters even further, some of this work may be dated and no longer relevant to the product’s vision or may simply be of low value to the product’s stakeholders. Often a product manager will justify investing in this low-value work as a way of keeping a team busy while higher value work is found. However, this assumption ignores the ongoing maintenance costs the team will incur to support this new work as well as any potential increases in technical debt that were necessary to deliver that work. When the total costs to create and support this low-value work are considered over the long term, we often find that it’s more cost effective to simply keep the team idle until truly high-value work can be identified.

Keeping small teams effective

So, with the all of the challenges that can face larger teams, you may be wondering if simply creating additional smaller teams might be the right choice for your organization. In fact, many organizations find that this can be a very successful approach. Luckily, there are a few specific steps you can take to keep your small teams effective.

The first step is to keep your small teams…well, small. But how small? The Scrum Guide recommends that development teams stay between three and nine individuals. But even the upper end of that range that may be a bit too large for some tastes. Those of us who shudder at the thought of a nine-person team will be happy to know that studies from such management thought leaders as the Harvard Business School or the Wharton School of the University of Pennsylvania have placed the ideal size of a knowledge worker team at five. This means that if you are looking for the ideal size for your teams, around five members per team would be a great place to start.

But size isn’t the only consideration for building an effective team. You must also consider the mix of skills that will be present on that team. Successful small teams are structured in such a way that they are cross-functional and have the right mix of skills necessary to deliver an increment of product with minimal dependencies on other teams. For example, if your team’s delivery flow includes designing a compelling UX for your product, writing the code to realize that UX, and then validating that the entire experience works as expected, then your team should have UX designers, engineers, and testers all committed as part of the team. This will allow the entire increment to be created and delivered without the need of enlisting the help of external teams. This not only increases the team’s sense of ownership over the work they are delivering, but it also allows each individual team to operate more independently within the organization.

Putting this to work for your team

Finding the right size for your team can be a daunting task. Many factors can come into play, including the amount of work that’s defined and ready for your team to tackle, the mix of skills available on your team, and the steps your team must take to ship your product. But by keeping each of these challenges in mind while you structure your teams, and erring on the side of smaller teams, you’ll be sure to find the perfect size for your team.

Are you ready to learn the skills that will transcend any agile methodology your team chooses? Check out the course series ICAgile Certified Professional – Agile Fundamentals from Pluralsight to learn the underlying theories and values that will help you create real and sustainable change in your organization, regardless of the agile approach used by your team. This series discusses common traits of agile teams, self-organization, and, of course, how to discover the perfect size for your team.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

Continue Reading
No Comments on Dividing and Conquering: Finding the Right Size for Your Team
4 min read
Uncategorized

Taking an Active Approach to Transparency in an Agile Team

4 min read
No Comments on Taking an Active Approach to Transparency in an Agile Team
4 min read

One of the driving philosophies of an agile approach is the idea of transparency. Agile teams strive to create transparency both with their stakeholders and within their teams. However, achieving…

One of the driving philosophies of an agile approach is the idea of transparency. Agile teams strive to create transparency both with their stakeholders and within their teams. However, achieving the level of transparency necessary for an agile team to be successful is often more difficult than many teams believe.

Often times, a team will decorate their team space with burndown charts, burn up charts, and the like that convey the progress they are making to their stakeholders every day. And if that same team begins to fall behind then they’ll faithfully update those charts accordingly to ensure they accurately reflect their progress. Unfortunately though, simply updating their charts often is not enough.

However, the shortfalls of this approach are often not evident until the next Sprint Review when the team is frustrated that their stakeholders appear blindsided that the team’s progress was not what they expected. Of course we didn’t hit our velocity, they yell, it was right there on the burndown chart all along!

Taking Responsibility for Transparency

As an agile team, you have a responsibility to act in a transparent way, but doing so means more than simply hanging a few charts in view of your stakeholders and calling it a day.

In order to achieve true transparency with your stakeholders you must work to actively foster that transparency with everyone involved. This means regularly engaging your stakeholders in conversation, showing them the locations where you’re currently surfacing information, and teaching them to how to decipher and glean the information they need from each location.

For example, if your team begins to fall behind their forecasted velocity for the Sprint simply posting a burndown chart on the wall and assuming that your stakeholders have been informed isn’t a successful strategy. Instead, seek out your key stakeholders and call their attention to your burndown chart, ensuring that they understand what it conveys and what it means for your project. You can then use this opportunity for a deeper conversation of how your team and stakeholders can work together to still achieve your overarching goal for the Sprint, such as by removing some stories from the Sprint plan that don’t contribute to that goal or by reducing the scope of the remaining stories.

As another example, allowing your Sprint Reviews to devolve into a passive demo where your team simply demonstrates the work they’ve completed to a panel of disinterested and disengaged stakeholders is unlikely to garner the feedback you need to move your team forward. Instead, make an effort to ensure that the right stakeholders are in the room to decide whether your team is truly on the right track, and then work to force a productive conversation to identify what needs to change in the next Sprint in the event that they aren’t.

Achieving True Transparency

While simply working in a transparent manner in your day-to-day activities will garner a passive level of transparency, to truly achieve the benefits of agility you must actively promote transparency through every facet of your team’s process.

This includes actively engaging your stakeholders in your team’s delivery process, teaching them how to get the information they need from your team’s information radiators, and bringing them into fold so that everyone is equally vested in a successful outcome for your project. In fact, teaching your stakeholders to accurately decipher your team’s information radiators may even result in those stakeholders spotting patterns and or insights that your own team may have missed, deepening the value that those relationships bring to your team.

If you want to truly create a level of transparency between your team and stakeholders then simply hanging a burndown chart on the wall often isn’t enough. To achieve true transparency, you need to engage your stakeholders every step of the way and ensure that they are actively aware and engaged throughout your project.

Are you ready to learn the skills that will transcend any agile methodology your team chooses? Check out the new course series ICAgile Certified Professional – Agile Fundamentals from Pluralsight to learn the underlying theories and values that will help you create real and sustainable change in your organization, regardless of the agile approach used by your team.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

Continue Reading
No Comments on Taking an Active Approach to Transparency in an Agile Team
5 min read
Uncategorized

Writing Great User Stories For Developing APIs

5 min read
No Comments on Writing Great User Stories For Developing APIs
5 min read

I recently received a great question from a viewer of my Creating Effective User Stories course. The viewer asked how she should approach writing user stories for team who would…

I recently received a great question from a viewer of my Creating Effective User Stories course. The viewer asked how she should approach writing user stories for team who would be creating APIs. For example, should the user story be written from the point of view of the API, such as “As an API, I want to…”, or should the persona portion of the user story be dropped entirely, focusing instead on only the intent and the justification.

As more and more teams find themselves tasked with creating APIs this is becoming a very common question. But luckily, there’s an approach to writing these types of user stories that can still help the team understand the intent of these stories without sacrificing their essence.

APIs Aren’t People

Most of know that creating an API persona for these types of stories simply doesn’t feel like the right answer. But explaining exactly why this isn’t the right answer can be harder to put your finger on.

To better understand why this feels wrong we have to remember some of the goals of user stories. First and foremost user stories are intended to improve collaboration with your team. However, they also have additional benefits, as well.

One of these additional benefits is to help you understand how the features you are designing will benefit the intended users of your product. Note the keyword there: users. This is critical, since without first understanding the users of your product, you can’t hope to design the features that will yield the most benefit to those users.

Another additional benefit is that well-crafted user stories help you understand the ultimate value that each story will be creating. This can help you can better understand if that value is worth the investment required to bring that story to market as well as when would be the optimal time to make that investment.

Note that neither of these benefits are possible if you don't have a properly-crafted and realistic persona already attached to each story. The lack of a realistic persona not only impedes your ability to make the necessary prioritization decisions as a product owner, but it also deprives your team of the context they'll need to make better informed technical decisions along the way.

Defining A Realistic Persona

So if creating a persona named API isn't the right choice for these types of stories then what is? The best choice is to identify the persona who will ultimately benefit from the value that the story will deliver and then attach the user story to that persona.

For example, imagine that you are creating an API that allows for conversions between different currency units. As part of this story you would like to convert between the Euro and the US Dollar. You could write the story as follows:

“As an API,
I want to convert between the Euro and the US Dollar”.

While this user story does convey the action that you wish to accomplish it lacks critical context. Who needs to do perform this action…the API? That's not very helpful. And what about the why?

While this story does tell the team what you want achieve, it lacks the necessary context to help the team make better decisions in development as well as to help you decide where this story fits in your overall product strategy.

Understanding Who Stands To Benefit

Imagine that you discover that your API will be used by a commodities trading house. And furthermore, imagine that you have a persona called “Commodities Trader” who represents someone who trades global commodities. Let's revisit the story in this new light.

“As a Commodities Trader,
I want to convert between the Euro and the US Dollar,
so that I can better understand how the price of my target commodity will be affected by currency fluctuations.”

This version of the story gives us much more context to work with. For example, understanding that this conversion will be used for comparing currency valuations helps our team better understand what level of precision will be needed in their conversions. And understanding that this conversion is intended to be used for commodities trading gives you much more context as a product owner to understand where this story might fit in your overall product strategy.

For example, if the trading volume between the European Union and the United States is relatively low today then this story can probably be delayed in exchange for higher priority work. On the other hand, if this trading volume is currently high then your product would likely benefit from tackling this story sooner rather than later. And finally, since we now know who will be using the feature and why they will be using it, we now have more information to find other stories in our backlog that might complement this story and therefore should be delivered alongside of it.

Putting This To Work In Your APIs

Features should exist only to yield value to your product’s users and ultimately your stakeholders. And user stories should exist to give your delivery team the context they need to make better informed decisions along the way. But without a well-crafted persona attached to each user story, you risk investing your team’s effort only to deliver stories that completely miss the mark for both your users and your stakeholders.

Want to find the perfect next hire for your team? Check out my Agile Developer Assessment on Kand.io, the leading tech-talent assessment platform. This assessment will help you find the perfect fit for your growing agile team.

Continue Reading
No Comments on Writing Great User Stories For Developing APIs
8 min read
Uncategorized

How To INVEST In Your User Stories

8 min read
No Comments on How To INVEST In Your User Stories
8 min read

This post originally appeared on the PivotalTracker blog. If you’re a product manager, user stories are a critical part of how you interact with your team. Nothing trumps a face-to-face conversation,…

This post originally appeared on the PivotalTracker blog.

If you’re a product manager, user stories are a critical part of how you interact with your team. Nothing trumps a face-to-face conversation, but the key to starting that conversation is a good story.

For example, imagine that your team is building an e-commerce site that enables college students to sell their books to other college students at the end of the semester. Rather than selling to an intermediary, such as a university bookstore, this site would let college students to sell their unused textbooks directly to their peers, thus allowing them to keep more of their profits. As a product manager, you might start the conversation with your team with this story:

As a college student

I would like to sell my old textbooks

so I can make money.

On the surface, this story seems to have all of the basic building blocks of a great user story. It clearly specifies a target persona that will benefit from the new capability described by the story, specifies what that new capability should be, and even describes what value the persona will receive from that capability.

But is this story enough to start the conversation with your team? What if there were a simple test that could tell you?

Meet INVEST

Luckily, there is a practice that can help, and it’s called INVEST. INVEST represents a specific set of qualities that mature stories tend to exhibit. Although not every quality will apply to every story, the more qualities that your story exhibits, the more likely it is to be ready for consumption.

So what are these qualities? INVEST represents these six qualities that are often considered desirable in a user story:

    • Independent: The story can be delivered independently of other stories. Note that this doesn’t mean that stories can’t have prerequisites, only that the stories may not be so coupled that they must be delivered in parallel.

 

    • Negotiable: While we prefer stories written in a clear and unambiguous language, stories should not be written to such a level of detail that they become overly restrictive and prevent your team from arriving at the best solution themselves.

 

    • Valuable: Every story that’s delivered should make your product more valuable—period.

 

    • Estimable: Every story should provide enough information to equip your team to make a reasonable estimate of that story’s complexity. This is because whether or not we can estimate a story’s complexity is often a great indicator of how well we actually understand that story.

 

    • Small: Smaller stories are easier for your team to understand and therefore are simpler to deliver. Plus, the smaller a story is, the less risk that may be lurking under its covers.

 

    • Testable: For each story that you write, you should be able to determine whether what was delivered met your expectations. To do this, the story must be written in a clear enough manner as to remove any ambiguity of what the end result should be.

 

Let’s look again at our story from before, but this time through the lens of INVEST.

As a college student

I would like to sell my old textbooks

so I can make money

For example, does “sell my old textbooks” describe a story that is small and independent? Perhaps not. Although this higher-level description does leave room for negotiation of how your team can best deliver the story, a more specific description may better enable that negotiation. What if you revised this story to better reflect how a college students may sell those textbooks?

As a college student

I would like to list my old textbooks for sale

so I can make money

This new version provides your team with a more refined vision for this capability that not only reduces the ambiguity and scope of the story, but also makes it more estimable because the team now has a better idea of what you have in mind. And because the story is now more clearly defined, it’s more testable, too.

But what about value? Is making money really the ultimate value that this story might yield to the college student? That’s definitely an end result, but this value statement doesn’t necessary add context to the story. Great value statements help your team better understand the why behind the story by providing clues to what a user might stand to gain after the story has been delivered. Let’s try to rework this story’s value statement to make that more clear.

As a college student

I would like to list my old textbooks for sale

so I can sell my textbook to the highest bidder.

That’s better. Your team now has a clearer understanding of what value the story will yield to the user once it’s delivered, which will provide clues to the complexity that may be inherent in this story. This additional context will better enable your team to negotiate tradeoffs that may allow them to deliver the story more effectively.

Getting more from INVEST

So now that you’ve seen what the individual qualities of INVEST are, let’s talk about how you can use INVEST to improve the quality of your own stories. To do this, we’ll start by talking about what each of these qualities has in common.

First, notice that while each of these qualities asks for a simple “yes” or “no” answer, how you arrive at that answer is subjective. For example, is your story valuable? Before you can answer yes or no, you must first define exactly what value means to your product as well as how that value will be measured. What about negotiable? Is your story negotiable enough? Once again, it’s up to you and your team to agree on how you strike the balance of defining your stories clearly enough so that they’re unambiguous, but not so well defined that they restrict your team’s creativity. This fostering of a deeper discussion across your entire team is the magic of the INVEST technique at work.

Next, notice that many of the INVEST qualities seem to support other qualities. For example, smaller stories naturally lead to more testable stories because smaller stories naturally become more concise and less coupled to other stories. Additionally, smaller stories also tend to be more estimable because these stories are naturally easier for a team to understand.

But not all qualities set up such a natural, virtuous circle. In fact, some qualities act as a balancing force to other qualities. For example, while in general we may prefer smaller stories, we don’t want to create stories that are so small that they don’t yield any meaningful value. For example, we want to avoid breaking stories into such small pieces that each piece is too small to move the product forward on its own.

Putting INVEST to work for you

Ensuring that your stories adhere to the qualities described by the INVEST technique can result in significant improvements to not only your stories but also your own communication with your team. But where should you start?

It would be unrealistic to expect that every story in your product backlog conforms to INVEST. Not only would this be time consuming, but overinvesting your time in stories further down your product backlog might also discourage you from changing those stories as you learn more about them in the future. Instead, INVEST is most appropriate when applied to those stories that are on deck for your next iteration. At this stage, you can be reasonably confident that you’ll make the investment in delivering those stories and you will have also learned more about those stories from your experience in previous iterations. At this point, it makes sense to spend the extra time ensuring your stories adhere to the INVEST qualities to improve your communication with your team.

By applying INVEST to those stories that are on deck for your team to deliver—and applying this technique at the right time—you can dramatically improve the level of communication between you and your team, which will dramatically improve the quality of the product that your team ultimately delivers.

Want to learn more ways to help your team get the most out of user stories? Check out my course, Creating Effective User Stories, 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.

Continue Reading
No Comments on How To INVEST In Your User Stories
6 min read
Uncategorized

Plotting The Scrum Master’s Career Path

6 min read
No Comments on Plotting The Scrum Master’s Career Path
6 min read

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 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 have found themselves wondering what’s next? Even if you’re happy in your role it’s normal to wonder what opportunities might exist beyond that role. In fact, you may find yourself wondering if there even is a Scrum Master's career path. If this sounds familiar then you’ll be happy to know that there is a career path for Scrum Masters…it just might not look quite like you expect.

Skilled Scrum Masters show an incredible amount of versatility, often adjusting their approach to meet the specific needs of their teams. This versatility makes the Scrum Master role an ideal jumping off point to a myriad of other career opportunities. But finding the right career path for you primarily depends on what facet of the Scrum Master role appeals to you most.

Becoming An Agile Coach

Often Scrum Masters are so pleased with the positive effect that an agile approach has had on their teams that they want to bring this approach to their entire organization. If this sounds like you and you’d like to be catalyst for changes inside of your broader organization than becoming an agile coach may be the right path for you.

To be successful, you’ll need to develop the ability to coach at higher levels in the organization than you do as a Scrum Master…often at the executive level. You’ll also want to familiarize yourself with concepts such as business agility to better explain how an agile approach can benefit even the non-technical functions in your organization as well as become well-versed in change management strategies since introducing a significant change to a large organization is not for the faint of heart. Finally, it can also be beneficial to broaden your exposure to agile methodologies beyond Scrum so you have a wider variety of tools at your disposal in your agile toolbox.

Making The Move to Product Owner

Sometimes Scrum Masters find what really appeals to them about the Scrum framework is how it enables them to deliver better products to their users. If you find yourself most fascinated by the end product your team is creating as well as understanding whether that product is actually meeting your users’ needs then the Product Owner role may be the right move for you.

Product Owners who have a background as a Scrum Master can be incredibly empowering to their teams. This is due not only to their deep knowledge of the Scrum framework, but also to the perspective that they’ve gained during their role as a Scrum Master. This perspective can better equip Product Owners to understand exactly what their Scrum teams need from them. This insight can be incredibly valuable as you work to find the right balance between setting a clear direction for your team but also giving them the freedom to identify better solutions as they emerge.

However, remember that each of the 3 roles on a Scrum team are defined as peers. Therefore you should be careful not to consider a move to the Product Owner role as a promotion above the Scrum Master role. In healthy teams, a move between these two roles would simply be considered a lateral move with the benefit of adding another facet to one’s Scrum experience.

Becoming A Manager

Often when agilists think of managers we picture pointy-haired Dilbertesque bosses forcing mundane tasks on their employees without a care for the well-being of those employees. However, while there certainly are managers that fit this description, generalizing all managers in this way would be unfair.

There are many excellent managers who regularly demonstrate a high-degree of empathy for their employees, a well-refined sense of emotional intelligence, and a sincere desire to help their employees grow both personally and professionally.

If this sounds like a path that may appeal to you then many of these same skills that you developed as a Scrum Master will transfer well. Combine this with the team facilitation skills that you’ll also develop as a Scrum Master and you can be well on your way towards a fruitful career as a manager.

Furthering Your Investment In The Scrum Master Role

Finally, it’s important to understand the Scrum Master role doesn’t always have to be a stepping stone into a new career. Many Scrum Masters have found that they enjoy the role so much that they desire nothing more than to simply spend their career as a Scrum Master. In fact, many organizations are now changing how they think about this role to help enable these types of individuals.

For example, many organizations have introduced a Scrum Master career ladder often culminating in a Senior Scrum Master position. As Scrum Masters progress along this ladder they gain more and more responsibility by working with multiple teams, working with teams at different skills levels in their agile journey, acting as an agile advisor to their broader organization, or even serving as a mentor to more junior Scrum Masters.

In addition to this role, many organizations who have endeavored to scale Scrum also have created roles specifically to enable this scaling process. Sometimes referred to as a Chief Scrum Master, this role is often tasked with assuming responsibility for the entire scaled Scrum implementation as well as for identifying and addressing any scaling dysfunctions that may occur as the organization grows.

If you find that you simply really love the act of being a Scrum Master, then either of these opportunities may appeal to you.

Finding The Right Path For You

Becoming a Scrum Master can be the first step in a long and rewarding career that can offer many different career paths over time. Whatever path is right for you, you can be sure that the skills and relationships that you’ll develop as a Scrum Master will serve you well on that journey.

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.

Continue Reading
No Comments on Plotting The Scrum Master’s Career Path
10 min read
Uncategorized

Finding The Right Scrum Master Job

10 min read
No Comments on Finding The Right Scrum Master Job
10 min read

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…

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 to break into this new career, or an experienced Scrum Master just looking for a new challenge, then this is a great time to be on the market. But with all of the Scrum Master jobs available, how do you know which job is right for you?

One of the best indicators of whether or not a Scrum Master job is right for you is how an organization’s view of the Scrum Master role aligns with your own view of the role. While the responsibilities of the Scrum Master role are clearly defined in the Scrum Guide, the lightweight and non-prescriptive nature of the Scrum framework often leads to many organizations taking wide latitude with how they interpret this role. And this interpretation may or may not align with your own interpretation.

Luckily, there are four simple questions that you can ask to help determine if you and a new organization are a match made in heaven, or if you may be in for a nasty surprise your first day on the job.

Question 1: How Do You Measure A Scrum Master’s Success?

One of the most common surprises you might find with a new Scrum Master position is when the organization views the Scrum Master role simply as a rebranded project manager. In these instances, you may find that your goals for your new position don’t align with your organization’s goals.

One of the best ways to identify if such a discrepancy exists is by asking how the organization measures the success of their Scrum Masters. Organizations who are simply treating the Scrum Master role as a rebranded project manager will often cite criteria as to whether or not the Scrum Master’s team is delivering the work expected of them on-time and in-budget, how well the Scrum Master is pushing the team to meet previously agreed upon deadlines, and if the Scrum Master is increasing the team’s velocity sprint-after-sprint. While the organization may feel that they find value in each of those criteria, many of those criteria still carry the smell of a command and control approach to software delivery, not to mention that they also mistakenly equate a team’s busyness with the value that they produce.

In contrast, organizations who have a healthier perspective on the Scrum Master role might cite criteria that could indicate that the Scrum Master is enabling their team to improve as a unit. For example, is the Scrum Master actively working with the broader organization to help them understand how they can better support the team, is the team becoming more self-sufficient and self-managing, and is the team’s overall throughput improving and their velocity stabilizing. Each of these criteria can indicate a Scrum Master who is actively improving the way their team operates and laying the groundwork for sustainable improvements to how their team delivers value to their organization.

But to truly know how deeply the organization understands this difference, you should also pose this same question to the existing Scrum Masters in the organization. Most large organizations will already have several Scrum Masters on staff. And, if there are already Scrum Masters in the organization, then they should most certainly be part of the interview process.

This is a great opportunity to also ask those current Scrum Masters how their success is measured in the eyes of the organization. If the answers given by the Scrum Masters differ significantly from the answers given by the organization, then this could be an indication that the organization hasn’t made their expectations clear to the Scrum Masters and that they don’t truly understand how they are being measured.

Question 2: What Is Your Career Path For Scrum Masters?

Another indicator of whether or not an organization is the right fit for you can be how they view the career path of Scrum Masters. But to know this, you first have to understand what you ultimately want from the Scrum Master role.

The versatility of the Scrum Master role makes it uniquely well-suited to serving as a jumping off point to other longer term career aspirations. For example, if you desire to broaden agile adoption across your organization, then the deep agile knowledge and facilitation skills that you gain as a Scrum Master can serve as an excellent step towards becoming an agile coach. On the other hand, if you find that you are most interested in the outputs that your team produces and how those outputs ultimately provide value to your stakeholders, then a career in product management may be in your future. Or finally, if you discover that you simply enjoy working closely with development teams and enabling them to continuously push the envelope of what they’re capable of, then simply continuing to pursue a mastery of the Scrum Master’s craft may be your goal.

Regardless of your long-term career aspirations, you should confirm that the career ladder available at your new organization will enable those aspirations. Often this can be learned by simply asking what an organization’s career path is for Scrum Masters.

If you desire an eventual move into product management, then you might seek an organization who encourages Scrum Masters to move laterally into other parts of the organization, such as business analysis or product management. On the other hand, if your longer-term aspirations are to become an agile coach, then you might seek an organization whose career ladder gradually increases the responsibility of Scrum Masters into broader areas of the organization until those individuals are acting as executive level coaches. Or, if you’re one of the many Scrum Masters who simply loves the role of Scrum Master and wants to continually refine their craft, then you might seek an organization with multiple levels of the Scrum Master role. These Scrum Master career ladders, which often culminate in titles such as Lead Scrum Master or Senior Scrum Master, are designed to a grow a Scrum Master’s skills by gradually increasing their responsibility by giving them responsibility for more teams, teams who are new to or who are struggling with their agile adoption, or even responsibility for training and mentoring more junior Scrum Masters in their organization.

Whatever your long-term career aspirations are, you’ll want to be sure to find an organization that will enable and support those aspirations long into the future.

Question 3: What Is A Day In The Life Of A Scrum Master?

One of the best ways to understand how the organization views the Scrum Master role is simply to ask the organization’s other Scrum Masters.

Asking each Scrum Master to describe a typical day can give a lot of insight into the expectations of that organization’s Scrum Masters. For example, do the Scrum Masters speak mostly of removing impediments for their team or do they seem to be more focused on teaching their team to remove these impediments for themselves. Or, do the Scrum Masters speak of leading the various Scrum events for their team or do they position themselves as a facilitator who helps their team get the most from these events. Listening to not only what activities the Scrum Masters describe, but also for subtle cues in how they describe them can be very revealing of the Scrum Master’s true role in the organization.

And, as with previous questions, turning this question back on the organization can reveal how well the organization understands how the Scrum Master role functions in their organization. If you find that the organization’s description of the daily activities of a Scrum Master differ significantly from what the Scrum Masters describe, then this may be an indication that the organization doesn’t truly understand the challenges their Scrum Masters are facing each day.

Question 4: What Are You Looking For In Your Next Scrum Master?

Finally, if you are fortunate enough to meet other Scrum Masters in the organization during the interview process, then you can also use this opportunity to gain insight into how well those Scrum Masters are currently functioning as a team.

For any lasting change to take effect in an organization, there must be multiple Scrum Masters acting in concert to enact that change. This not only enables those Scrum Masters act as a chorus of guidance to the organization, rather than as a single lonely voice, but it also allows each of those Scrum Masters to reinforce that same guidance across multiple teams in the organization.

But in order for this to happen, it takes more than just multiple Scrum Masters in the same organization…those Scrum Masters must be acting in a coordinated effort. One of the best ways to understand how well-coordinated this effort is is to ask the other Scrum Masters what they are looking for in their next Scrum Master.

Asking this question helps you understand how introspective the current team of Scrum Masters are about their strengths and weaknesses. A mature team of Scrum Masters will be very introspective which will allow them to identify gaps in their skills across the team. For example, the team may understand that while they have a strong grasp of the Scrum framework, they lack significant experience with other agile methodologies like Kanban. Or while the members of the team may feel very comfortable coaching at the team level, they may lack the skills to coach effectively at the executive level.

A mature team of Scrum Masters will be introspective enough to identify opportunities for improvement and will be actively seeking to fulfill these opportunities gaps with the next addition to their team.

Making Your Next Move The Right Move

Considering any change in employment can be a stressful time. This is especially true when that change involves a role that can be as widely interpreted as the Scrum Master role. But by understanding what you truly desire from your next opportunity, as well as asking the right questions to help you learn whether or not your new organization will support those desires, you can greatly increase your chances of making your next change a successful one.

Do you want to learn the skills that you'll need to ace your next Scrum Master interview? Check out my course series, Using the Scrum Framework, 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.

Continue Reading
No Comments on Finding The Right Scrum Master Job
6 min read
Uncategorized

Can the Length of Your Iteration Change in the Middle of Your Project?

6 min read
No Comments on Can the Length of Your Iteration Change in the Middle of Your Project?
6 min read

This post originally appeared on the PivotalTracker blog. Most agile teams work in iterations, especially those teams that follow a cadenced approach, such as scrum. And why not, since an…

This post originally appeared on the PivotalTracker blog.

Most agile teams work in iterations, especially those teams that follow a cadenced approach, such as scrum. And why not, since an iteration-based approach provides many advantages to teams. But while there’s little argument concerning the value of iterations, finding the right iteration length for a team is no small feat.

But, even after finding the right iteration length, some teams start to wonder if the length they once thought was so perfect is still the right choice for them. Perhaps they’re lured by the promise of the greater efficiency of longer iterations, or the greater responsiveness of shorter iterations call to them like a siren’s song. Whatever the reason, it inevitably begs the question: can a team change the length of their iterations in the middle of a project?

If your team happens to be pondering this same question, then you’ll be happy to know that the answer to this question is a resounding, “Yes!” It’s completely acceptable for teams to change the length of their iteration in the middle of their project and it actually happens more often than you might think. But while changing iteration lengths in the middle of a project can be done, it’s not a decision that should be taken lightly. Luckily there are a few things that can improve your odds of success if your team is considering heading down this path.

Preparing Your Team for the Change

Any change to how your team works will require time for them to absorb. This is true whether that change is the adoption of a new piece of the team’s technology stack, a new technical practice, or even a new team member. Even if the change is ultimately a positive one, don’t be surprised if your team’s output dips a bit while they become accustomed to this new way of working. This is especially true when changing your iteration length, since you’re fundamentally altering the timebox in which your team works.

The first thing you’ll need to do to prepare your team for this change is to help them understand how their planning activities will also need to change. For example, your team is probably conducting a planning session at the beginning of each iteration to select and plan their work for the upcoming iteration. And they’re also probably holding a review session at the end of each iteration to review their work and ensure that they’re on track to delivering what their customer needs.

If you are shortening the length of your iteration by half—e.g., from two weeks to one week—then you can expect that the duration of the accompanying planning and review sessions will also be shortened by half. For this to be successful, you must make sure your team understands that this shortened planning duration means that they’ll need to be more efficient during those sessions in order to accomplish everything they need to within the time allowed. A team that shortens its iteration length but continues to spend just as much time in planning sessions gains nothing and actually loses efficiency as now a smaller percentage of their time is spent actually producing value.

On the other hand, if your iterations are becoming longer, then you’ll need to prepare your team for the reality that they’ll now need to spend correspondingly more time in their planning and review sessions. For example, imagine that your team is currently working in two-week iterations but decides that three-week iterations are a better fit. If your team is currently spending four hours on the first day of each iteration planning their work for the next two weeks, then you’ll need to prepare them to spend roughly six hours planning their work on the first day of every iteration moving forward. While most teams will, at least superficially, understand the need for correspondingly longer planning sessions to accommodate the larger undertaking of work, *understanding* a six-hour planning session and *participating* in a six-hour planning session are two entirely different things.

Predicting the Result of the Change

But once you’ve prepared your team for this change, how do you understand the effects it will have on your project? A team’s velocity is often treated as one of the major indicators of a project’s success. And while we understand that velocity is not our goal, tracking a team’s trend in velocity over the past few iterations can be a powerful tool for forecasting the capacity that we can expect from that team in the future. But how can we predict the change in our team’s velocity after we’ve altered their iteration length?

It can often be tempting to simply extrapolate a team’s change in velocity based on the corresponding change in the team’s iteration length. For example, if your team has an average velocity of 50 points per iteration using two-week iterations, then it would stand to reason that that same team should produce 100 points per iteration using four-week iterations, right?

Maybe. Or, maybe not. Extrapolating a team’s new forecasted velocity based on the change in their iteration length may be a good place to start, but the actual effect of that change is rarely that simple.

A lot of factors can affect a team’s velocity from iteration to iteration, and the actual result of a change in iteration length may not be reflected in that team’s velocity for several iterations. This means that while your team’s velocity *will* change as result of a change in iteration length, *how* it will change will be tough to predict. For this reason, you’ll need to be prepared to expect the unexpected for the first few iterations under the new length as well as be prepared to account for this change in velocity in your longer term project planning.

Making the Most of the Change

While you won’t want to alter your team’s iteration length on a regular basis, the occasional change can be not only successful but even a very positive change for your team.

However, this change shouldn’t be taken lightly and your team will need your help to make it successful. By preparing your team for a change in iteration length using the tips above, you can help ensure they make the most of this new new change to their workflow.

Want to learn more about how to make agile work with your team when things don't go as expected? Check out my course, Agile in the Real World, for tips and techniques for making agile really work in your organization.

Don't have a Pluralsight membership yet? Try the entire Pluralsight course catalog free for 10 days here.

Continue Reading
No Comments on Can the Length of Your Iteration Change in the Middle of Your Project?

Type on the field below and hit Enter/Return to search