Jeremy Jarrell

Agile Made Simple

Tag: sprint

Creating Great Sprint Goals

This post originally appeared on the PivotalTracker blog. Let’s try an experiment. Open your Sprint Backlog and take a look at the stories that are slated for your current Sprint. Do…

This post originally appeared on the PivotalTracker blog.

Let’s try an experiment. Open your Sprint Backlog and take a look at the stories that are slated for your current Sprint. Do you see a theme that ties each of them together?

Too often, the set of stories that teams select for their Sprint has no overarching theme or focus. In fact, while these stories may be individually valuable, at times their selection can appear almost random.

But high-performing agile teams begin each Sprint Planning session by defining an overarching goal that they would like to accomplish by the end of that Sprint. This shared planning helps the team select a cohesive set of stories that will help them reach that goal. However, there’s also another advantage to crafting a great Sprint goal.

A great Sprint goal helps your team understand *why* it’s embarking on the Sprint in the first place. This context not only better positions your team members make more informed decisions during the sprint, but it also gives them guidance in the event that they need to adjust their Sprint plan during the Sprint to react to unexpected developments.

How Are Great Sprint Goals Crafted?

Crafting great Sprint goals is easier than you may think. The best time to craft your Sprint goal is at the beginning of each Sprint Planning session. Doing this at the outset will help set the context for what the team will be tackling over the next Sprint and better equip your team to select the stories that will support that goal. While the process of crafting a sprint goal is typically led by the Product Owner, ideally the entire team should be involved in this process. This will create a shared understanding of the goal that the team is trying to accomplish and create buy-in towards that goal.

When crafting your Sprint goal, remember that the best goals are specific enough that there will be no ambiguity as to whether or not the team accomplished the goal, but also are not so specific as to constrain the team’s flexibility to adapt their Sprint plan in pursuit of deciding how to best achieve that goal.

For example, *Increase the number of social login options available to the user* is a great example of a Sprint goal, since it defines a clear direction but leaves the flexibility to the team to decide how to best achieve that goal.

As another example, while *Improve the long-term maintainability of the reporting framework* is a great Sprint goal, *Reduce technical debt* is not. This is because while the former gives the team a clearly defined and high-level objective to aim at, the latter is vague and tough to quantify. This can make it hard for the team to clearly decide at the end of the Sprint whether or not they actually achieved their goal.

Planning From the Top Down

So where do Sprint goals come from, you ask?

When first creating a Sprint goal, many teams are tempted to just select stories as usual during their Sprint Planning session and then simply derive a Sprint goal from any common themes they spot in those stories.

While at first, this approach may seem better, it often leads to vague Sprint goals that merely describe the lowest common denominator found in every story selected for that Sprint. As a result, it can be hard to quantify whether these goals were achieved at the completion of the Sprint or even whether completing the goal actually yielded any value to the organization and the overarching release.

The best Sprint goals are often derived from your overarching release goals. Specifically, if you’ve defined a high-level goal for your release, you can begin by decomposing that goal into roughly Sprint-sized chunks, of which each chunk will become the starting point for a Sprint goal. Don’t worry if you’re not sure how to decompose your high-level goal into Sprint-sized chunks as this is a great opportunity to involve your technical team early so they can help you understand how large each chunk of work is likely to be. Not only will this increase the likelihood that your initial chunks of work fit together well, but the early involvement of your team will also help to create a shared understanding of what the goals of the release are, as a whole.

Seeing the Bigger Picture

Crafting clear Sprint goals helps your team understand how the work they are doing in each Sprint is a part of something bigger. Helping your team see the bigger picture not only equips them to make better-informed technical decisions during the Sprint, but it also gives them valuable insight into the overall vision for their product as well as how the work they are doing today contributes to that vision.

Curious to try this for yourself? Invite your team to collaborate with you during your next Sprint Planning meeting to set a Sprint goal that moves your team closer to success. Then, after the end of that Sprint, let us know in the comments below how it went! I’d love to hear how this worked for you and your team!

Want to learn how to deliver the work that matters most to your users? Check out my course series, Using the Scrum Framework from Pluralsight, to learn how to set yourself apart as a Scrum Master or Product Owner and to help your team reach their highest potential.

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

No Comments on Creating Great Sprint Goals

The Destination Is The Goal, Not The Journey

Many organizations try to measure a team’s progress by their velocity, or at least, to conflate their velocity with their goal. But, velocity is not their team’s goal. A team’s…

Many organizations try to measure a team’s progress by their velocity, or at least, to conflate their velocity with their goal. But, velocity is not their team’s goal.

A team’s goal should be a specific and measurable piece of business value that the team plans to deliver within a certain timeframe. For example, some great ideas for goals might include a new feature set that sets your product apart from its nearest competitor or a fresh look and feel and for an older feature set. Or, rather than being user-facing, a valuable goal might the delivery of a new capability or service that’s useful to the rest of the organization, such as a significantly improved build pipeline.

Whatever the goal may be, high-performing teams clearly define the goal that they intend to achieve at the outset of each sprint so they have a shared understanding of the objective that they will all be striving towards.

Velocity is different

Velocity, on the other hand, is simply the sum of the estimated effort that the team completed during the sprint in pursuit of their stated goal. For example, imagine that during the last sprint your team completed the following stories:

  • Story A: 3 points
  • Story B: 8 points
  • Story C: 5 points
  • Story D: 1 point
  • Story E: 1 point

Based on this list, we know that your team had a velocity of 18 points in the last sprint.

Was your team’s overarching goal to deliver 18 points the last sprint? Probably not. Most likely, your team’s goal was something that held the promise of a more tangible piece of business value, such as a social sign-on capability to encourage more users to create accounts, or a streamlined build process.

The 18 points of velocity that your team achieved during that sprint was nothing more than a byproduct of the progress that they made towards their goal. This is because, by itself, the act of delivering 18 points yields no value to your organization. At it’s best, it might serve as a correlation to the value that your team produced during the same timeframe, but only if you assume that your team had only selected high-value work to tackle during that time.

Making this stick

If this sounds familiar to you, then you’re not alone. Most agile coaches find themselves repeating this point on a regular basis. But, despite how many times most organizations have heard this story, it simply never seems to stick. So, in hopes of making this stick, let’s look at an analogy to this problem based on another problem that you probably already intuitively understand.

Imagine that you’re planning a trip to the beach with your family. Your entire family has been looking forward to this trip and are anxious to arrive. However, the beach is far from your home and it will take most of a day to drive there.

You’ve done some initial planning using your GPS and have discovered that the beach is 520 miles from your home. You also know from your experience with previous, similar trips that you can cover about 65 miles per hour in your car. This means that, roughly speaking, it should take you about 8 hours to drive your family to the beach…or 520 miles divided by 65 miles per hour.

If you relate this problem to our previous discussion then it should be easy for you to recognize that your goal is to arrive safely at the beach. The 520 miles between your home and the beach is simply an initial estimate of the effort required to achieve that goal. And finally, the 65 miles that you expect to cover per hour is your forecasted velocity per hour, based on similar trips in the past.

Simple right?

Simplicity, meet reality

If you’ve ever taken a long-distance trip then you probably know that trips are rarely as simple undertakings as they first seem. Although we may start our trip with the best-laid plans many unexpected events often emerge to disrupt those plans.

For example, your initial estimate of a traveling speed of 65 miles per hour most likely assumes that the majority of your time will be spent traveling at a constant speed on the interstate. But, few of us are lucky enough to have an interstate that runs directly from our front door to our favorite shoreline. As a result, you’ll most likely have to spend a bit of time at the beginning of your trip and the end of your trip traveling on secondary roads. This means that you should expect to travel less miles than you’d originally planned during those times, which means that you should also expect some variation in your speed throughout your trip.

In addition, even the most ambitious amongst us wouldn’t attempt an 8 hour trip with our families without a few short courtesy stops for everyone to stretch their legs. In fact, most of us would even grant a longer stop for lunch.

But most importantly, every great travel planner knows to expect the unexpected. Traffic jams, road closures, out-of-the-way detours, or even inclement weather can all emerge to slow you down while pleasant surprises like unexpected shortcuts can give you a boost in the right direction.

Any trip offers the possibility of unexpected developments, any one of which could affect your overall travel time. In fact, the longer the trip, the more possibility there seems to be for those plans to go awry.

Remembering the goal

If you’ve ever taken a long trip, then none of the twists that I threw at you in the example above would have been surprising. Difficult road conditions? Sure. Inclement weather? Of course. Unexpected stops along the way? Absolutely.

But, if you’re like most people, when I gave you my first estimate of 8 hours of travel time, which I arrived at by simply dividing our expected effort by our average forecasted velocity, these types of issues were probably the furthest thing from your mind.

However, even with those unexpected developments, if you arrived at the beach safely then you’d likely still consider the trip a success. This because arriving at the beach is your ultimate goal, not the trip to it.

If your goal had simply been to drive 500 miles in your car, then you could have just driven 250 miles in one direction out of your front door, turned around, and drove 250 miles back. Or, if your goal had only been to spend 8 hours in your car, then you could have just driven in circles around your block for 8 hours.

When applied to analogy like this the idea of driving circles around your block for 8 hours and considering that a success seems ridiculous. “Of course I wouldn’t do that” you say, “the goal was to get to the beach…not to spend some arbitrary number of hours in my car driving aimlessly.”

But if this is the case, then why is it that so many organizations judge the success of their teams only on whether that team closed an arbitrary number of points in a given a timeframe with little regard for the work the team ultimately produced while earning those points?

The next time your organization holds a sprint review in which the focus is solely on the number of points closed rather than the value that those points delivered, remember: the destination is the goal, not the journey.

Want to learn more about how to make agile work on real teams? Check out my course, Agile in the Real World from Pluralsight, for tips and techniques to help your organization get the most out of their agile adoption.

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

No Comments on The Destination Is The Goal, Not The Journey

My Team Works Hard But We Never Seem To Finish. Why Not?

We’ve all experienced this. Your team seems to be working hard. In fact, you know your team is working hard because you’re right there in the trenches with them. But,…

We’ve all experienced this. Your team seems to be working hard. In fact, you know your team is working hard because you’re right there in the trenches with them. But, no matter how hard your team works, they never seem to actually get anything finished.

If this sounds familiar, then you’re not alone. Most teams face this problem at some point in their development. However, despite how common this problem is it’s actually quite easy to overcome.

Why It Happens

To overcome this problem you first have to understand why it happens, in the first place. Most often this is due to two reasons.

First, it can happen because your team is accepting work from outside of the Sprint. This is the “can’t wait” work that wasn’t planned for during your team’s Sprint Planning, but reared it’s head after the Sprint has begun. Sometimes this happens because the Scrum Master is unable to head off a major stakeholder. Or sometimes the Scrum Master simply can't make that stakeholder understand the impact that this new work will have on the team’s outcome. Or even other times, the Scrum Master may not even be aware of the unplanned work, in the first place.

But regardless of the reason, if your team is spending time working on unplanned work instead of the work they had planned for the Sprint, then they may look busy but they’re unlikely to finish what you expect them to.

Second, it can happen because your team is working on too much work at once. This can be counter-intuitive at first, but if your team decides to tackle all of their work at once then the team will make surprisingly little progress on any of their work. This is because the team’s total effort will be spread across a much wider surface area resulting the in team making very little forward progress.

In addition, on many teams when the amount of work in progress is not closely tracked, it can be common for some individuals to begin work on one item and then move to a second item before the first item is complete. Once again, this can create an image of very busy individuals on a team, but with very little actual work in result.

Luckily, there are solutions for both of these situations that will get your team back on track and back to finishing the amount of work that you know they’re capable of.

Make It Visible

In the first case, where the team is continuing to work on items outside of the Sprint, work with your team to craft a clearly defined Sprint Goal that describes the goal that the team should accomplish with the work in the next Sprint. Once your team is in agreement about the goal, share the goal with your stakeholders so that everyone understands what your team plans to accomplish during the next Sprint and how this Sprint Goal contributes to your overall product goals. Then, when outside work begins to appear during the Sprint, you can work with your stakeholders to evaluate how that work maps to the goal the team has selected for the Sprint and what effect accepting the work may have on that goal.

If you’re still unable to prevent the work from being worked on during the Sprint, then make a special effort to estimate the newly accepted work and add it the Sprint board. You can even dedicate a reserved row of the Sprint board for this type of work, or use a different colored card so the unplanned work is immediately obvious. This visual differentiation will make visible the impact that the unplanned work is having on the work that was originally planned in pursuit of the Sprint Goal. In addition, the estimated points will allow you to better communicate to your stakeholders during the Sprint Review what percent of the team’s effort was spent on work that didn’t directly contribute to the Sprint Goal.

Both of these actions will help your stakeholders stop thinking of the Sprint as an empty bucket that work can simply be poured into, and instead begin to think of the Sprint as a strategically planned batch of work that moves the team closer to a stated goal.

Limit Your Throughput

In the second case, where the team is working on too much work at once, work with your team to establish work in progress limits, commonly known as WIP limits, on the key states of your Sprint board.

A WIP limit restricts the number of items that can be in a given state at any time. For example, in the image below, a WIP limit of 3 has been assigned to the Development column and a WIP limit of 2 has been assigned to the Testing column. This means that at any given time, no more than 3 items can be in development at one time and no more than 2 items can be in test at one time.


What happens if the WIP limit is reached? Then your team must work together to figure out how to complete the items in the column where the limit has been reached to make room for new work, thus allowing more work to flow through the process.

For example, imagine that a developer on your team completes the an item and attempts to move it to the Testing column. However, the Testing column has already reached its limit. The developer must work with your team’s testers to understand how they can help clear the existing the items from the Testing column. This may mean that the developer needs to assist the tester with their work so they can complete the items currently waiting to be tested, or that that team as a whole needs to make a greater investment into automated testing so that the testing process is more efficient overall. Regardless of the solution, the new item cannot be added to the Testing column until the existing items have been cleared.

While at first, WIP limits may seem as if they would cause a team to move slower, the opposite is actually true. WIP limits incentive your team to move work to completion, rather than to simply start it. This results in more work being completed by your team which allows them to reach their goals faster.

Focus on Finishing

Many teams look busy but surprisingly few actually complete the amount of work that may be expected of them. But, by defining clear goals for each Sprint that your team can aim for, and then incentivizing them to focus on finishing the work required to complete those goals, you can ensure that your team actually delivers the value that your stakeholders expect.

Do you want to learn more about how you can help your team deliver work more efficiently? Check out my course series, Using the Scrum Framework, to learn how you can help your team reach their highest potential and deliver a great product to market.

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

No Comments on My Team Works Hard But We Never Seem To Finish. Why Not?

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