Jeremy Jarrell

Agile Made Simple

Tag: agile

What, When, How: The 3 Levels of Strategic Agile Planning

When we think of agile, we often think of quick reactionary planning to the realities of a project as it unfolds. For that reason, most discussions of agile planning focus…

When we think of agile, we often think of quick reactionary planning to the realities of a project as it unfolds.

For that reason, most discussions of agile planning focus on the short term. Our teams plan and synchronize at the daily level using recurring morning stand-ups. And, for those teams practicing Scrum, we plan at the iteration level using recurring sprint planning meetings.

Both of these practices are great for keeping a team on the same page tactically, but what about strategically?

Luckily, there are some simple techniques for aligning your team strategically as well as for helping them to think beyond the sprint.

Strategic agile planning comes down to three simple questions:

  1. What are we doing?
  2. When do we need it done?
  3. How are we going to get there?

The key is to remember that the answers to these questions will likely change as the development of your product progresses. But, by taking an iterative approach, you can keep your team on track to ensure that you deliver the right product at the right time.

So let’s take a look at these three questions in turn to see how each propels you down the path of creating a great product.

What are we building?

The most important decision that you need to make as a team is what are you building? But the question is often more complicated than that. Instead, the deeper question is what need should your product be solving.

One of the best ways to answer this question is with a visioning canvas. There are many variations of the canvas available, including the well-known Lean Canvas, but my personal favorite is Roman Pichler's Product Vision Board.

Product Vision Board

The example that you see here is how a vision board for a streaming music service, named Ostinato, may look. Notice that the vision board starts at a higher level than the specific needs of the product and instead focuses on the overarching need that the product is trying to fulfill.

Some of the characteristics that you’ll discuss when creating a vision board include defining the specific user needs or market opportunity that the product is trying to fill, identifying the core user base that you’re targeting with the product, identifying potential competitors who may already be in the market, and discussing how the product will generate revenue.

The outcome of the visioning exercise is intentionally vague, as it is not used for planning the execution of the product, but rather to build alignment across the team of what the ultimate result of building the product should be.

Some teams refer to this exercise as “setting their North Star,” since the result is a guiding direction on where the team is heading without dictating the specific steps of how to get there.

Although your product vision is unlikely to change daily, you should expect it to evolve as you learn more about your target users, potential competitors and where your product can most effectively fit in the market.

For that reason, plan to repeat this exercise periodically to reevaluate core assumptions that you may be making about the competitive landscape, as well as to take a fresh look to help spot opportunities for growth.

To do this, a good rule of thumb is to repeat this exercise annually, though newer and more rapidly evolving products may benefit from a slightly more frequent cadence.

To get the full benefit from this session, you should expect it to be attended by the product’s executive sponsors, the relevant product management team and key technical representation such as the product architect.

Although members of the product delivery team such as engineers, testers and designers may benefit as well, be wary of growing the session too large and remember that the resulting vision may be more effectively conveyed to these team members by the architect and product manager after it’s complete.

When does it need to be done?

Now that you know what you’re building, the next question that you need to solve is when does it need to be done?

But, remember that you’re running an agile project, so rather than waiting until the entire project is complete, you’ll want to deliver in small increments to get as much feedback as possible along the way.

This combination of answering both when you want to deliver your overall product as well as how and when you want to make small incremental deliveries along the way will become your product roadmap.

Product roadmaps are high-level plans that show your product’s intended evolution over the next few releases. They show, at a high level, the overall strategic direction that you plan to take your product, as well as the different guide points along the way that will help get you there.

If the idea of long-term planning fills you with fear as images of Gantt charts dance in your head, don’t worry…there are better alternatives that we’ll discuss here.

Agile product roadmapping has become a hot topic in the past few years with several very nice tools coming on to the market. However, my favorite is still the free Goal Oriented Roadmap, or GO Roadmap, which was created by the very same Roman Pichler that I mentioned previously.

What sets the GO Roadmap apart is that rather than focusing on the features required for each release, it instead focuses on the goal of each release. This approach not only frees you from thinking about implementation details and sequencing too early, but it also leaves the responsibility to define the specific features of each release until a time when you know more about them.

GO Product RoadmapIn the example here, we’ve created a GO Roadmap for our streaming music service, Ostinato.  Notice that any features defined here are very high level and intentionally lack specific detail.

Forcing your team to define features too early often creates an unrealistic impression of certainty for your product and can even lock you into a less than optimal feature set too early.

Instead, thinking at a higher level about the overarching goals that each release should meet will free you to think strategically not only about the impact of each release, but also how the entire release cycle for the product fits together as a whole.

While your roadmap won’t change frequently, expect to revisit it more often than your product vision. If you’re revisiting your product vision once a year, then revisiting your roadmap quarterly would be a good rule of thumb.

To be effective, this session should include key technical personnel who can advise you to any technical dependencies or limitations that may affect the goals you’re laying out.

During each roadmapping session, your team should be focusing primarily on the release that’s immediately upcoming. While you’ll still want to leave time to discuss subsequent releases, expect that they will be more vaguely defined and more volatile as they’re farther out on the horizon.

GO Product RoadmapAs a rule of thumb, you should be able to draw a diagonal line from the last objective of the nearest release to the last objective of the farthest release showing how each release becomes progressively less defined as you move toward the horizon.

How are we going to do it?

The final piece of strategic planning is to lay out a plan for how your team will approach the next release. This is done with a tool that’s similar to the GO Roadmap we discussed previously, but with a more fine-grained feel.

While this release plan contains much of the same information found in your roadmap, it also adds lower level information such as a prioritized list features that will be tackled in each release.

Release PlanThese features can be prioritized by whatever means is the most comfortable for your team … as long as they are prioritized. I’ll often use the MoSCoW prioritization technique, which has the advantage that it allows for items to be explicitly removed from a release.

Expect to revisit your release plan after each minor release, which should occur more frequently than the major releases detailed on your roadmap. For example, if you follow a release cadence of a major release at the end of each quarter with minor releases at the end of each subsequent month, then you should expect to revisit your roadmap quarterly and your release plan monthly.  The goal is to create a plan that represents what your team is currently working towards as well as to give you an idea of what lies in the future.

Ideally, your entire team should be involved in this meeting as they will be the ones who will deliver the work inside of each release.

And, as with the roadmapping discussion, you should be focused primarily on the next upcoming release and expect subsequent releases to be progressively less defined as you move out to the horizon.

In fact, the guiding principle of drawing a horizontal line from the last feature in the next release to the last feature in the farthest release works just as well for release plans as it does for roadmaps.

Seeing the big picture

Strategic agile planning is as much of an iterative exercise as anything else that we do in an agile context. The secret is to realize that no matter how confident you feel in your overall vision today, it’s very likely to change as your product grows and your market evolves around it.

By taking an agile approach to your strategic planning, you can significantly increase the odds that the product you deliver will make the impact that you envision.

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

No Comments on What, When, How: The 3 Levels of Strategic Agile Planning

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…

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.

No Comments on Get More out of Your Sprint Review

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.

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 things 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 recurring theme in these movies…Santa and his elves are actually saving Christmas with Scrum.

Let's see how.

Real Elves Generalize

santa-painting-toy-planeLook at Santa’s Workshop and you’ll no doubt see lines of long tables filled with happy elves working away.  The elves are, of course, happy and productive.  But if you look closely you’ll also notice something else.  As each toy completes it journey down the table it passes by carpentry elves, painter elves, and even gift-wrapping elves…each of whom contribute to the product in their own special way.  A quick glance at the busy workshop will tell us two things:

  1. Elves specialize.
  2. Elves organize into co-located, cross-functional teams.

Each elf has a chosen speciality that they excel at more than any other elf at the North Pole.  And the organizational structure of Santa’s Workshop allows each elf to pursue their chosen passion and use it to contribute to the toys in their very own way.  But, as narrow as each elf’s chosen specialization may be, rarely are these specializations compartmentalized.  Rather than stashing each group of elves into their own corner of the workshop, each group works together at long tables where the different specializations can collaborate.  This lets each elf communicate more readily and shortens the feedback loop between each discipline as the toys move between them.

Because, at the end of the day, the elves know that a toy is not a complete until they’ve all had their chance to contribute.

There's No “I” in Elf

Even with each elf’s chosen specialization when push comes to shove and Jolly Old St Nick’s annual run is threatened, the elves never fail to pull together in the face of adversity.  Whatever the crisis at hand, all elves step in to help in whatever way they can regardless of the task that is asked of

This means that every elf drops their preconceived notion of what they should be working on and lends a hand wherever they can be most useful.  Well, almost every elf.

Painter elves dive into wrapping gifts, baking elves load the sleigh, and carpentry elves drop everything they’re doing to prep and feed the reindeer.  Whatever an elf’s specialization is, when the cookies are down all that matters is getting those toys out the door.

Christmas Doesn’t Come Late

No matter how many toys are finished, how many boxes are wrapped, or how much of the sleigh is packed…Christmas comes on December 25th or not at all.  Real elves know that no matter what happens, they must ship against a hard deadline because Christmas Can Not Move.

So how do they ensure that every Christmas is a success when faced with a hard deadline?  By building the most important toys first.  Elves know that they have only a limited amount of time to create the toys for that perfect Christmas so they focus on what matters.  This means that when all of the letters to Santa start pouring in the elves focus on what’s top on each list and only work down the list once the most important toys are made.  Once December 24th rolls around what’s done is shipped and what isn’t…well, doesn’t. 

The elves take this approach because they know that even if 15 toys were originally on his list that Little Johnny really isn’t going notice if the last two toys aren’t waiting under his tree on Christmas morning.  But he will notice, however, if Christmas morning doesn’t come until December 28th.  Even though each and every one of those toys seemed incredibly important at the time Little Johnny made his list, the elves know that what matters the most is that Christmas comes on time.

Putting a Bow On It

christmas-presentSanta and his elves may be one of the most effective delivery teams ever created.  Despite deep specializations across the elf corps, each group collaborates well and prioritizes ruthlessly to ship great toys on time each and every year.  There’s a lot to be learned from watching how groups like this work together so the next time your favorite Christmas movie is on, grab a hot cup of cocoa, curl on your couch, and see what you can learn.

Want to learn more about how to help your team get the most out of Scrum? Check out my course series from Pluralsight, Using the Scrum Framework, for tips on helping Scrum Masters be more effective in their role.

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

No Comments on Saving Christmas with Scrum

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…

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!

Comments Off on Release Planning from the Top Down

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…

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

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

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

No Comments on Where Afternoon Standups Go Wrong

Choosing the Best Scrum Master

Choosing the best Scrum Master for your team is an important decision. But how do you know who is the best fit? Luckily there’s a way.

Thanks to Kim Hardy for a great conversation which was the original inspiration for this post.  See more of Kim's great work here.

When teams are first adopting scrum one the first questions they ask is “Who should be our Scrum Master.

Often teams take the path of least resistance saying things like “Steve is the Tech Lead, he can do it” or “Joe wants to try it…let's let him do it”.  But choosing a Scrum Master is not something that should be taken lightly.

The Scrum Master is responsible for shepherding the Scrum process for a team.  Not only are they responsible for the execution of the process, i.e., setting up Daily Standups or running Sprint Planning meetings, but they are also responsible for helping the team stick to the process when things get tough.  This means that this is a very important role for the team…especially a new team.

A Mix of Skills

When I talk with managers about choosing their first Scrum Master, I inevitably draw the same diagram on the whiteboard…

Scrum Master Skills

On the left side of the diagram we see a few individuals who really want to try the role of Scrum Master.  Perhaps they have aspirations to management and see the role as a first step, or the adoption of Scrum is new and exciting and they want to be a part of it.  Whatever the reason, they want to be a Scrum Master.

On the other side of the diagram we see those individuals who just seem to have a natural knack for what the Scrum Master role requires.  They enjoy seeing the team succeed as a whole and want to do everything they can to help them do so.  They have the political savvy in the organization to head off outside interruptions so the team doesn't lose focus.  And, most importantly, the team respects them.  These are the individuals that when they speak, the rest of the team looks up from their laptops to listen. These are the exact kind of people that you want facilitating the Scrum process.

If we're lucky, we'll have both types of individuals on a team.  But, if we're really lucky, we'll have that rare individual that falls into both groups:  someone who wants to be a Scrum Master and has the knack to be successful at it.

Those who want to serve this role but do not have the natural ability may not be effective, especially in that tumultuous time when a team is just getting started.  On the other hand, those who have innate ability but aren't truly interested in being a Scrum Master won't give the role the attention that it needs, causing the process to falter as it tries to take hold.

How to Choose

While we'd love to find and individual who has both the desire and the natural ability, the reality of the situation is that few will have both.  Instead, we're forced to choose.  Do we choose the individual who wants to be a Scrum Master but does not yet have the skills, or do we choose the individual with an innate ability but no interest.

When given the option, we should always err on the side of those with want.  If someone has the passion for their new role but is simply lacking skills then, with time, those skills can be taught.  However, if someone has the skills but not the desire, then no amount of time will fill that gap.

Passion Trumps Skill

Choosing the first Scrum Master for your team is a very important decision and not one that should be taken lightly.  Ideally you can find someone with both the desire and natural ability to fill the role, but failing that, someone with the passion and a willingness to learn will always serve the role best in the long term

Want to see more about how to choose the Scrum Master that's right for your team? Check out my course series, Using the Scrum Framework, for tips and techniques for choosing the Scrum Master that's most likely to be successful.

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

Comments Off on Choosing the Best Scrum Master

Getting the Most out of Your Scrum of Scrums

One of the first hurdles you will run into when scaling beyond a single Scrum team is staying in sync. Luckily there’s a solution: the Scrum of Scrums.

One of the first hurdles that an organization runs into when scaling beyond a single Scrum team is how to keep those teams in sync.  Luckily there's a solution: the Scrum of Scrums.

On the surface, the Scrum of Scrums looks a lot like a regular team Scrum.  In fact, it's even still focused on the same three questions…

  1. What did I do yesterday?
  2. What am I doing today?
  3. What's in my way?

Similarities aside, however, if you want to get the most out of your Scrum of Scrums you'll need a few simple tricks.

Improving the Scrum of ScrumsScrum of Scrums

While a regular team Scrum is intended to coordinate the work that individuals on a single team will tackle for the day, a Scrum of Scrums is intended to coordinate the work for a group of teams.  This difference leads us to a few slight differences in how we can best conduct our Scrum of Scrums.

One Person per Team

As mentioned before, a Scrum of Scrums is intended to be held between groups of teams rather than individuals on a single team.  But rather than ask entire teams to attend this meeting, we instead ask only one individual from each team to attend the Scrum of Scrums on their team's behalf.

Typically this person is the Scrum Master as they tend to have the best overarching view of the team's work.  Also, since Scrum of Scrums are more likely to veer into process-related discussions the Scrum Master is best suited to handle those topics.

Keep Them High Level

Scrum of ScrumsSince Scrum of Scrums are actually held between teams rather than individuals the focus of the meeting is much more on the direction of each team as a whole and how it relates to other teams.  As a result, the updates given by each team's representative tend to be at a much higher level than you may hear in an individual team's Scrum.

A good rule of thumb to know if your updates are occurring at the right level is listen for a good mix of “we” language.  Put another way, are the Scrum of Scrums representatives focusing mainly on the work of each individual on the team or are they rolling up these updates into a broader updates.  Ideally you should hear updates similar to “We're just wrapping up the UI for the new security questions screen and will be moving on to incorporating the security questions in the password reset workflow tomorrow“.  If, instead,  the updates sound more like “Jimmy is putting the finishing touches on the security question screen and Joseph is tying it to the backend code so Sarah can finish testing it.  Then, Jimmy will move on to integrating it into the password reset screenflow so Joseph can incorporate it in the backend” then your updates are too detailed for the Scrum of Scrums venue.

Keeping the updates at a high level will make it easier for the other attendees to follow as well as to understand how this work fits with the work of their own team.

Hold Less Frequently

Scrum of ScrumsSince Scrum of Scrums updates tend to be at a higher level than an individual team's Scrum you'll probably find that you need to hold them much less frequently than the daily rhythm of the team Scrum.  This is because, at this level of detail, the information may not change often enough to warrant getting everyone together on a daily basis.  However, this may not always be the case.  For example, you may find benefit in holding this meeting daily shortly after a project has kicked off or as it nears a major milestone and the pace of change quickens.  As with everything else in Scrum, you'll need to experiment to find out what works best for your team…and then expect that to change as time goes on.

As a result of this, expect the Scrum of Scrums meetings to run a bit longer than a team Scrum.  While there is no set timebox, as there is with a team Scrum, expect these meetings to regularly last 30 minutes if not a bit more depending on the number of teams involved.  This is a result of the difficulty of coordinating the work of entire teams who are often working in different areas of the codebase as compared to individuals on the same team who often work on related features and code.  However, just as with a team Scrum, you should still strive to make these meetings as efficient as possible.

The Most Powerful Tool

The Scrum of Scrums is the most powerful tool in your toolbox when it comes time to scale Scrum to multiple teams.  However, much like the team Scrum, the simple structure of the meeting can be deceptive.  While it's easy to begin holding the Scrum of Scrums meetings, only by keeping the previous points in mind will you and your teams get the most benefit from this powerful practice.

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.

Comments Off on Getting the Most out of Your Scrum of Scrums

Themes versus Epics in 2 Minutes

The difference between themes and epics are a common sticking point for many teams first diving in to user stories. Not only can descriptions of both topics often be vague, but the difference is often muddled further by many project management tools that use the two terms interchangeably. However, the difference doesn’t have to be so hard.

The difference between themes versus epics are a common sticking point for many teams first diving in to user stories.  Not only can descriptions of both topics often be vague, but the difference is often muddled further by many project management tools that use the two terms interchangeably.  However, the difference doesn't have to be so hard.


Themes are a group of related user stories.  Often these stories can be comprised of tasks that may have been too big to fit into a single user story, so they were split into multiples.  An example may be a set of stories dedicated to improve the performance of an app…

User Stories are often represented by sticky notes

  • As a customer, I want to view my last 100 transactions in under 2 seconds, so I can quickly spot inconsistencies.
  • As a loan officer, I want to retrieve a candidate's credit history in under 30 seconds, so I can discuss lending discussions while the candidate is still in my office.


Epics are a group of related user stories, which all contribute to a common goal.  In nearly all cases these underlying user stories have all been split out of the original epic to allow the team to tackle them over multiple sprints.  As an example, imagine that we've broken the process which allows a customer to analyze the spending trends in their checking account into several stories all comprising the same epic of “As a customer, I'd like to view my spending trends, so I can make smarter decisions.”  The underlying stories may look like this…

  • As a customer, I want to import transactions into my checking account, so they can be analyzed for spending trends.
  • As a customer, I want to view the categorical spending trends from my checking account, so I can see where I tend to spend the most money.

User Stories are often represented by sticky notesAt first glance, the stories that make up the epic may seem very similar to those in the theme.  Each are clearly defined, bite-sized chunks of work.  Each contribute to a larger goal of the system.  However, there's one crucial difference.

While the stories that comprise the theme are not interrelated and could easily be delivered independently from one another, the stories that comprise the epic provide no value until all are delivered.

Diving Deeper

Each of the performance tuning stories in our theme are valuable, and either would likely be appreciated by our users.  However, we could easily deliver the story to improve the performance of viewing recent transactions in one release, and the story to reduce the time to retrieve a candidate's credit score in another. The stories, while related, have no dependency on one another and could easily be delivered independently and in any order.

Contrast this, however, to the stories focused on importing and analyzing transactions from a customer's checking account.  In this case, ordering is important as we will not be able to view a customer's spending trends until we've imported the transactions from their checking account.  However, the ability to simply import transactions provides no real value to a user by itself.  This means that we cannot truly release this story until the second story, to view categorical trends, is completed as well.

The stories that comprise a theme can easily be delivered independent of one another, while the stories that comprise an epic provide no real value until the overarching epic is delivered in its entirety.

Want to learn even more ways to slice your user stories so your team can start working with them immediately? Check out my course, Creating Effective User Stories, for easy techniques that will have you writing better user stories today.

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

Comments Off on Themes versus Epics in 2 Minutes

Turning Your Standups on Their Head

The daily standup is one of the most powerful tools in the scrum toolbox, so powerful in fact that when teams move beyond scrum they often still retain the standup as one of their core practices. But, there’s still room for improvement.

Few teams doubt the value of the daily standup.  Three simple questions, each designed to help the team plan their next day's work
based on the current situation.

  1. What did I do yesterday?
  2. What am I doing today?
  3. What's in my way?

Paper DollsThe daily standup is one of the most powerful tools in the scrum toolbox, so powerful in fact that when teams move beyond scrum they often still retain the standup as one of their core practices. But what's the real goal of this meeting?  It's to identify areas where the team is blocked so we can get those blockers out of the way.  If this is the case, though, then why do we save blockers until end of each person's update when the team has already started to shift their focus to the next person in line?  In fact, not only has the team started shift their attention, but the person giving the update has often already started to check out!  How many times have you heard a someone simply mumble something about “and no blockers.” when you know for a fact they do?  This is because most people are ready to be done with their update by the last question and just want to move on.  Unfortunately though, they've just skipped the most important part.

Meet the Reverse Standup

The Reverse Standup takes the same three questions as the classic standup and turns them on their head.  The result is that the most important questions are tackled first.

  1. What's in my way?
  2. What am I doing today?
  3. What did I do yesterday?

What's in my way?

This is our classic “what's blocking me question”, and the bread-and-butter of the daily standup.  Think about it like this, if someone is blocked then the next question is irrelevant.  Whatever is blocking your team has to be solved before we can move forward, so we need to start there.

What am I doing today?

Assuming nothing is blocking a team member this question becomes the most important.  This is the information the team uses to build their plan for the day so we tackle it immediately after any blockers.

What did I do yesterday?

Forget for a moment that the classic standup leads off with this question.  Instead think back to your last standup and remember what each person answered for this question.  Now remind yourself that the daily standup is a planning meeting, not a status meeting.  Keeping that in mind, think about how useful knowing what each person did yesterday was to your planning?  Not very, eh? It's not that what someone did yesterday isn't important, its just that it's usually not that useful as input to to creating our plan for today.

Sure there are exceptions: Sally resolved an issue with the test deployment that had been blocking John for the past 2 days, or Steve finished the icon set that Sally had been waiting add to her own feature.  But these are the exceptions rather than the rule.  The vast majority of the time “what I did yesterday” just doesn't impact what we're doing today. And, when it does, it's already reflected on the scrum board.

So what happens to this question?  Well, once a team finds the flow of a Reverse Standup this question starts to feel less relevant.  As a result, many teams eventually make this question optional which results in it being skipped during most standups.  The exception is that the question is only answered when it's relevant to moving the team forward today.

Give it a Try

If you're finding blockers aren't being called out as often as they should, or if you'd just like to breathe some life into a stale standup, give the Reverse Standup a try.  You may be surprised with the result

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.

Comments Off on Turning Your Standups on Their Head

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