Jeremy Jarrell

Agile Made Simple

Tag: scrum

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

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

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

Stop Estimating Spikes!

The most common question that teams face when first working with spikes is whether or not to estimate these stories. Luckily the answer is simple…don’t.

The whole point of spikes is to help us learn more about stories that we don’t yet know enough about to estimate well. This very unknown nature means that estimating the spike itself would be fruitless. Instead, our goal is to learn enough during the spike that we can estimate the associated story in an upcoming sprint.

One of the most common question that teams face when first working with user stories is how to best approach estimating spikes.  Luckily the answer is simple…don't.

The whole point of spikes is to help us learn more about stories that we don't yet know enough about to estimate well.  This very unknown nature means that estimating the spike itself would be fruitless.  Instead, our goal is to learn enough during the spike that we can estimate the associated story in an upcoming sprint.

Do Spikes Still Count Towards Our Velocity?

railroad-spikeWhether a spike still counts towards a team's velocity is a hotly debated question.  After all, if a spike isn't estimated then how could it?  To answer this question we must first understand that although we don't estimate spikes…we do timebox them.

Timeboxing Spikes

Each of our spikes should be timeboxed, in story points, and that timebox should contribute to the team's velocity for that sprint.  For example, if we decide that a certain spike should be timeboxed to 3 points then we count that 3 points towards the team's forecasted velocity for that sprint.  This is important because if you're tracking historical velocity to help better predict what the team can accomplish in future sprints, then deducting the time spent on those spikes will skew your velocity which unnecessarily complicates those measurements.

We do this since while a spike may not produce something as tangible as a feature story for a sprint, it may produce value which ultimately benefits the customer…assuming it ties directly to a slated story.  In this way, a spike contributes business value in the same way that the first iteration of a particular UX design contributes business value…i.e., it provides useful knowledge that helps improve later versions of the feature, even if its only to define the path that we shouldn't take.

Knowing What You Want

Whats in the boxHowever, to timebox a spike correctly we need to first know what we want out of it.  This means that we need to define the end goal…i.e, what we want to have learned by the end of the spike.  A great exercise for doing this is to simply ask “Why can't we simply estimate the associated story today?”  The answers to this question then become the spike's acceptance criteria.  As an example, the acceptance criteria for a spike to learn more about the implementation of a new feature may include criteria such as…

  • We have an understanding of the components necessary to build the feature
  • We have an understanding of the impact on existing code
  • We have an understanding of the dependencies necessary to complete the feature

Is this criteria a big vague?  Sure.  But it at least gives you a direction to better understand what you need to have learned during the sprint and the direction that you should be going.

Keeping Spikes Short

Although we are timeboxing our spikes and including them in the sprint, they do have an impact on our overall velocity.  Therefore it's to our benefit to prefer shorter spikes whenever possible.  Not only does this minimize the impact of the timeboxed points alongside the “actual” points of a sprint, but keeping our spikes short also discourages open-ended “exploratory” spikes which may not yield tangible value at the end.

On the contrary, shorter spikes force us to keep them well-defined, which means that they're more likely to produce something of meaningful value to both the team and the customer.

Spikes are an incredibly helpful tool to have our scrum toolbox.  Assigning meaningful timeboxes to them not only help us better understand the impact that they have on our sprint, but it also forces us to better define our desired end result which dramatically improves our odds of getting there.

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 Stop Estimating Spikes!

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

Meet the Timestamp Sticky

It’s no secret that teams who track their progress using physical tools rather than electronic have have a much higher rate of success, but how do you handle of the fear of sticky notes falling off the wall?

Card wallIt’s no secret that teams who track their progress using physical tools rather than electronic have have a much higher rate of success.  This is because low-
fidelity tools such as sticky notes and index cards are much easier to fit into a team’s natural flow, rather than forcing the team into the constraints defined by an
electronic tool.  In addition, the more tangible and visible nature of physical items helps the team feel more involved in the flow of the project and, as a result, more vested in the outcome.  However, despite all of these advantages, one of the most common push backs to the idea of tracking progress using physical cards is “What happens when they fall off?”.

Despite the fact that this question is so common, the reality is that this concern is largely unfounded.  In fact, if teams are working in a reasonable sprint length then the lifetime of your average sticky note will far outlast the lifetime of your average story.  But how do you convince people that this is the case?

timestamp-stickyMeet the Timestamp Sticky.  Simply take a regular sticky note, write the current date on it, and stick it somewhere on the wall.  Then, whenever someone expresses concern about sticky notes falling off, just point to your timestamp sticky as an example of how long a sticky note can stay on the wall.

This is a great way to alleviate the fear of the sticky note simply falling off of the wall, and help combat the pressure to move to electronic tools.

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 Meet the Timestamp Sticky

Stories versus Themes versus Epics

When a new team is just beginning to adopt Scrum the difference between stories, themes, and epics always seem to be a source of some confusion. In particular, where stories end and epics begin tends to be a particular sticking point. In this article, we’ll take a closer look at each artifact to get a better understanding of the subtle differences between them so we can better communicate to our teams when each is appropriate for the work at hand.

This article was originally published here by ScrumAlliance.com, in March 2014.

When a new team is just beginning to adopt Scrum the difference between stories, themes, and epics always seem to be a source of some confusion.  In particular, where stories end and epics begin tends to be a particular sticking point.  In this article, we’ll take a closer look at each artifact to get a better understanding of the subtle differences between them so we can better communicate to our teams when each is appropriate for the work at hand.

Let’s start with a few definitions…

Stories

StoryA story is a self-contained unit of work agreed upon by the developers and the stakeholders.  Stories are the heart of Scrum, and the building blocks of your sprint.  An example of a story may be… 

“As a salesperson, I’d like to set my password, so I can log into the system.“

Themes

Themes may be thought of as groups of related stories.  Often the stories all contribute to a common goal or are related in some obvious way…such as all focusing on a single customer.  However, while some stories in a theme may be dependent on one another, they do not need to encapsulate a specific workflow or be delivered together.

Epics

Epics resemble themes in the sense that they are made up of multiple stories.  They may also resemble stories in the sense that , at first, many appear to simply be a ‘big story’.  As opposed to a theme, however, these stories often comprise a complete workflow for a user.

But there’s an even more important difference between themes and epics.  While the stories that comprise an epic may be completed independently, their business value isn’t realized until the entire epic is complete.  This means that it rarely makes sense to deliver an epic until all of the underlying stories are complete.  In contrast, while stories comprising a theme are related each is still independent enough to be delivered separately and still provide some measurable sense of business value.

Why stories, themes and epics?

When faced with the confusion between stories, themes, and epics many budding agilistas wonder why we wouldn’t simply choose stories in every case.  One of the most common reasons is often the sheer size of some stories.

Stories that at first seem daunting often need only to be broken down further into smaller stories that can be estimated individually.  To get a handle on how the story can be broken down, try asking your team some of the following questions…

  • Why does the story seem so difficult to estimate?
  • Are the individual tasks that make up the story too complex?
  • Does the story have dependencies on other work that has yet to be completed, or that must be completed by a third party?
  • Are there technical or business unknowns in the story that are still unclear?

Once you have a feel for where the hesitation originates from you can take another pass at breaking down the story in the context of the questions above.

An example of an epic

Now that we have a feel for ways in which larger stories can be broken down further, let’s take another look at our earlier example of a story to see if it fits this description.

“As a salesperson, I’d like to set my password, so I can log into the system.“

While at first this may seem like a fairly innocuous story, there’s actually a bit to unpack here.  For example, a few questions immediately spring to mind…

  1. How does the salesperson first access the system to set their password if their account isn’t fully setup?
  2. Do password strength requirements exist that will need to be enforced?

In order to better tackle some of these unknowns the story above may be better served as an epic comprised of the following stories…

  1. “As an Administrator, I’d like to send an email to a new salesperson containing a tokenized access link, so they may temporarily access the system in order to set their password.”
  2. “As a Salesperson, I’d like to edit my profile, so I may set my password.”
  3. “As an Administrator, I’d like to ensure that all salespeople’s passwords meet corporate strength requirements, so I can harden access to the system.”

There are a few things we may immediately notice about the stories above.  First, when broken down each individual story paints a deeper picture of what’s actually happening in the system than the original epic ever could.  In the least, this may highlight new interactions with the existing system that may increase or decrease the estimates.  For example, in story 1 a developer may respond with “we already have a system in place that allows us to send emails” or “our existing email system only allows for plain-text messages without links in the email.”  While neither of these situations may have been obvious prior, either may significantly increase or decrease the estimate.

Two yellow sticky note reminders on a white background

Next, the stories have an implied workflow to them.  A salesperson cannot access the system to update their password until they’ve received their initial email.  In addition, the salesperson should not change their password before we can enforce its strength.  This workflow has an obvious beginning, an obvious end, as well as a few steps in the middle.  For this reason it can often be helpful to think of epics as a Story Arc.

Finally, although the stories comprising an epic may be completed individually, they provide no measurable business value on their own.  Shipping the functionality to email new salespeople provides no value if the profile page or the new password functionality doesn’t yet exist.  By the same token, allowing the user to set their password without enforcing corporate strength requirements will result in many passwords being invalidated as soon as those requirements are in place.

Creating epics from stories that are just too big

A related rule of thumb is to automatically further break down any story that is estimated above a certain threshold.  A good starting point for this threshold may be where your team has historically tended to become inaccurate with their estimates.

For example, imagine that your team’s velocity tends to be relatively predictable when estimating stories of sizes 1, 2, or 3 points but doesn’t have a great track record with stories sized at 5 points and above.  If this is the case, then any story estimated at 5 points or above should automatically be broken down further before it's added to a sprint.

In addition, breaking a large story into smaller stories has the added advantage that multiple smaller stories will travel the sprint board faster than a single large story.  Though the same amount of work may be occurring in either case, the negative effect on a team’s moral as a single dominating story sets in the ‘In Progress’ column for the majority of the sprint cannot be understated.  A vibrant board not only helps a team maintain a feeling of forward momentum, but it also encourages stakeholders to take an interest in checking the board each morning to see the progress the team has made.

An example of a theme

themeWhile the example above provides a great demonstration of an epic, themes may still be a bit unclear.  Let’s look at an example of a common piece of work that can often be represented as a theme—performance tuning.

Improving the performance of a specific feature of an application often involves making many small improvements towards the end goal of a significant performance improvement.  For example, imagine that your application includes a report to display the total sales numbers per salesperson.  These numbers may be calculated as of the previous day.

This can be a time consuming report to execute, and as a result the entire application tends to hang for several seconds each time a user runs it.  There may be several things we can do to improve this report, which are captured below as stories…

  1. “As a Salesperson, I’d like for the UI of the application to remain responsive while the report is loading, so I may cancel the report if desired.”
  2. “As a Developer, I’d like to pre-aggregate and cache the sales numbers as of the previous day, so they do not need to be recalculated each time the report is ran.”
  3. “As a Developer, I’d like to generate the HTML table containing the sales numbers on the server and send it pre-rendered to the client, so it no longer has to be rendered by JavaScript on the client.”

Each of these stories has the potential to improve the performance of the report.  However, while each story contributes to the same overarching goal they do not need to be completed in a specific order.  Furthermore, each story could be delivered independently from the others and still provide some measurable benefit to the end user.

For these reasons these stories are best grouped into a theme rather than an epic.  Grouping these stories by theme allows us to see the broader goal that each story contributes to without forcing us to approach the stories in a specific order.  Also, grouping the stories as a theme also negates the need to hold delivery of the entire group until each story is complete.  This give us more flexibility in scheduling and planning as well as in our ability to add and remove stories as the shape of the backlog changes.

In closing

We’ve taken a closer look at each of the Scrum artifacts of stories, themes, and epics as well as dove into the strengths and weaknesses of each.  In addition, we've looked at examples of using each type of artifact in practice to better illustrate when it may be the appropriate choice for a situation.

The choices of stories, themes, or epics bring an incredible amount of flexibility to a Scrum team.  This flexibility can be realized not only in the creation and grooming of the backlog but also into the planning of each sprint.  As a result of having a clear understanding of the differences between each artifact, as well as the flexibility to choose the right vehicle for each situation, teams can dramatically improve the accuracy of their sprint planning sessions.  This increase in accuracy can greatly improve the perception of a team’s success in the eyes of stakeholders, which can go a long way to improving their overall odds of success when adopting Scrum.

 

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 Stories versus Themes versus Epics

Using Hit Rate to Gauge Success

Velocity usually isn’t the best measure of a team’s progress. Instead, we often find accuracy to be a better indicator of a team’s long term success. Since many teams still find value in having a metric with which they can plot their success, why not use one that measures how accurate they’re becoming?

dartboard_three_darts_bwI've mentioned before that velocity isn't the best measure of a team's progress.  Instead, we often find accuracy to be a better indicator of a team's long term success.  Since many teams still find value in having a metric with which they can plot their success, why not use one that measures how accurate they're becoming?

Hit Rate is a simple metric that describes a team's accuracy over time.  In particular, it measures how close a team's forecasted velocity is coming to its actual velocity each sprint.

We can calculate it using the simple formula below…

Hit Rate = \frac{V_{Actual}}{V_{Forecast}} \times 100

Let's Try Some Examples

Imagine that a team forecasted a velocity of 20 points for the first sprint. However, one of the stories turned out to be a bit more difficult than expected which slowed down their progress. In the end, they only completed 17 of the 20 forecasted points. Let's plug that into our Hit Rate formula to see how they did…

Hit Rate = \frac{17}{20} \times 100 \approx 85\%

This tells us that the team had a Hit Rate of 85…or that they hit 85% of the velocity they originally forecasted. Note that the \times 100 at the end of the formula is only there to give us a nice percentage to work with.

Let's try another one.  Imagine that the next sprint the team forecasted a velocity 18 points, but two of the stories turned out to be a simpler than expected.  This allowed them to finish early, which let them pull an additional story into the sprint.  The end result was that the team completed 2 more points than originally forecasted.  Let's plug these numbers into our formula to see how this windfall affected their Hit Rate…

Hit Rate = \frac{20}{18} \times 100 \approx 111\%

This time we see the team had Hit Rate of 111%, which means that they actually completed 11% more work than originally forecast.

Hit Rate as a Trend

HitRate_w_lineIf either of these cases sound familiar it's because they're quite common in young scrum teams.  In fact, if you track Hit Rate from a project's outset you'll likely see a pretty erratic pattern in the beginning.  However, if you're willing to pay attention to and learn from your Hit Rate, you should start to see it settle near 100% over time.

What Your Hit Rate Can Teach You

Although some occasional wavering in your Hit Rate is to be expected, sharp trends away from 100% can reveal much about a team's tendencies.

For example, is your Hit Rate consistently trending down?  If so, then the team is likely overcommitting to the amount of work they can complete each sprint.  Work with them during Sprint Planning to keep the lowest priority stories in the backlog rather than bringing them into the sprint.

What if your Hit Rate is consistently trending up?  This likely means that the team can take on more work than they're selecting at the Sprint Planning meetings.  Work with them to gradually bring in a bit more work each sprint until the Hit Rate closes in on 100%.  This will build their confidence and help them see what they're really capable of.

Using the Hit Rate as a Guide

Even after a team begins to close in on a 100% Hit Rate they still may show some occasional variance.  While intermittent variance is no cause for concern, a consistent pattern of moving away from the 100% line in a certain direction should raise your eyebrows.  If you're tracking your Hit Rate then this should be easy to spot before it gets away from you.  However, if you do find yourself in this situation then just refer to the Actual Velocity from your last few sprints.  You can use this number to reset the team back to a more reasonable forecast during your next Sprint Planning.  With the Hit Rate as a guide it won't take long to get back on track.

If You Must

Although metrics can be a helpful gauge of a team's progress, we should always remember that they're no replacement for simply getting to know your team and understanding the specific events surrounding each sprint.

However, sometimes it's nice to have a guide that can call out areas where your team can still improve.  If you must use a metric, then Hit Rate is the one to look at.

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 Using Hit Rate to Gauge Success

Velocity Is Not the Goal

Teams that post consistently high velocities are often treated as valuable to the organization. However, those teams that tend to be more erratic…posting a high velocity one sprint then falling off dramatically the next…may not be as valuable as they may first appear.

“ve·loc·i·ty (n) – a measure of how many points a team completes during a sprint.”

On velocity

Velocity is often the first scrum metric we encounter.  It's a quick way to gauge how many points a team completed during the previous sprint, and how many they'll likely complete in the next.  It's clean, simple, and easy to understand.  It's also easy for people to get attached to.

On predictability

Teams that post consistently high velocities are often treated as valuable to the organization.  However, those teams that tend to be more erratic…posting a high velocity one sprint then falling off dramatically the next…may not be as valuable as they may first appear.

The reason is that velocity isn't as valuable as predictability.  Much of what we do in agile is done with the aim increasing the predictability of our team.  The more predictable a team is, the more effectively we can plan into the future.  This lets us take risks more intelligently as well as formulate more realistic strategies based on what our teams can likely deliver in a given timeframe.

Teams that post high velocities followed by low velocities are very erratic, and thus can't be planned for.  And if a team can't be planned for, then its value to the organization declines.

What's the harm in an erratic velocity?

Erratic velocities can lead to difficult planning for any team.  Not only long term release planning, but even short term sprint planning will suffer since the team won't be able to accurately forecast how many points they can complete during a given iteration.

If your team is experiencing erratic velocity, then it may be time to look upstream at your estimating process.  Often unpredictable velocities or missed forecasts are the result of poor estimates at sprint planning time.  Even exceeding your forecast can be a symptom of over-estimating the amount of work selected for the sprint.

Regardless of whether your estimates are missing up or down, your planning process is suffering.

So what's the goal?

If velocity isn't the goal, then what is?

Regardless of the hype surrounding ‘fast' agile teams, at the end of the day agile is often more concerned with predictability than speed.  Posting a high velocity for one sprint isn't helpful if your team can't sustain it.  However, posting consistent velocity numbers goes a long way towards great planning.

Does this mean that a team shouldn't strive to produce their velocity?  Not at all, it means that improving a team's velocity shouldn't be its goal.  Instead, the team should focus on what it takes to improve that velocity.  Practices such as continuously improving the engineering process or systematically identifying and chasing out risk will naturally result in higher velocity.

Focus on these things and the velocity will come.

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 Velocity Is Not the Goal

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