The 3 Levels of a Scrum Master Removing Impediments

Often when someone becomes a Scrum Master the only instruction they are given is to “remove impediments”, but what does that even mean?

Impediments can come in many forms and have many effects on a team.  Some can simply slow a team down by slowly eating away at their progress one bite at time while others can stop a team dead in their tracks.  How successful a Scrum Master is at identifying and removing these impediments tells a lot about how they are growing in their role.  To dive deeper into this, let’s look at some of the most common types of impediments a team can face and how a Scrum Master can detect and remove them.


Blockers are the classic stop a team in their tracks problems that most people tend to think of when they picture impediments.  Maybe the hard drive cracked on a tester’s laptop taking him totally out of action for the next 2 days.  Or, maybe a developer’s daughter suddenly became sick and she needs to leave early to pick her up from school.

BlockerWhatever the reason, blockers are often easy to spot because someone on the team grinds to a halt as soon as they occur.  In fact, these are typically the types of issues most people think of when asked “What’s in your way?” at the morning standup.  As a Scrum Master, it’s your job to listen to these issues and do everything in your power to clear these blockers so the team can keep moving forward.

Many of these you can probably address yourself, directly.  Is there a spare laptop somewhere a tester can work from in the meantime, or can he pair with another tester to test his stories in parallel?

Others, however, you may be able to do very little about.  Can the team work around the work in progress of the developer who suddenly had to be out of the office due to a family illness?  Or, can she work remotely while her daughter recovers?  You may have to stretch yourself to remove these issues, or you may have to get creative to help the team work around them while these issue are in their way.

Classic Impediments

Classic Impediments are a bit trickier.  These are the things that slow your team down but don’t necessarily ground them to a halt.  Often the team is aware of these issues but have become so accustomed to working around them that they have simply written them off as “that’s how things will always be”.  In some cases, the team may have become so used to these issues that they don’t even notice them anymore or have forgotten that they even exist.  Examples of common impediments include a team who is not empowered to make changes to their production environment in order to deliver new features or a team that has to frequently stop to correct merge conflicts as a result of dealing with an antiquated source control system that they don’t have the freedom to replace.

ImpedimentIt can take an adept Scrum Master to detect these impediments since the team has often become so used to dealing with them they no longer even bother to mention them at the daily standup.  Your job as Scrum Master is to first bring these issues to the team’s attention and remind them that they exist and are slowing them down.  Once the team has accepted these issues, though, impediments often aren’t as easy to remove as blockers.

This is because impediments are often more of a global, systemic issue that affects the team as whole rather than a single individual.  In addition, impediments tend to be more subtle artifacts that arise as a result of factors in your organizational structure or culture.  These can make them very difficult to remove.

While your first task as a Scrum Master may initially be to remove these impediments so your team can operate at their full potential, ideally your long term goal should be to empower your team to start to remove these impediments for themselves.  I’ve mentioned previously that impediments tend to be symptoms of deeper issues in your organization’s culture.  If this is the case then the team working to identify and address these impediments themselves will have a longer lasting effect than the Scrum Master swooping in to correct these issues for them.  This is because the most effective way to address deep organizational issues is for the organization to acknowledge and address these issues for themselves.  Even if the Scrum Master is also a member of the organization, simply fixing issues for others on the team often becomes more of a band aide than a meaningful change in behavior.


The final type of impediment a Scrum Master may find themselves removing are the landmines and pitfalls that lie in wait for their team to trip over.  These can be the trickiest type of all since, unlike a classic impediment which the team may have once been aware of but has since faded to the background, they likely have never even noticed the landmines before.  Often these are issues that a Scrum Master recognizes only because he’s seen them befall similar teams in the past or because it takes a second set of eyes to notice them.

LandmineSome landmines a Scrum Master may spot but aren’t entirely obvious to the team at large include an aggressive functional manager over participating in ceremonies such as retrospectives or daily standups thus limiting the transparency or honesty that the team is comfortable sharing.  Or maybe daily standups moved from the morning to the afternoon turning them from an opportunity for the team to plan and synchronize at the daily level to a mere afternoon status meeting.  Or even a Product Owner who is overcommitted to multiple teams thus limiting their ability to effectively clear a path for any of them.  Note that in all of these cases while the presence of such a landmine isn’t a guarantee of disaster it can at least be a warning of possible issues to come.  It’s up to the Scrum Master to evaluate each situation in the current environment and determine how likely it is that the landmine will detonate at the worst possible time for the team or simply become a harmless dud that fizzles out before the team even blindly wanders past it.

To make things even tougher, it’s not uncommon for a team to be initially resistive when a Scrum Master first attempts to point out landmines to the the team.  This means that a Scrum Master must have a sensitive touch when coaching their team to identify and to remove this particular type of impediment.

As with classic impediments, it’s often best to coach the team to remove these impediments for themselves.  But, how you coach may depend on how open your team is to such issues.  If you find that your team is particularly responsive to learning about and addressing landmines then simply guiding them to identifying them with a series of leading questions may be quite effective.  On the other hand, if your team resists the possibility of such landmines due to a strong cultural bias or organizational gravity then you may be better off standing aside while the team sails towards the brink to help illustrate the possible downfalls of not addressing the landmines that lie in their path.  Although this approach isn’t ideal, often it’s only necessary once or twice before a team becomes more receptive to feedback on where the landmines may lay.

A Natural Progression for Scrum Masters

In all cases, how a Scrum Master progresses through identifying each type of impediment, removing it, and ultimately coaching the team to clear it for themselves are important steps in the journey from Scrum Master to coach.

Although we often describe the Scrum Master role as the one who must remove impediments for their team, it’s important to remember that true success with agile only becomes possible once the team has become empowered to identify and remove such impediments for themselves.

Want to see more about becoming a great Scrum Master? Check out my course, Agile in the Real World, for tips and techniques to help your team perform at the highest level.

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


Why Your Minimum Viable Products Probably Are Not Viable nor Even a Product

Founders pay a lot of attention to Minimum Viable Products, or “MVPs”.  However, for all of the attention that’s paid there seems to be just as much confusion about what an MVP exactly is.

Despite the name, MVPs aren’t intended to actually be viable products.  MVPs serve one purpose and one purpose only…to validate a specific hypothesis.  Sometimes that means you need to release a product to the market to validate that hypothesis, but usually not.

cup-of-coffee-and-napkin-sketchWhat this means is that most early MVPs actually aren’t viable in the marketplace.  In fact, they’re usually not even products.

Let’s dive a bit deeper into this.  Often when you first begin work on your product the hypotheses that you’re validating are less about specific features that would be tested with a build and more about your overall product direction or business model.  These are the “would you pay for this questions” that underly all assumptions about your product from the outset.  And, these are the most important assumptions that you need to be validating with your early MVPs.

So, how do you validate these early hypotheses?  You do so with the most lightweight MVP possible…a conversation.  You don’t need a functioning app, or even a prototype, to be able to have an early discussion with a potential customer about the validity of your idea.  Often, you just need a list of questions and a sketch on a napkin.  If this list of questions and sketch helps you to test whether or not your hypothesis is valid then this is your MVP.

Could this list of questions and sketch be considered a product?  Probably not.  Would it be viable in the marketplace?  Absolutely not.  But, it’s well suited to validating the specific hypothesis that you have at that moment because this hypothesis is about your overall vision for your product and where it fits in the market…not about specific features.

Meet the MMP

So, if an MVP is not always viable in the market then what is?  The MMP.

An MMP, or Minimum Marketable Product, embodies what people often think of when it comes to MVPs.  An MMP is the smallest possible product increment that could conceivably be viable in the marketplace.

Is a list of questions and a napkin sketch a viable product in the marketplace?  No.  But the first build of that product containing the bare minimum of features may be.  Often when we discuss adding only enough features into our product to create an MVP, we’re actually referring to an MMP.

All MMPs are MVPs

We use MVPs to prove a hypothesis that we’ve set for our product.  Depending on the nature of that hypothesis our MVP may be a sketch on a napkin, a landing page that collects email sign ups, or even just a cup of coffee and conversation with a potentialmvp-mmp customer.  It doesn’t matter what form they take, as long as they can be used to validate a hypothesis and move your product forward.

Once our hypotheses have matured to the point that we’re now testing actual features our MVPs start to become viable product builds, often in the form of MMPs.  Although an MMP will be more refined than the MVPs described above it can be just as useful for validating a hypothesis about your product.  The point we must remember, however, is that shipping a full fledged product to validate a hypothesis will take much more time and effort than walking a napkin sketch to a coffee shop.  This means that we should always be asking ourselves if we’re using the absolute lightest weight MVP possible to validate that hypothesis.

Choosing the Right Path

In the end, it all comes down to the nature of the hypotheses that you wish to validate and where you are in your product life cycle.   Early hypotheses concerning your vision or market fit can be much more effectively validated using a simple MVP.  This is because their lighter weight and more malleable nature will allow you to get feedback sooner and more easily adjust course if you take a misstep.  Later hypotheses concerning specific features, distribution channels, or platform decisions may warrant the investment in an MMP.  But your goal is to delay that investment as long as possible until you’ve proven as many of your initial hypotheses as possible using other means.

Want to learn more about choosing the right features for each step of your release?  Check out my course Agile Release Planning on Front Row Agile to learn more.


Beware Your Early Adopters

If you’re building a product then you want users…it’s that simple.  

And you want these users as soon as possible because the earlier you can get users, the sooner you can get start to get that feedback that will be so crucial to your product’s success.

These first users are your early adopters and the feedback that they provide will be instrumental in the early stages of your product.  But as much as you need your early adopters there’s one thing that you must remember about them:  your early adopters are not your mainstream users.

Sure, there may be overlap.  And sure, with any luck, some of your early adopters will grow alongside your product into your mainstream users as your product matures.  But, more often than not, early adopters are an entirely different breed than your mainstream users.

Inside the Mind of the Early Adopter

Early adopters tend to have different needs than mainstream customers.  On the surface, both groups may be solving the same problems but by their very nature early adopters are more adventurous and are willing to put in more of an effort to do so.  And, while everyone wants a great experience, early adopters tend to be more tolerant of the occasional bug or odd usability choice.

But there’s an emotional component at play here, as well.  Often early adopters are just as attracted to your product for the fact that it’s new as they are for the underlying problem that it solves.  This newness is exciting in its own right and, in large part, drives their use of the product.  But this “I used your product before it was cool” quality isn’t a quality that you can count on to drive usage as a your product matures.

Inside the Mind of the Mainstream User

Mainstream customers are less drawn to a product for its newness but are also less drawn by the product’s feature set.  Since this may be surprising, let me explain.  Mainstream customers don’t buy a product because of its specific features, they buy a product because of the specific problems it solves.  This doesn’t mean that all of the same features that were compelling to early adopters aren’t also compelling to your mainstream customers, but it does mean that these feature aren’t likely to be the deciding factor to whether they make the jump.

Expanding on this, your mainstream customers will have much mess tolerance for the same bugs and usability issues that your early adopters had.  Whereas your early adopters viewed rough corners and hiccups with your product as a fair trade for getting access to a new and exciting product early your mainstream customers won’t be so kind.  These users will expect a complete and polished product that functions out of the box.  And, to the same end, while an early adopter may be willing to invest some time fiddling with and configuring their own experience, a mainstream customer will want an experience that fits their needs on day one.

Making the Jump

So, why does this matter?  This matters because if you expect your product to grow you’ll ultimately need to make the jump from your early adopters to your mainstream customers.  The catch, however, it that the same qualities that appealed to your early adopters may not entirely align with the same qualities that will appeal to your mainstream users.  Therefore, you may have to make the decision to alienate some of your early adopters, who have been with since the beginning, in order to grow to the mainstream.

To this end, you’ll also want to be cognizant of catering too much to the early adopters in your roadmap.  You’ll want to measure every step of the way once your product hits the market but beware of blindly following those metrics.  Don’t double down on features or trends that have had a lot of uptake in your product by your early adopters but aren’t likely to appeal to your mainstream customers.  By the same token, evaluate judiciously the decision to drop any feature with little uptake by your early adopters that potentially may be a play towards the mainstream market.

Product development is a journey.  On that journey you’ll encounter many customers all with different needs.  Don’t forget your early customers and the lessons they taught you at the beginning but don’t become trapped by those same customers, either.  By learning to tell the difference between the needs of your early adopters and the needs of your mainstream customers you’ll know when it’s time to take the next step in your product’s journey.

Want to learn more about how to grow your product from inception to the mainstream?  Check out my course Agile Release Planning on Front Row Agile to learn concrete strategies for planning your product’s evolution.

A quintet of vintage hanging light bulbs over a dark brown background

Get More out of Your Sprint Review

Is your Sprint Review just a dog-and-pony show for your stakeholders?  If so, then you may be missing one of the most valuable aspects of the Scrum process.

It’s Not a Demo, It’s a Review

The root of this problem often lies in the habit of referring to the Sprint Review as a “demo”.  Demos are one-sided meetings where the team walks through the highlights of the product in a carefully scripted manner to a disinterested set of observers.

Reviews, on the other hand, are hands-on conversations between the team and stakeholders to discuss the work they’ve done so far and how it matches the stakeholder’s intent.  A good review lets stakeholders test drive the work the team has done so far in as close to a real-world environment as possible.  Only then will the team get the feedback it needs to adapt their plan moving forward to deliver a great product.

So, how do you ensure that you’re making the most of this opportunity?  Here are a few tricks to help you out…

Get the Right Feedback

Believe it or not, many stakeholders are just as uncomfortable in their first review as the team is.  Some mA quintet of vintage hanging light bulbs over a dark brown backgrounday worry about hurting the team’s feelings after a strong effort, or looking silly when they offer their opinion to the team they’ve hired to be the “experts”.  As the facilitator of the review it’s your job to put them at ease when offering their feedback and to help them understand what types of feedback would be the most helpful to you.

First, let the stakeholders know that the entire purpose of this session is to get their feedback so they should not hesitate to give it.  Without their feedback, after all, you won’t know when you need to adjust course.

Second, coach them on the specific types of feedback that would be most helpful.  The type may change depending on the product that you’re building, but some common examples include…

  • Flow – Does the way the user moves through the app make sense?  Is there a better way?
  • Messaging – Is the language the team is using in the app appropriate to the product.  This can be particularly important in products that target a specific business domain, such as healthcare, to ensure that users understand the features as quickly as possible.
  • Superfluousness – Is everything that the team is showing useful and providing value?  Is there anything that could be removed?

Giving stakeholders examples of the specific types of feedback that you’re looking for often makes them more likely to offer it during the session.  And although stakeholders tend to start with the specific types that you prompt them with they’ll rarely constrain themselves to it for long.

Finally, be sure to elicit this feedback in an open ended manner instead of asking them as yes/no questions.  For example, rather than asking if the messaging that you’re using in the app is appropriate, ask if there’s more appropriate message that could be used instead.  Or, if you are seeking more general feedback for a portion of the app, do not simply accept “yes, this looks good”.  Continue digging until you understand why the work looks good and why it is solving the problem at hand so you can replicate that same experience elsewhere in the app.

Plan Ahead

Although we want Sprint Reviews to be a two way conversation rather than a scripted demo that doesn’t mean that we don’t start with a little bit of planning.  Make a list of the key topics you want to get feedback on before the Sprint Review.  These may be new features that have been added to the product, significant enhancements, or particularly nasty bugs that were fixed.  Like Scrum ceremonies, the Sprint Review is a time-boxed meeting so be sure to prioritize the list to tackle the most important topics first.  Once the list is complete, send it to attendees before the review to encourage the right people to attend.  Although a large meeting may be more difficult for you to manage, sharing the topics ahead of time will increase the chances of getting the right people in the room to get the feedback that you need.

As a word of warning, though, be aware that your list of topics does not evolve into a script.  Carefully scripted Sprint Reviews yield little value since they don’t accurately represent the product in use.  Interact with your product casually in the Sprint Review just as you would in a day to day scenario.  This will best convey the actual working state to your stakeholders and will invite their feedback if it doesn’t.  A demonstrable more casual approach to your interaction will also convey to them that their feedback is invited at any time, while a scripted Sprint Review will appear more formal and encourage attendees to hold their feedback until the end of your presentation.  Instead, keep the review casual and informal.  After all, your users won’t be using the product from a script…why should you?

Use Real Data

Just as we ant to interact with the product in a meaningful we’ll want to do so using real data.  All too often we prime products with carefully scrubbed test data that’s been painstakingly curated to contain elements that we’re certain the product can handle.  Unless your users are also painstakingly scrubbing any input or data they feed into your product this gives an inaccurate representation of the state of your product to your stakeholders.

Strive to conduct every Sprint Review with as authentic test data as you have available and use each review to re-confirm with your stakeholders that the data you are showing is representative of the actual data they will be working with.  Unless you explicitly call it out, many stakeholders will assume that you’re aware that your data is not indicative of what the product will be working with in the real world…encourage them to call this out so you can get the test data you need.

Coming Attractions

A common question for new teams embarking on their first review is whether or not they should review unfinished work.  Although, not everything the team creates is worth reviewing along the way, if it’s a significant portion of the product then you should take the opportunity to put it in front of stakeholders as soon as possible.  This “first look” is your chance to confirm that you haven’t completely misunderstood the overarching goal of the feature before you get too far down the wrong path.

Reviewing unfinished work can be a bit tricky, however, especially with stakeholders who are new to an agile process.  If you do decide to review unfinished work be sure to add the caveat that this work is still in progress and that you’re most interested in feedback concerning whether the team has correctly understood the problem and if they’re on the right track with the solution.  As with other pieces of the review, coaching stakeholders on the type of feedback that is most useful here is critical.

It can be helpful to save these topics until the end of the session.  As this work is still new it tends to be the most malleable, therefore it’s of lower priority than work that’s nearer completion.  Also, since less completed work tends to invite more open-ended feedback the natural time box of the Sprint Review can help manage this feedback before it grows out of control.

Inspecting and Adapting

Sprint Reviews are one of the most important ceremonies of the Scrum process as they allow teams to get to the critical feedback that results in a great product.  Without genuine feedback, the team has nothing to adapt to and runs the risk of continuing down the wrong path without an opportunity for correction.  It’s the team’s responsibility to make the review as authentic and productive as possible so they can get the right feedback from their stakeholders and deliver the right product, in return.

Want to learn more about making the most of agile with your team? Check out my course, Agile in the Real World, for tips and techniques for getting the most from agile in your organization.

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


Saving Christmas with Scrum

It’s that time of year when our thoughts turn to the Holidays, Family, and for much of the world…Santa.

I have a soft spot in my heart for this time of year so I never miss the opportunity to catch a classic Christmas movie from my childhood. Not the modern takes on the season, but the classic films where just when times seem the darkest our clay-crafted heroes pull out a Christmas miracle in the last moments before Santa’s sleigh leaves the icy tundra for his trip around the world.

Lately, however, I’ve started to notice a consistently recurring theme in these movies…Santa and his elves are actually saving Christmas with Scrum.

Let’s see how.


Evil User Stories for Modeling Evil Users

If you’re like most Product Owners, you probably have a backlog full of user stories modeling just what you’d like to see your best users do with your product.

But what about your “not so great” users. Not just those who are casual users of your product, or approach it with the lackluster enthusiasm. No, I’m talking about those malevolent users who have set out to do you harm. You have those users, too…you just may not be thinking about them.

These are the users who have only dubious intent towards your company, your product, or even your other users. We call these users our “Evil Users”, and whether you want to think of them or not…they’re your users, too. And they deserve they’re own user stories.

The Choosers versus Users Dilemma

The Choosers versus Users Dilemma

We often talk about our “customer”, they’re at the center of everything we do. But we rarely talk about who our “customer” may actually be. Often, we just assume that our customer is the user of our product…but what if they’re not? It may seem strange to imagine a case where our customer and our user are not the same person, but it happens more often than you may think. But if our customers are not the users of our product then we need to think about who is…and how can we design a product that appeals to them, too.

For example, imagine that we create educational apps for kids. We write these apps to appeal to kids, and we want them to be fun.

Kids are our Users.

So, to appeal to our users we craft colorful environments filled with enticing audio cues and addictive rewards systems. And, as a result, kids love our apps.

But, kids aren’t paying for our apps…their parents are. So, we also need to appeal to the parents. In this scenario, the parents are our Choosers. This means that the app needs to provide more value beyond simply being “fun”. Perhaps it needs to provide educational value, or it simply needs to occupy the kids on a long car ride. Whatever the reason, it ultimately needs to serve the needs of the parents who will actually be the ones to spring for it.

But we can’t forget the kids, if they don’t enjoy the app then they’ll stop playing with it. And if they stop playing with it then they won’t be occupied on long car rides and their parents won’t buy apps from us again.

See what we did there? We’ve created a cycle. Whether it turns out to be virtuous or vicious is up to us.

Enough of This Consumer NonsenseThe Choosers versus Users Dilemma

I know what you’re thinking. Sure, that example is all well and good for consumer apps…but I build business products. I build products for the enterprise…I don’t have to worry about this nonsense. But what if I told you that your Choosers versus Users dilemma is even more pronounced.

Imagine that you’re building a CRM app for the real estate industry. You’ll want the the product to appeal to real estate agents so you’ll want it to be easy to use, lightweight, and provide useful information such as contact info and recent conversations that agents can draw on when interacting with prospective buyers and sellers.
In fact, we could even customize it to their industry to allow agents to quickly access additional information such as each prospect’s desired home type and school district.

It should be everything they could ever want. After all, they are our Users.

However, there’s just one problem. The agents aren’t paying for the product, the brokers who own the brokerages they work for are. And as much as the broker would probably like to make their agents happy, they’re not likely to spring for the cost of a custom CRM system just to put a smile on their faces. So we also need to appeal to them….perhaps even more so. They are our Choosers.

To make the system worthwhile to our Choosers, we’ll need to provide features that meet their unique needs. Many of these will likely stem from their agents’ ability to bring in new business and close sales, but may also include things like understanding the types of properties their agents are transacting (and what types are likely to transact successfully), the number of times their agents are reaching out to prospects, and who the most productive agents are.

So our product needs to include features such as reporting on listing trends, providing insights into communication trends between agents and prospects, and ranking agent profitability.

And, we need to do all of this without sacrificing the agent’s usr experience.

Although our Choosers (brokers) are paying for the product, they’ll derive no value from it unless our Users (agents) find enough value in it for themselves to continue to using it. For example, brokers will find a lot of value in understanding the number of times that an agent reaches out to a prospect, and how that number correlates to the the likelihood of closing a listing. But, an agent won’t log those interactions into the system without getting some value out of that action themselves. This means that in addition to the broker facing feature of correlating interactions to listings, we also need to design an additional agent facing feature that incentivizes them to log their interactions in the first place, such as letting an agent know when it’s been more than two weeks since they reached out to a prospect. Otherwise, agents won’t log their interactions and brokers won’t have anything to report on. And if our Users don’t find enough value to keep using our product, then our Choosers won’t find enough value to continue to pay for it.

So What Do We Do About It?

So, what do we do about this? First need to understand who are Choosers and Users are, and whether or not they’re the same person. Next, we need to determine the incentives for each group to use our product. What do our Users hope to get from our product and what do our Choosers hope to get from it? And finally, we need to understand how the incentives for the Users will create value for the Choosers…or if gaps exist where they don’t. For example, what element of value do Choosers wish to derive that Users are not incentivized to provide? Once we understand where these gaps exist then we can design features and flows to help create the value expected by both.

By keeping this in mind, we can ensure that we create not only a product that our Users will love, but also a product that our Choosers will pay for. And then, everyone will be happy.


This post was originally published on the Front Row Agile blog.

Scrum Board with Firelane

Help! My Team Keeps Missing Releases

Lately, I’ve seen a recurring anti-pattern across several different scrum teams.  The pattern works likes this: a team forecasts a certain number of points per sprint and regularly completes that same number.  If you were to plot the team’s hit rate, or number of points completed over those forecasted, then you would see a fairly straight line at 100%.  The plot below represents a team who, after an erratic first few sprints, has settled down to a particular 100% hit rate.

Hit Rate From the outside, it looks like the team is right on track.  But, as they begin to near the end of the release, everyone starts to realize that the picture isn’t quite as rosy as first thought.  In fact, it becomes obvious that they’re not on track at all to complete all planned work in time for the release, even though they had consistently completed the same number of points they had forecasted.  How does this happen?

Finding the Churn

This can occur when the team regularly accepts new work during the sprint that pushes the planned work to the side.  This work, which often takes the form of high priority bugs or customer issues in production that must be fixed immediately, is estimated and added to the sprint alongside the existing work.  Often, this “high priority” work pushes the previously scheduled work to the side.  At the end of the sprint the team celebrates completing the right number of points…unaware that they actually completed the wrong points.

How can we catch this before we near the end of the release so we can do something about it?  By tracking “point churn”.  Churn is the number of points added to a sprint after it has begun.  Typically, we discourage adding work to an in progress sprint but some teams follow this practice to handle high priority work that must be addressed quickly.  These teams can get early insight into their churn by plotting the number of points added to their sprint alongside their hit rate.

Hit Rate with Point ChurnThe plot to the right adds an additional line along side hit rate to indicate point churn.  The red line, bound to the right axis, represents the number of unplanned points added each sprint.  You can see that although the team maintains its 100% hit rate, more and more points have been added each sprint.  This could be an indicator that although the team is completing the right number of points each sprint…they could actually be completing the wrong points.

If you notice that your hit rate is consistently around 100% but your churn is regularly above 0 then this is can be an indicator that you’re falling behind in your overall release, even though you’re completing the planned number of points each sprint.

A Simpler Approach

But there is another approach.  Rather than go to the effort to track unplanned work that is added to each sprint, an alternative approach is for the team to still accept the unplanned work but not award any points to it.  In this model the work is not added to the sprint, but it is still tackled alongside sprint work.  This approach is easier since it doesn’t require tracking additional points and, if the team reaches the end of the sprint and still has planned work outstanding as a result of being distracted by the unplanned work, then the hit rate for the sprint actually provides a more accurate reflection of how the team is likely to pace for the overall release.

To make new work more visible in this approach you can even add an additional lane to your sprint board for it to flow through.  Seeing this work alongside your planned work, especially with team members assigned to it and Work in Progress limits respected, is a wonderfully effective way to illustrate the impact that new additions can have on your sprint plan.

Scrum Board with Firelane

In the image above, we’ve added an empty row to the bottom of the standard scrum board to allow unplanned work to flow across the board.  These cards are red to indicate their importance.  However, note the WIP limits for each state called out in parenthesis at the top.  Deploying has a WIP limit of 1 meaning, that the unplanned work is currently blocking release of the planned work for the sprint.  Adding an explicit lane to the scrum board can more visibly call out the effect that unplanned work has on a team’s productivity rather than the team simply accepting the work but then quietly falling behind.

Whichever approach you choose, asking whether your team is completing the right points instead of just all of the points can provide early insight into your team’s pace and give you the opportunity to correct your course before its too late.

Want to learn more about planning great releases and keeping your team on track? Check out my course Agile Release Planning on Front Row Agile to learn how.

Top Down Release Planning

Release Planning from the Top Down

Quick…what was the killer feature in your last big release?  If your release is like most then you’ll probably have trouble answering that question.  In fact, if your release is like most it was probably filled with a grab bag of low quality features and a handful of bug fixes.  Sure, there may have been one or two important features in there, but for the most part they were buried amongst an avalanche of noise.

Bottom-Up Release Planning

Bottom Up Release PlanningWe call this type of release planning Bottom Up Release Planning.  It often begins with simply combing the backlog for stories that need to be released and grabbing as many as you can fit in your next release.

Sure, there are advantages to this, most notably that it’s easy to do.  Release planning tends to be simpler and take less time using this method.  In fact, you’ve probably seen these types of releases before, they often begin with a “wishlist” of features that absolutely must be in the next release.

But releases planned in this way tend to feel disjointed and often fail to make an impact on your users since there’s nothing tangible for them to bite on to.

Top-Down Release Planning

Top Down Release PlanningThere’s a better way…and we call it Top Down Release Planning.  This type of release planning occurs when we first define an objective or goal for each release and then select only those backlog items that fit that objective.

This type of release planning can be a bit more involved since we must decide if each item selected fits the objective of the release, but it can lead to much more cohesive releases.  These types of releases often make a bigger impact on users which can resonate with them for a long time to come.

Why Bother?

You may be wondering why if Top-Down Release Planning is even a little more difficult then why we put forth the extra effort?  Well, aside from the advantages I mentioned already, highly cohesive releases tend to be much easier to build a memorable marketing message around.

In addition, focusing the release on a key objective also allows us to make greater strides in trying to solve a sticky problem that our users are currently facing.  If we can solve a particular pain point—and build a great message around that solution—then we’re much more likely to deliver a release that will resonate with our users.

Want to Know More?

I cover Top-Down Release Planning in more depth in my course new course Agile Release Planning, available on Front Row Agile.  If you’ve ever struggled with building large-scale projects using agile techniques, or have just wondered how planning works in an agile framework then this course is a great fit.

In addition to Top-Down Release Planning I also cover

  • How traditional planning and agile planning differ, and how to start adopting a more agile mindset.
  • How to develop a vision for your projects, including creating a vision board and learning proven techniques to cultivate focused concepts.
  • Strategies for building a roadmap to your goal and important things to consider in the first release and all future releases.
  • Ways to plan the release, including how to develop a release grid and prioritize features well.
  • How to build the product backlog by looking through the lens of DEEP and constructing effective sprint plans now and far into the future of your agile development.
  • Methods to keep plans on track when things just don’t go as you expect.

This course is regularly $50 but for a limited time readers of this blog can get all of this content for just $40 by using the discount code PLANBETTER at checkout.  That’s an additional 20% off just for following this blog.

Just enter the code above to claim your discount and be on your way to planning great releases and I’ll see you in the course!


Where Afternoon Standups Go Wrong

Most teams are familiar with the morning standup, or the classic scrum ritual that gives teams the opportunity to sync up and plan their work for the day.  For many teams, the morning standup is the bread and butter of their scrum process.

But every once in a awhile a team tries to move their standup to the afternoon.  The reasons always sound legitimate:

“Not everyone gets here at the same time, so we’ll just hold our standup in the afternoon.  That way everyone can attend.”


“Mornings are when we’re most productive…we don’t want to interrupt that with another meeting.  Let’s just have the standup in the afternoon.”

As valid as these reasons sound afternoon standups have a tendency to be less useful than morning standups, but the reasons why aren’t always clear.  Let’s take a look at why.

The Ritual Suffers

The standup ritual suffersMorning standups create a nice ritual for your team.  Everyone trickles by 9 o’clock, checks their email, and gets their morning cup of joe.  But, at 9:30 everyone filters into the team room and it’s time for the standup.  After a quick standup the team starts their day for real.  The 9:30 standup is the signal for the day to start.

On the other hand, even though afternoon standups are still scheduled at the same time every they are much less likely to start at the same time every day.  This is because by the afternoon the day is much more likely to have gone awry.  Maybe tasks have taken longer than expected so not everyone is ready.  Perhaps a fire has much of the team too distracted to make the original time.  Or, even if all of the team is available, maybe other meetings outside of the team have ran long and the team’s normal meeting space isn’t available.  Now the team has to hustle to find a space that can accommodate them for their already late standup.

Standups Last Longer

No one likes a long standup.  In fact, one of the most common complaints from new scrum teams is

“Our standups always last at least 45 minutes.”

All standups are susceptible to this but afternoon standups are particularly so.

Standups last longerThink of how you feel in the morning:  You’re energized for the day, you’ve had a fresh cup of coffee, and you’re ready to tackle that sticky problem from yesterday.

Now, think of how you usually feel in the afternoon:  You’ve just had lunch.  You’ve already been at work for 5 hours, and all you want is a reason to sit down and take a break for a bit.  The afternoon standup is that reason.

And, once everyone has sat down, the standup begins to drag.

Your New Status Meeting

But, the most insidious problem of all with afternoon standups is much more subtle.

Standups should have two goals…

  1. Identify blockers so they can be brought to light and removed.
  2. Allow the team to sync up and plan their work for the day.

Nowhere in that list is a goal for the team to report the status of their current work in progress.  That’s not the purpose of the standup…that’s the purpose of the scrum board.

Morning standups are very conducive to these goals since they encourage the team to identify blockers early in the day and to synchronize the day’s work before they get started on the wrong path.

But afternoon standups share neither of these traits.  Although the same blockers might exist in the afternoon as they did in the morning, team members are less likely to bring them to light since they may mistakenly believe they’re close to solving them.  Even if they do, the other team members are likely too deep into their own tasks to volunteer much help.  In addition, since the individual team members have already started their work for the day there’s no opportunity to synchronize the work as a team…everything has already begun.

With both of these options off of the table only one thing is left to talk about in an afternoon standup…status.  When held in the afternoon the focus of the standup naturally shifts to what each team member has accomplished so far that day.  Rather than providing the opportunity for the team to clear their own way and plan the day’s work ahead, the standup simply devolves into yet another status meeting.

Try It and See

The differences between afternoon and morning standups are subtle but the results can vary dramatically.  If your team is currently using afternoon standups and something just doesn’t feel quite right then give morning standups a try.  The difference may surprise you.

Want to see more about how to make textbook agile work on real teams? 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.

Load More
10 of 27