Jeremy Jarrell

Agile Made Simple

Creating Great Sprint Goals

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…

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 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.

No Comments on Creating Great Sprint Goals

Agile Does NOT Make You Go Faster

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.

No Comments on Agile Does NOT Make You Go Faster

Prioritizing Across the Themes in Your Product

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….

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.

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:

  1. Tag a new visitor when they visit the website
  2. Identify and log a returning visitor when they return to the site
  3. Analyze each user’s engagements with the website over a given time period
  4. 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:

  1. Improve the rendering performance of the Visitor Behavior report
  2. Improve the filtering performance of the Visitor Behavior report
  3. Reduce the performance impact of the tracking code on customer websites
  4. 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.

No Comments on Prioritizing Across the Themes in Your Product

How Many Teams Can A Scrum Master Work With?

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 new to the Scrum Master role and are just trying to find your way? Or, are you an experienced Scrum Master 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 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.

No Comments on How Many Teams Can A Scrum Master Work With?

Coaching Your Product Owner As A Scrum Master

Often when we talk about the responsibilities of the Scrum Master role one of the first topics that come to mind is coaching. But too many Scrum Masters believe that…

Often when we talk about the responsibilities of the Scrum Master role one of the first topics that come to mind is coaching. But too many Scrum Masters believe that their responsibility for coaching stops at the Development Team. While coaching of the Development team is important, Scrum Masters must not forget that they also have a responsibility to coach their Product Owners.

However, despite the importance of this responsibility, many Scrum Masters find themselves uncomfortable with the idea of coaching their Product Owners. One reason for this is that the responsibilities of the Product Owner role focus on Product Management, which is an area with which few Scrum Masters have any practical experience.

But there's also another, more insidious reason. In many organizations, the Product Owner is likely to hold a senior title in the organization, such as Director or Vice President. In most cases, these titles are far more senior than the Scrum Master's own title. To make matters worse, while Scrum Masters often come from technical or project management backgrounds, Product Owners may hail from strange lands such as sales or marketing. These lands are likely to be foreign to not only the Scrum Master but to the rest of the Development Team, as well.

This seniority, combined with the unfamiliarity of the role, can put the Scrum Master in an awkward position when they're asked to coach their Product Owner. However, both the Scrum Master and the Product Owner must always remember that inside the walls of the Scrum team…everyone is equal.

Helping Your Product Owner Communicate Their Vision

The good news is that there are plenty of opportunities for Scrum Masters to coach their Product Owners that are not dependent on seniority level or a deep knowledge of Product Management.

One such opportunity is helping the Product Owner understand how they can best communicate their intent to the Development Team. There are many techniques to accomplish this, such as product visioning, product roadmapping or release planning. However, one of the most powerful tools for helping your Product Owner get the details of their vision out of their head and in front of your Development Team is the product backlog.

Scrum Masters often tell their Product Owners that they are responsible for the management of their product backlog. However, those same Scrum Masters are often silent on exactly how to do this.

One area that's ripe for coaching is helping your Product Owner understand how they can better convey their intent through user stories. A Scrum Master can provide invaluable feedback on what the right level of detail is in those user stories to accurately communicate the Product Owner's intent without constricting the Development Team's implementation options. In addition, an adept Scrum Master can also provide advice as to how the right level of detail might change depending on where that item falls in the product backlog.

And speaking of backlog ordering, a Scrum Master can also help their Product Owner understand the different backlog prioritization strategies that are available to them and when it might make sense to choose one strategy over another.

Finding The Right Touch With Your Product Owner

Another common area of coaching is helping your Product Owner understand how they can make themselves more available to the Development Team and why this is important.

Striking a balance between building a strong rapport with the Development Team and micro-managing the team's every move is an act that requires finesse. This can be an excellent opportunity for a Scrum Master to add value as an astute observer who can provide feedback on the Product Owner's interactions with their team.

Being Your Product Owner's Conscience

And finally, an excellent but often-overlooked opportunity for coaching is for the Scrum Master to serve as the Product Owner's conscious. Earlier we mentioned the importance of helping the Product Owner develop a clear vision for the product that your team will deliver. However, even with a clear vision, it can still be easy to be led astray.

In the fast-paced world of product development, new opportunities arise quickly. Key customers may demand capabilities specific to their own business, sales teams may pressure teams for functionality necessary to close a large deal, and competitors may unveil more than enough new features to make any Product Owner jealous.

When these new opportunities arise, it's important for the Scrum Master to help the Product Owner stay true to their original product vision, even in the face of temptation.

One way for a Scrum Master to do this is to continually ask “The 3 W's”:

  • Who is this feature for?
  • What need will it accomplish for that person?
  • Why are we as an organization investing in filling that need?

But merely asking these questions isn't enough. A skilled Scrum Master must also help their Product Owner evaluate whether the answers to these questions match the stated vision for their product, and if they do not, determine whether it's time for that vision to change in response to a previously unforeseen opportunity.

Embracing Your Role As Coach

As a Scrum Master, it's your responsibility to coach your entire team, including your Product Owner.

While this coaching arrangement may at first feel uncomfortable, investing the effort to do so will help improve both the working relationship of your entire team as well as improve the chances that what your team delivers will ultimately provide value to your organization.

Do you want to learn more about how to grow your team through coaching? Check out my course series, Using the Scrum Framework from Pluralsight, to learn how to set yourself apart as a Scrum Master and help your team reach their highest potential.

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

No Comments on Coaching Your Product Owner As A Scrum Master

Dividing and Conquering: Finding the Right Size for Your Team

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.

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

Taking an Active Approach to Transparency in an Agile Team

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.

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

Should A Manager Be A Scrum Master?

In a recent post, I discussed whether the Scrum Master and Product Owner roles could be successfully combined. As you probably recall, the answer to that question was a resounding…

In a recent post, I discussed whether the Scrum Master and Product Owner roles could be successfully combined. As you probably recall, the answer to that question was a resounding “no”. In fact, the Scrum framework intentionally keeps these two roles separate in order to encourage a healthy tension between the needs of the development team and the ultimate needs of the organization.

However, when posing this same question in the context of the Scrum Master and the Development Manager, the answer becomes less clear. This is primarily because while the Scrum framework clearly describes the roles of Development Team, the Scrum Master, and the Product Owner, Scrum has no concept of the role of the Development Manager. This means that the Scrum framework offers no guidance to how this role should relate to the Scrum Master role.

Considering The Ideal Traits Of A Scrum Master

To better understand how these two roles might relate to one another, let’s take a moment to consider their responsibilities.

In addition to all of the responsibilities that are defined for Scrum Masters, one of the most important qualities of a Scrum Master is that they are viewed as a Servant Leader to their team. Servant leadership is a deep topic, but some of the qualities of a true servant leader are that they share power with their team, they put the needs of others first, and they put a strong emphasis on helping those with whom they work with grow both professionally and personally. In fact, one of the most telling traits of a servant leader is that rather than believing that their team is there to serve them, they instead flip the pyramid and believe that they exist to serve their team.

Comparing These Traits To A Development Manager

Let’s compare the approach of servant leadership to that of a traditional Development Manager. While there are managers who are exemplary servant leaders, the traditional definition of a manager is one who has functional authority over their team.

One aspect of this is that these managers often have hiring and termination authority over their team, which can significantly alter the dynamic that exists between the Scrum Master and their team.

In addition, many managers are also responsible for the day-to-day tasking of their team. While this may seem to be a simpler and more reliable approach for many organizations, it flies directly in the face of the principle of self-organization that a Scrum Master should be attempting to instill in their team.

Dreaming The Impossible Dream

With so many core differences between the Scrum Master role and the Development Manager role you might think that combining the two successfully is impossible. But this isn’t actually the case. While it can be incredibly rare, the right individual can find success in both roles.

To do this, that individual must be keenly aware of the responsibilities of each role and where they might conflict with one another. For example, such as how the expectation that a manager provide day-to-day tasking to their team conflicts with the very qualities of self-organization that they should be trying to grow in that team.

In addition, where these conflicts exist this individual must also make it clear to their team when they are wearing the hat of a manager, when they are wearing the hat of a Scrum Master, and when they are trading one hat for another. This explicitness in the role that they are currently serving can help provide the context that their team needs to best interpret the Scrum Master/Manager’s advice.

Making The Most Of A Bad Situation

While combining the Scrum Master and Manager roles can be challenging, it may not be without its perks.

Scrum Masters often encounter tough organizational impediments that can be challenging to resolve on their own. Such impediments might include responsibilities outside of the sprint that are distracting members of the Scrum team or an inability to secure key hardware or computing resources that are necessary for the completion of a key story.  But by leaning on their role authority as a manager in the organization, Scrum Master/Managers can often facilitate the removal of these impediments much easier than that of a non-manager Scrum Master.

In fact, a successful Scrum Master/Manager can even use their authority to grant greater latitude to their team which better empowers their team to take on more responsibility, moving them closer towards self-organization.

So while combining the Development Manager and Scrum Master roles is far from an ideal situation. An individual with a keen sense of the responsibilities of each role can still find success in this difficult situation. In fact, the right individual might even be able to use the unique combination of these roles to their advantage.

Want to learn more about how to make Scrum work in your unique environment? 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 Scrum adoption.

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

No Comments on Should A Manager Be A Scrum Master?

Using the Blocking and Tackling Backlog Refinement Pattern to Ensure a Great Sprint Planning

This post originally appeared on the PivotalTracker blog. We’ve all had that sprint planning meeting. Your team spent the entire session arguing over which stories to include in the next sprint…

This post originally appeared on the PivotalTracker blog.

We’ve all had that sprint planning meeting. Your team spent the entire session arguing over which stories to include in the next sprint and you never even made it to sizing. By the time the session was over, you were no closer to having the next sprint planned and all that you’ve gained for your trouble is a frustrated and disheartened team.

If this sounds familiar, then it might be time to consider backlog refinement. Backlog refinement is a practice intended to help you keep the top of your backlog in a refined state so you can have better sprint planning sessions. But despite the value backlog refinement can yield, there is no officially prescribed approach for how to do it. However, if you’re looking for a simple way to introduce this practice to your team, then don’t despair: there’s an easy approach that you can use with your team today.

Blocking and Tackling Your Backlog

The *blocking and tackling* approach consists of two separate refinement meetings spaced evenly throughout each sprint. For example, if your team operates on two-week sprints, then you might hold the first session on the first Wednesday of the sprint and the second session on next Wednesday of the sprint.

Blocking

In the first session, known as *blocking*, your goal is to select the stories that you expect your team to work on in the next sprint. Your selected stories will be a function of both your planned goal for the next sprint and your team’s forecasted capacity for that sprint. If your backlog has already been prioritized so your most important stories are near the top, and these stories already have a rough estimate applied to them, then this process tends to be relatively straightforward. However, it’s still helpful to do this session with the help of your team for two reasons.

First, sharing more detail about your goal for the next sprint and which stories you believe will enable that goal helps your team better understand the bigger picture of what they are trying to create. This understanding will allow them to make decisions in the current sprint that will put them in a better position to accomplish the work selected for the next sprint.

Second, while your team will save their final estimates for the next sprint planning meeting, they can often share their impression of whether or not the work selected seems too large for the next sprint—or even too small. If it turns out that the work you selected isn’t quite the right fit, then you have the rest of the sprint to decide how to adjust your selection accordingly.

The rest of the session is saved for discussion. Introducing the stories you’ve selected to your team often leads to questions and discussions about alternative approaches…many of which you may not have considered. Surfacing these questions before the sprint planning meeting allows you to take time before the next refinement session to find the answers your team needs to confidently move forward.

Tackling

The second session, known as refinement, is where the real work happens. During this session, you will work with your team to further refine the selected stories to ensure that they’re ready for the next sprint planning meeting.

This session begins with you reviewing the selected stories for the next sprint to help refresh your team’s memory of what was selected. This is also a great opportunity to call out any changes that were made to your story selection to better fit your team’s forecasted capacity.

Next, take the time to provide any answers to questions you were unable to answer in the previous session. Not only does this help further refresh your team’s memory of their concerns regarding each story, but it also improves the chances of productive discussion later in the session.

Once you’ve answered any outstanding questions, give your team the opportunity to ask any questions that may have occurred to them since the last refinement session. Your team has now had several days to more thoroughly consider their approach to these stories; therefore, a few questions are to be expected. This is their chance to pose those questions to you before the deeper discussion begins.

Finally, the remainder of session is focused on ensuring that the selected stories are in a *ready state* for the next sprint planning session. Many high-performing teams already have a checklist in place of what they consider necessary for a story to be ready for discussion in an sprint planning meeting. The contents will vary, but at a minimum they often specify that a story must have a brief description of its objective, acceptance criteria, and a rough estimate.

If your team doesn’t have a checklist of its own yet, then the INVEST criteria is a great place to start. INVEST specifies six qualities that are often associated with well-refined stories. Try comparing each of your selected stories against the INVEST criteria to see what gaps it exposes. After several sprints of this, you’ll likely start to recognize which qualities seem to add value to your team and which qualities do not. Once this happens, feel free to adapt the INVEST criteria to your own set of criteria that makes the most sense for your team.

Getting the Results You Need

Regularly holding backlog refinement sessions will result in smoother sprint planning meetings and, ultimately, more predictable sprints. However, the approach outlined above should be considered a starting point, so don’t be afraid to adjust this practice to better fit the needs of your team.

Regardless of how you ultimately approach backlog refinement for your team, what’s important is that your team is always ready to start the next sprint and that you or your team never have to suffer through a painful sprint planning meeting again.

Are you a Product Owner who wants to help your team better understand your vision for your product. Or do you want to understand how you can work more effectively with your development team? Check out my course series Product Owner Fundamentals, part of the Using the Scrum framework learning path from Pluralsight, to learn how you can use Scrum to help your team deliver great products that your customers love.

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

No Comments on Using the Blocking and Tackling Backlog Refinement Pattern to Ensure a Great Sprint Planning

Using An Estimation Grid To Improve User Story Estimation

Estimation is tough. We all know it and we all struggle with it. Most of the challenge of estimation is due both to the abstract the nature of software as…

Estimation is tough.

We all know it and we all struggle with it. Most of the challenge of estimation is due both to the abstract the nature of software as well as the challenge of estimating something’s complexity. In fact, due to the abstract nature of estimating in story points, teams find that their goal is less often accurate or precise estimates, but more often consistent estimates.

Although we often struggle with assigning specific values to items we’re actually quite good at assigning relative values to objects. For example, few of us could glance at a bucket of water and estimate exactly how many ounces that bucket will hold. But, we could easily estimate that the bucket holds more ounces than a glass and less ounces than a swimming pool.

Teams can also apply this same relative estimation technique when estimating a particularly tricky piece of work. However, this is often done by estimating new stories relative to the size of other stories that the team has not yet worked on, such as other stories that have also been selected for the sprint.

While any relative estimation can be helpful, it can be more helpful to compare new stories to stories that have already been delivered and that the entire team agrees were estimated correctly.

Meet the estimation grid

One of the most powerful ways to do this is with the use of a tool called an estimation grid, which is simply a grid containing a cell for every other number in your team’s estimation range.

For example, if your team estimates using the values in the Fibonacci sequence from 0 to 13 then your estimation grid would look like this.

In each cell, place a sticky note representing a story that your team has recently completed that everyone agrees was indicative of its original estimate. For example, if in the last sprint your team completed a story that was originally estimated at 3 points, and everyone still agrees with that estimate, then place it in the cell for 3.

Putting the estimation grid to work

Once the grid is built you can begin working through your estimation routine as normal, such as by playing a few rounds of Planning Poker. However, once your team gets stuck on a particularly tricky story then it’s time to refer to the grid.

For example, imagine that your team is trying to estimate a story to add support for a new payment gateway to your ecommerce app. While the act of supporting the new gateway seems straightforward, it will involve touching a particularly complex piece of the codebase. For this reason, many of the team are unsure of how to estimate this story.

But by comparing this story to the reference stories already found on the estimation grid, your team is able to spot key similarities between this story and the reference 3 point story, such as a relatively straightforward set of business rules coupled with a complex area of the codebase. As a result, the team estimates this story as a 3.

Later, when the team finds themselves stuck on another story to add a simple CSV export to an existing report they return to the estimation grid. However, this time the answer is not as straightforward. While they find that adding this export seems more complex than the reference 1 point story, it’s not quite as complex as the reference 3 point story. But since the complexity of the story seems to fit neatly between these two reference stories your team assigns the story an estimate of 2.

Getting the most out of your estimation grid

While the estimation grid is already a powerful tool, there are a few things that you can do to get even more out of this tool.

First, resist the urge to use the estimation grid for every story that your team encounters. You’ll still want your team to be able to evaluate the complexity of each story through discussion and shared discovery rather than simply defaulting to comparing every story to the same handful of stories. Your estimation grid should be an aide, not a crutch, so only refer to it when needed.

Next, be prepared to update your estimation grid periodically. As the work your team is doing evolves they’re likely to begin working with different technology stacks, in different areas of the codebase, or with different themes of your product. Occasionally checking that your reference stories reflect these changes and replacing those that do not will help keep your reference stories relevant to your team’s needs.

Finally, resist the urge to create a cell for every value in your team’s estimation range. For example, you may have wondered why we didn’t create a cell for each value in the Fibonacci sequence from 0 to 13. There are two reasons for this. First, finding a canonical reference story for each value in that range can become tiresome, especially for those values that your team rarely uses. But second, and most importantly, you don’t want to paralyze your team with too many choices.

Generally, speaking humans make decisions easier when presented with fewer choices. For more on this, you can check out this article from Harvard Business Review, but for our purposes simply know that presenting your team with more choices to compare a tricky story to is likely to make act of the estimation longer rather than shorter. Instead, keeping your estimation grid simple and only giving your team just enough options will help keep the entire estimation process as painless as possible.

Wrapping up the session

Once your planning session is complete, a great way to wrap up is by laying all of your team’s estimated stories over your estimation grid and looking for patterns or clusters. For example, did it seem as if your team estimated the majority of their stories at the high end of your range? Larger stories are more complex and, as a result, tend to be less well understood. While a single large story in a sprint is unlikely to be a cause for a concern a sprint that’s primarily comprised of large stories is likely to be a very risky endeavor.

Or does your sprint seem to have many 0 point stories? While some stories may be so simple as to feel as if they do not warrant a point, no story is truly free. Every story takes time and attention from your team to deliver. While a few 0 point stories may not be cause for concern, many 0 point stories can add up and threaten your team’s chances of delivering everything they’ve planned for the sprint.

While the right answer is going to vary for every team, generally speaking I like to see most of a team’s stories clustered in the lower end of their estimation range. Stories this size tend to be just large enough that you can understand the impact that each story will have on our team’s velocity but are not so large to contain large amounts of unknown.

If your team’s sprint doesn’t seem to be clustered as I just described then don’t panic, you can simply take some of your larger stories and try to split them into smaller stories to reduce your risk. And if your team gets stuck estimating some of those newer stories then now you have a tool to help them.

Want to see 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.

No Comments on Using An Estimation Grid To Improve User Story Estimation

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