Jeremy Jarrell

Agile Made Simple

Tag: user stories

Using An Estimation Grid To Improve User Story Estimation

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

Estimation is tough.

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

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

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

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

Meet the estimation grid

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

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

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

Putting the estimation grid to work

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

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

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

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

Getting the most out of your estimation grid

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

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

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

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

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

Wrapping up the session

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

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

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

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

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

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

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

Writing Great User Stories For Developing APIs

I recently received a great question from a viewer of my Creating Effective User Stories course. The viewer asked how she should approach writing user stories for team who would…

I recently received a great question from a viewer of my Creating Effective User Stories course. The viewer asked how she should approach writing user stories for team who would be creating APIs. For example, should the user story be written from the point of view of the API, such as “As an API, I want to…”, or should the persona portion of the user story be dropped entirely, focusing instead on only the intent and the justification.

As more and more teams find themselves tasked with creating APIs this is becoming a very common question. But luckily, there’s an approach to writing these types of user stories that can still help the team understand the intent of these stories without sacrificing their essence.

APIs Aren’t People

Most of know that creating an API persona for these types of stories simply doesn’t feel like the right answer. But explaining exactly why this isn’t the right answer can be harder to put your finger on.

To better understand why this feels wrong we have to remember some of the goals of user stories. First and foremost user stories are intended to improve collaboration with your team. However, they also have additional benefits, as well.

One of these additional benefits is to help you understand how the features you are designing will benefit the intended users of your product. Note the keyword there: users. This is critical, since without first understanding the users of your product, you can’t hope to design the features that will yield the most benefit to those users.

Another additional benefit is that well-crafted user stories help you understand the ultimate value that each story will be creating. This can help you can better understand if that value is worth the investment required to bring that story to market as well as when would be the optimal time to make that investment.

Note that neither of these benefits are possible if you don't have a properly-crafted and realistic persona already attached to each story. The lack of a realistic persona not only impedes your ability to make the necessary prioritization decisions as a product owner, but it also deprives your team of the context they'll need to make better informed technical decisions along the way.

Defining A Realistic Persona

So if creating a persona named API isn't the right choice for these types of stories then what is? The best choice is to identify the persona who will ultimately benefit from the value that the story will deliver and then attach the user story to that persona.

For example, imagine that you are creating an API that allows for conversions between different currency units. As part of this story you would like to convert between the Euro and the US Dollar. You could write the story as follows:

“As an API,
I want to convert between the Euro and the US Dollar”.

While this user story does convey the action that you wish to accomplish it lacks critical context. Who needs to do perform this action…the API? That's not very helpful. And what about the why?

While this story does tell the team what you want achieve, it lacks the necessary context to help the team make better decisions in development as well as to help you decide where this story fits in your overall product strategy.

Understanding Who Stands To Benefit

Imagine that you discover that your API will be used by a commodities trading house. And furthermore, imagine that you have a persona called “Commodities Trader” who represents someone who trades global commodities. Let's revisit the story in this new light.

“As a Commodities Trader,
I want to convert between the Euro and the US Dollar,
so that I can better understand how the price of my target commodity will be affected by currency fluctuations.”

This version of the story gives us much more context to work with. For example, understanding that this conversion will be used for comparing currency valuations helps our team better understand what level of precision will be needed in their conversions. And understanding that this conversion is intended to be used for commodities trading gives you much more context as a product owner to understand where this story might fit in your overall product strategy.

For example, if the trading volume between the European Union and the United States is relatively low today then this story can probably be delayed in exchange for higher priority work. On the other hand, if this trading volume is currently high then your product would likely benefit from tackling this story sooner rather than later. And finally, since we now know who will be using the feature and why they will be using it, we now have more information to find other stories in our backlog that might complement this story and therefore should be delivered alongside of it.

Putting This To Work In Your APIs

Features should exist only to yield value to your product’s users and ultimately your stakeholders. And user stories should exist to give your delivery team the context they need to make better informed decisions along the way. But without a well-crafted persona attached to each user story, you risk investing your team’s effort only to deliver stories that completely miss the mark for both your users and your stakeholders.

Want to learn even more ways to get the most out of your user stories? 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.

No Comments on Writing Great User Stories For Developing APIs

How To INVEST In Your User Stories

This post originally appeared on the PivotalTracker blog. If you’re a product manager, user stories are a critical part of how you interact with your team. Nothing trumps a face-to-face conversation,…

This post originally appeared on the PivotalTracker blog.

If you’re a product manager, user stories are a critical part of how you interact with your team. Nothing trumps a face-to-face conversation, but the key to starting that conversation is a good story.

For example, imagine that your team is building an e-commerce site that enables college students to sell their books to other college students at the end of the semester. Rather than selling to an intermediary, such as a university bookstore, this site would let college students to sell their unused textbooks directly to their peers, thus allowing them to keep more of their profits. As a product manager, you might start the conversation with your team with this story:

As a college student

I would like to sell my old textbooks

so I can make money.

On the surface, this story seems to have all of the basic building blocks of a great user story. It clearly specifies a target persona that will benefit from the new capability described by the story, specifies what that new capability should be, and even describes what value the persona will receive from that capability.

But is this story enough to start the conversation with your team? What if there were a simple test that could tell you?

Meet INVEST

Luckily, there is a practice that can help, and it’s called INVEST. INVEST represents a specific set of qualities that mature stories tend to exhibit. Although not every quality will apply to every story, the more qualities that your story exhibits, the more likely it is to be ready for consumption.

So what are these qualities? INVEST represents these six qualities that are often considered desirable in a user story:

    • Independent: The story can be delivered independently of other stories. Note that this doesn’t mean that stories can’t have prerequisites, only that the stories may not be so coupled that they must be delivered in parallel.

 

    • Negotiable: While we prefer stories written in a clear and unambiguous language, stories should not be written to such a level of detail that they become overly restrictive and prevent your team from arriving at the best solution themselves.

 

    • Valuable: Every story that’s delivered should make your product more valuable—period.

 

    • Estimable: Every story should provide enough information to equip your team to make a reasonable estimate of that story’s complexity. This is because whether or not we can estimate a story’s complexity is often a great indicator of how well we actually understand that story.

 

    • Small: Smaller stories are easier for your team to understand and therefore are simpler to deliver. Plus, the smaller a story is, the less risk that may be lurking under its covers.

 

    • Testable: For each story that you write, you should be able to determine whether what was delivered met your expectations. To do this, the story must be written in a clear enough manner as to remove any ambiguity of what the end result should be.

 

Let’s look again at our story from before, but this time through the lens of INVEST.

As a college student

I would like to sell my old textbooks

so I can make money

For example, does “sell my old textbooks” describe a story that is small and independent? Perhaps not. Although this higher-level description does leave room for negotiation of how your team can best deliver the story, a more specific description may better enable that negotiation. What if you revised this story to better reflect how a college students may sell those textbooks?

As a college student

I would like to list my old textbooks for sale

so I can make money

This new version provides your team with a more refined vision for this capability that not only reduces the ambiguity and scope of the story, but also makes it more estimable because the team now has a better idea of what you have in mind. And because the story is now more clearly defined, it’s more testable, too.

But what about value? Is making money really the ultimate value that this story might yield to the college student? That’s definitely an end result, but this value statement doesn’t necessary add context to the story. Great value statements help your team better understand the why behind the story by providing clues to what a user might stand to gain after the story has been delivered. Let’s try to rework this story’s value statement to make that more clear.

As a college student

I would like to list my old textbooks for sale

so I can sell my textbook to the highest bidder.

That’s better. Your team now has a clearer understanding of what value the story will yield to the user once it’s delivered, which will provide clues to the complexity that may be inherent in this story. This additional context will better enable your team to negotiate tradeoffs that may allow them to deliver the story more effectively.

Getting more from INVEST

So now that you’ve seen what the individual qualities of INVEST are, let’s talk about how you can use INVEST to improve the quality of your own stories. To do this, we’ll start by talking about what each of these qualities has in common.

First, notice that while each of these qualities asks for a simple “yes” or “no” answer, how you arrive at that answer is subjective. For example, is your story valuable? Before you can answer yes or no, you must first define exactly what value means to your product as well as how that value will be measured. What about negotiable? Is your story negotiable enough? Once again, it’s up to you and your team to agree on how you strike the balance of defining your stories clearly enough so that they’re unambiguous, but not so well defined that they restrict your team’s creativity. This fostering of a deeper discussion across your entire team is the magic of the INVEST technique at work.

Next, notice that many of the INVEST qualities seem to support other qualities. For example, smaller stories naturally lead to more testable stories because smaller stories naturally become more concise and less coupled to other stories. Additionally, smaller stories also tend to be more estimable because these stories are naturally easier for a team to understand.

But not all qualities set up such a natural, virtuous circle. In fact, some qualities act as a balancing force to other qualities. For example, while in general we may prefer smaller stories, we don’t want to create stories that are so small that they don’t yield any meaningful value. For example, we want to avoid breaking stories into such small pieces that each piece is too small to move the product forward on its own.

Putting INVEST to work for you

Ensuring that your stories adhere to the qualities described by the INVEST technique can result in significant improvements to not only your stories but also your own communication with your team. But where should you start?

It would be unrealistic to expect that every story in your product backlog conforms to INVEST. Not only would this be time consuming, but overinvesting your time in stories further down your product backlog might also discourage you from changing those stories as you learn more about them in the future. Instead, INVEST is most appropriate when applied to those stories that are on deck for your next iteration. At this stage, you can be reasonably confident that you’ll make the investment in delivering those stories and you will have also learned more about those stories from your experience in previous iterations. At this point, it makes sense to spend the extra time ensuring your stories adhere to the INVEST qualities to improve your communication with your team.

By applying INVEST to those stories that are on deck for your team to deliver—and applying this technique at the right time—you can dramatically improve the level of communication between you and your team, which will dramatically improve the quality of the product that your team ultimately delivers.

Want to learn more ways to help your team get the most out of user stories? 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.

No Comments on How To INVEST In Your User Stories

The Case for Eliminating Epics

It should come as no surprise that the smaller the pieces your team can break their work into, the better chance they’ll have at succeeding at that work. After all,…

It should come as no surprise that the smaller the pieces your team can break their work into, the better chance they'll have at succeeding at that work. After all, smaller pieces not only reduce the risk associated with your work, but they can also be easier for your team to understand.

In fact, breaking work into small pieces is so beneficial for your team, that most agile methodologies is to do everything possible to encourage you to do so.

But, despite all of the obvious advantages of breaking work into small pieces, teams who are new to agile still find themselves hiding large pieces of work inside of epics.

To be fair, epics aren’t inherently evil. They can be a great tool for storing loosely defined work on the product backlog, or for grouping smaller and related pieces of work in a logical way. In fact, there are quite a few perfectly valid uses for epics.

What’s Wrong With Epics?

Unfortunately though, many teams tend to use epics as way to enable their bad habits. In particular, epics can encourage poor refinement of ideas by enabling people to capture details in epics that they would otherwise consider too poorly refined for a normal user story. This can result in poorly refined stories being hidden on the product backlog, under the guise of epics.

While at times this can be acceptable, the trouble arises when epics are slated for teams to work on during a sprint rather than slating the individual stories that comprise those epics. This is because while it can be perfectly acceptable to load the component user stories of an epic directly into a sprint, the epics themselves should never be loaded as a sprint level item.

Loading an epic directly into your sprint allows you to hide larger work inside of your sprint than would otherwise be acceptable. And, when work is not broken down appropriately before loading it important details become much more likely to fall through the cracks and missed by your team.

This can result in vague and poorly defined work which can be tough to prioritize.

So What Should You Do?

Remember that epics are just another type of user story. Don’t lower your bar of what’s considered acceptable for an epic just because it’s larger than a normal story. Instead, simply consider an epic to be a story that’s been refined to the point that’s most appropriate for where that story is at in its lifecycle at that time. This may not mean that an epic should adhere to the same Definition of Ready as a typical user story, but some level quality should still be applied to it.

However, if your team still seems to struggle with understanding what the appropriate level of refinement is for an epic, it may be time to eliminate them from your toolbox until your entire team has a better understanding of how to get the most from this particular tool. This doesn’t mean that epics will never be appropriate for your team, but until everyone has a better handle on how to use them appropriately it may be time to take them off the table.

Want to learn how to get even more out of  user stories? 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.

No Comments on The Case for Eliminating Epics

Putting Value First With The Reverse User Story

User Stories are a great way to translate your users’ needs into real tasks that your team can work with. They’re succinct, lightweight, and flexible. But what if you could…

User Stories are a great way to translate your users’ needs into real tasks that your team can work with. They’re succinct, lightweight, and flexible. But what if you could make them even better by moving the “why” of the story to the beginning?

To understand how you can improve them even further, let’s start by looking at an example of a User Story…

User Story format

This format answers the important questions clearly, but it keeps the most important part of the story…the benefit…until the end. The benefit, or the “So I can…” part of the story, is how you ensure that your team understands why they are building this story and how it will contribute to your overall vision for your product. Without clearly stating this benefit you risk adding functionality that doesn’t move your product towards its vision.

Saving this part of the story until the end means that we ignore it or even leave it out completely. The result of this is that the benefit of the story is shortchanged.

Turning the Problem on Its Head

The Reverse User Story, on the other hand, moves this important clause to the beginning of the story.  This format, inspired by the Reverse Stand Up, recognizes that the benefit is the most important part of the story and therefore it should appear first.  Building on the example above, our Reverse User Story would look like this…

Reverse User Story formatMoving the benefit to the beginning of the story forces your team to first think about the business value and resulting benefits of your work. If you’re unable to articulate a benefit for a story then this can be a warning sign that you don't understand the story as well as you thought you did. This may mean that the story still needs fleshing out or even that it may not be worth the effort required to bring it to fruition.

Finding Balance…Or the Zen of Release Management

Bringing the expected benefits to the forefront can also aide in long term exercises like Release Planning. For example, if the majority of stories selected for a release seem to have similar benefits then this can be a hint at the theme that’s emerging for that release. Alternatively, if too many stories have the same benefit then this can serve as a warning that you’re weighing the release too heavily towards one specific feature set while starving another.

Shifting the focus to the benefit can also help identify stories in the backlog that are duplicating value. Recall that one of the goals of Scrum is to optimize the ROI of the development team. To this end, if more than one story is accomplishing the same end goal then this can be an opportunity to drop a duplicate story in favor of another that may bring more value to the product.

Drawing in the Team

Bringing the business goals of the story to the forefront draws the team into the discussion.  This can even lead to the discovery of alternative approaches as to how those goals may be met.

For example, recall that the original idea of your story was to allow a customer to save items for later.  You'd assumed that the only way to do this was to make their shopping cart persistent.  But, perhaps someone on the team suggests instead providing a wishlist where the customer could store items for long term. This would result in the story being changed to…

So I can save items for later,
As a customer,
I want to add items to a wish list.

This change may even spawn additional conversations regarding the opportunities that the wish list could open up. Perhaps the customer could share their wish list with friends who are shopping for them.  Or, maybe they could even post them to their social networks. This would give you the opportunity to also capture sales from friends of the customer.  This could even happen when your original customer isn’t quite ready to buy an item themselves.

None of these ideas would have ever been suggested if the developers had not first been encouraged to consider the overall benefit they were trying to achieve rather than simply focusing on the action.

Putting This Technique to Use

Though a Reverse User Story has many advantages over the format it still may not be right for every situation.  Specifically, the classic format’s simplicity and broad adoption make it a good choice as a starting point for introducing the concept of User Stories to new teams.

But, if your team seems to be missing the bigger picture of the stories or is becoming mired in the details then this twist on the classic format may be just what you need to shift everyone’s focus away from specific actions and back to the overall goal of the product.

Want to learn even more neat techniques to get the most out of User Stories? 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.

No Comments on Putting Value First With The Reverse User Story

What’s the Right Amount of Backlog Refinement?

Many teams struggle with getting the right level of detail in their backlog.  If the backlog is too vaguely defined, then the team picks up stories that aren’t immediately actionable…

Many teams struggle with getting the right level of detail in their backlog.  If the backlog is too vaguely defined, then the team picks up stories that aren’t immediately actionable which can slow them down.  On the other hand, if the backlog is too well defined then it becomes rigid and fails to evolve as the product takes shape.  It can even stifle the creativity of the team as they try to find the best option for achieving each outcome.

So, how do you strike the right balance when creating your own backlog?  In his excellent book Scrum Product Ownership, Bob Galen introduced the 20/30/50 Rule for product backlog refinement to address this very problem.

Here’s how it works…

The First 20 Percent

20% of the stories on the backlog should be well refined and ready to be picked up at any time.  These are the stories that are immediately actionable that your team can begin work on with little hesitation.  You and your team will need to agree on exactly what makes a story actionable for them, but here are a few options to consider as a starting point….

  1. Each story has a stated objective and corresponding business justification.  While this is often expressed in the popular format “As a…., I want…., So that…” format, the specific format isn’t important as long as the team knows what they’re trying to accomplish and why they’re trying to do so.
  2. Each story has defined acceptance criteria to give the team a clear and unambiguous picture of what the end state of the story should look like.
  3. Each story meets the agreed to Definition of Ready established by your team.  If your team has yet to establish their own, then the INVEST criteria is a good place to start to consider which qualities of stories are important to your team team which may not be as important.

The Next 30 Percent

RefinementThe next 30% of the stories on the backlog aren’t ready to be picked up by your team, but are in a good enough state that you as the Product Owner can have a discussion about these stories with your team and stakeholders to decide when these stories should be worked on…if ever.  

Expect these stories to contain no more than an objective and business justification and to be sized larger than the first 20%.  In fact, it’s not uncommon for many of these stories to simply exist as unrefined epics.  The goal for stories in this bucket are to pin a specific idea to the backlog so that it’s not lost as well as to facilitate a discussion around when it would make sense for the team to invest in tackling that story.  If the story is not specific then this discussion will meander and won’t be productive, but, if the story has already been too well defined then the creativity that would otherwise emerge from that discussion will be stifled.

The Final 50 Percent

The final 50% of stories are the least refined of them all.  These stories tend to be largest stories on the backlog and exist only as vague ideas of things the team would like to consider for the future.  If the previous set of stories tend to be at the Epic level, then these items are the Themes of your backlog.  

These stories are not ready for a team to work on and really aren’t even ready for a team to discuss.  Instead, these stories exist as placeholders for the Product Owner to periodically evaluate whether they still make sense for the direction of the product and, if they do, to begin to introduce them to the discussion.

Finding What Works

Structuring your backlog according to these rules of thumb will help you strike the balance between items that your team can be productive with immediately and items that still deserve more refinement.

Depending on your team and your product, you may find that you need to tweak the percentages to optimize the backlog for what works best in your organization.  You may also find that you need to experiment with whether these numbers correspond to the total remaining story points in your product backlog or to simply the total number of remaining product backlog items.  As with most opportunities in agile, experimentation will be the key to finding what works the best for your team.

However you decide to implement it, the 20/30/50 rule gives you a nice guideline of how much of your backlog should be ready at any time while keeping the risk of over refinement at bay.

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.

No Comments on What’s the Right Amount of Backlog Refinement?

Evil User Stories for Modeling Evil Users

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

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

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

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

You have stories modeling how they get the most out of every feature, how they find every benefit laid out for them, and how they squeeze your best intent out of every corner of your product.  Everything you've done has likely been with an eye towards taking care of your best users.

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

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

A Story of Evil

Evil user stories are just like normal user stories, except they model what a malevolent user wants to do in your product rather than what a benign user would do.  In every case, this is exactly what you want a user not to do inside of your product.

Why would you write stories that model exactly what you want a user not to do?  Because by understanding what an Evil User wants to do in your product, and more important why they want to do it, you can better understand how to defend against them.

Evil User Stories

Let's look at an example.

Imagine your product is an ecommerce platform that allows your users to buy and sell rare video game cartridges.  Buyers on your marketplace can pay with either their PayPal account or a credit card.

Now imagine that your community of rare video game aficionados has been discovered by a hacker.  This hacker intends to steal the credit card numbers of your users so he may sell those numbers on the black market.

You might write an Evil User Story to model this that looks something like this…

As a hacker, I want to steal the credit card numbers of my fellow users, so I can sell those numbers on black market.

This story is our starting point.  It helps us understand what a hacker wants to do and why they would want to do it.  But it doesn't help us understand how they may accomplish it.

With a bit of “evil brainstorming” we can probably think of a few ways to accomplish this.  One way would be to gain direct access to the database that backs our website.  This would give our hacker unfettered access to all credit card numbers in the site.  However, this would be difficult our hacker to do, and since we're most likely encrypting our credit card  numbers, the hacker would not be able to easily use his bounty, anyway.

Another option would be to break into another user's account where the hacker could pull that user's credit card number right from their billing information page.  This would be much easier than gaining direct access to our backend database and it would also give the hacker access to more of our user's profile information, such as the corresponding name and address associated with the credit card.

This seems like the most likely path our user would take, so let's refine our Evil User Story to reflect this…

As a hacker, I want to break into another user's account, so I can steal their credit card number.

Now that we have a better understanding of why a hacker would want to break into a user's account we can consider how to better defend against it.  For example, we could strengthen the authentication requirements for a user to log into their account…perhaps by requiring an alphanumeric password with at least 8 digits and special symbols or require two-factor authentication.  Alternatively, instead of complicating the authentication process we could decide to just never display the full credit card number to a user and instead display only the last four digits.  That way, if a hacker does compromise a user's account, then they'll never be able to access the full credit card number in order to steal it.

The important takeaway here is that, much like a normal user story, the most powerful part of an Evil User Story is the “so that” clause.  Once we understand the intentions behind a user's actions we can start to work backwards to understand the steps they may take to accomplish them.  It's these steps that we'll want to mitigate against.

Evil Personified

We now have our first evil user story focusing on hackers.  But “hacker” is a relatively generic term.  There are plenty of disgruntled people in the world who may wish to do harm to both our product and our benevolent users.  For example, imagine that early in the history of our company we hired an IT Admin named Victor.  Although Victor was a talented admin he just never seemed to fit with the rest of the team and eventually things turned sour and he had to be let go.  Victor's departure was nasty and although we may have forgotten about him, he's now back for revenge.

How will Victor take his revenge?  Well, he knows that what sets our ecommerce platform across is the depth of our inventory.  We're “the place” that people come to for hard to find classic console video games.  If our inventory were to suddenly disappear from our website then we would be sunk.  Unfortunately, Victor also knows exactly how our ecommerce administration portal works…and that we rarely disable admin accounts after employees leave.  To help us imagine exactly what Victor may try to do, we can model his intent with another Evil User Story.

As a disgruntled employee, I want to delete all of the store's inventory, so the store will appear to be out of stock on all items and will be unable to generate revenue.

Now that we understand exactly what Victor is trying to do we can explore ways to prevent him from accomplishing his task, just as we did with our hacker.

However, the key takeaway here is the addition of the Disgruntled Employee persona.  Just as with normal users, considering all Evil User Stories from the perspective of the generic “hacker” persona would limit our vision of how the product could be compromised and bias our perception to only a single use case.  Instead, just as we should create personas to represent all of the major types of users of our product, we should also create Evil Personas to help us explore all of the potential groups of users who may wish to do us harm.  Only by creating actual personas for each of these groups can be better understand their motivations and, ultimately, their methods.

Where Do These Stories Fit?

Unlike normal stories, Evil User Stories are unlikely to ever end up on our product backlog in their original form.  After all, we wouldn't want to invest time in adding the ability for Victor to delete our entire inventory in a single click.

Instead, we use these stories as the first part of the process towards modeling the potential threats that could apply to our app and brainstorming how to mitigate them.  It is the output of this brainstorming that ultimately makes its way onto our product backlog as stories.  For example, as a result of our previous two discussions we may add a story to obscure all of the last 4 digits of all credit cards to a user who is viewing their billing information.  Or, we may decide to add an automated alert to review all active admin user accounts in the system every 30 days to ensure that no former employees retain their access after leaving our company.

Putting on Your Black Hat

As Product Owners, we're often quite adept at considering all of the possible use cases where our product could bring benefit to our users.  We also tend to be quite good at considering our different types of users and what their different motivations may be.  However, how some of our users may actually intend to take advantage of our product is often a blind spot.  By considering their different motivations, and ultimately their means, we can better protect both our users and ourselves and from those less scrupulous users who may wish to do us harm.

Want to learn even more neat techniques to get the most out of User Stories? 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 Evil User Stories for Modeling Evil Users

The Choosers versus Users Dilemma

We often talk about our “customer”, they’re at the center of everything we do. But we rarely talk about who our “customer” may actually be. Often, we just assume that…

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

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

Kids are our Users.

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

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

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

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

Enough of This Consumer NonsenseThe Choosers versus Users Dilemma

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

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

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

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

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

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

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

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

So What Do We Do About It?

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

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

 

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

No Comments on The Choosers versus Users Dilemma

Splitting User Stories Across Teams

I recently received a question by email wondering if large user stories should be split across teams.  The question was so interesting that I thought I would summarize my response here. Sometimes large…

I recently received a question by email wondering if large user stories should be split across teams.  The question was so interesting that I thought I would summarize my response here.

Sometimes large user stories are broken down into smaller stories that are tackled by multiple teams.  For example, imagine that your organization has two teams: a team that owns your web application and a team that owns your mobile application.  If you are releasing a feature across both platforms you may originally start with that feature described as a single user story but then split the story in two as each team tackles their respective implementations.

When multiple teams work on a single product we like to keep a single Product Backlog that all teams share. This lets the Product Owner see the big picture at any given time which helps keep them focused on the overall vision for the product.

Even if a larger story that will ultimately be split across several teams we tend to keep it as a single story during the Product Backlog phase.  This helps to prevent us from getting mired in the weeds of each story too early and makes the story easier to move up and down the backlog as new priorities emerge.

Product Backlog

Keeping the story as a single unit also it makes it easier to assign an estimate to.  Admittedly, we know that the estimate won't be as accurate as if we broke the story down and estimated each individual part, but that's ok.  We accept that estimates are less reliable during this stage and only use them for getting an idea of the complexity of a story relative to other stories in the backlog.

Splitting User Stories During Sprint Planning

However, during Sprint Planning the top stories in the product backlog are moved into a separate Sprint Backlog for each team. At this point those same large stories are broken down and split into separate stories for each team, who then take this opportunity to estimate their individual portions. The sum of those estimates may add back up to match the original estimate of the large story, but don't be surprised if they don't.  Breaking larger stories down into smaller stories often tends to expose gaps that we didn't originally consider when the story was in its larger form, so new stories may emerge as a result.

Product to Sprint Backlog

Allowing each team to work from their own Sprint Backlog minimizes the number of dependencies each team needs to complete their work.  We want each team to have as many of the skills as possible to complete a valuable increment of the product during each sprint, which is one of the reasons why we strive to make scrum teams cross-functional.  If a team can still deliver a valuable increment themselves, then we want that work split only into the portion that they can complete.

In addition, Velocity is our primary planning metric in scrum.  Teams who estimate in story points eventually start to evolve those points to the range that makes the most sense for each team.  Put another way, a story point for one team may be wildly different than a story point for another team.  This flexibility is what gives story points their power as each team starts to assign the most accurate value to each point that makes sense to them.

The side effect of this, however, is that the Velocity of two different teams can start to vary wildly even if each team is completing roughly the same amount of work.  For this reason we want to be able to map a separately velocity to each team which better represents the amount of work they're completing during a sprint rather than trying to roll all velocities into a single number.  This gives us a more accurate representation of how much each team tends to complete during each sprint, which lets us plan the overall product even better.

Want to learn even more ways to split 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 Splitting User Stories Across Teams

How to Best Slice User Stories

Splitting large stories into smaller stories is one of the best things a team can do to improve their workflow. But how do we split these stories?

Thanks to Ben Godwin for a great email question that prompted this post!  If you have your own questions about agile and don't know where to turn, drop me a line for some free advice.

Learning to split large user stories into smaller user stories is one of the best things a team can do to improve their scrum workflow.  Not only are smaller stories easier to understand and therefore easier to estimate, but their smaller size makes them inherently less risky for a team to take on.

However, when teams first start splitting stories they’re often tempted to split them horizontally rather than vertically.  To understand what I mean by this, let’s take a look at an example.

Imagine that you had a story to allow a salesperson to log into a sales management application.  The story may look something like this…

 “As a salesperson, I would like to log into my sales management application, so I can enter my lead information.”

At first glance this story may look pretty simple.  However, as we start to unpack it we realize there are a few additional concerns here that we may not have thought of originally.  For example, what feedback will we give the user when they enter an incorrect password, or how many times can a user enter an incorrect password before their account is locked?

After these additional concerns have come to light this story may become too large of a story for a team to feel comfortable tackling.  Instead, they may decide to slice it into smaller stories that can be tackled one at a time.

Slicing User Stories Horizontally

In their first attempt at slicing, most teams will try to slice the story horizontally…or across architectural lines.  This might result in new stories that look like this…

  • Create a user interface with a username and password field that shows validation errors when the user enters an incorrect password or locks their account.
  • Implement the server side logic to validate the user's password and to keep track of how many successive incorrect login attempts the user has made.
  • Update the user record in the DB.  For example, update the last login date on a successful login or lock the account if the user makes three incorrect attempts.

Horizontally Sliced User StoriesIn the image on the right, we can imagine that the slice of cake represents the complete story of a salesperson logging into the application.  Each layer of the cake represents a corresponding architectural layer, from the user interface to the database.

Each rectangle overlaid on the image represents one of the story slices from above.  For example, the orange rectangle may represent the story to create the user interface while the yellow rectangle represents the story to implement the database changes.

Slicing stories horizontally is always a nice place for teams to start because it feels familiar to how developers think.  This is because we tend to decompose problems into technical layers.  However, it also mimics the structure of teams that have come from a more traditional environment.  Many teams are used to working in more siloed environments where they're split amongst a database team, a UI team, and a server team each of which is responsible for their own tasks.  Even when we break down the silos and bring those people together as part of a scrum team many of us still tend to decompose the tasks in the same way.

However, as easy as horizontal story slicing is to get started with it’s not without its drawbacks.  The biggest being that it encourages developers to specialize which lowers your bus factor.  It can also lead to the development team avoiding certain stories or leaving them to the end if they demand a skillset that none of the team feels confident with.  For example, if your team is composed entirely of strong server side developers with little experience on the user interface side then the story above about creating a user interface will likely be avoided by most team members.  Since no one on the team is particularly strong in this skill leaving this story until the end of the sprint makes an already risky proposition even riskier.

Slicing User Stories Vertically

The alternative to this is to slice the stories vertically.  This means that each story crosses all boundaries of the architecture but implements only a sliver a functionality each time.

Returning to our login example, if we slice the story vertically the new stories may look like this…

  • Add the ability for a user to login with a correct password.
    Includes adding the username and password fields to the user interface, implementing the happy path server side logic, and updating the last login field on the database record.
  • Prevent the user from logging in with an incorrect password.
    Updates the user interface to provide an incorrect password validation message and adds a negative path to the server side logic.
  • Lock the user's account after 3 incorrect attempts.
    Updates the user interface to provide a locked account validation message, tracks the number of failed logins either on the server side or in the database, and updates the database record to be locked.

Vertically Sliced User Stories

Returning to our cake analogy from before, we now overlay each rectangle vertically so each rectangle represents a story sliced vertically through the entire architecture.  For example, the orange rectangle may represent the story allowing the user to login with a correct password while the light yellow rectangle may represent the story which locks the account after 3 incorrect attempts.

The advantage to slicing our stories vertically is that each resulting story still provides some sort of meaningful value to the user.  This not only makes them easier to test, but they also become easier for the customer to interact with to provide feedback and guidance for our next sprint.  A customer can provide direction based on their experience with a partially completed login form, but they can’t with only a set of database tables.

Along these same lines, vertically sliced stories also tend to ease the pain when not we’re not able to complete all stories we planned on during a sprint.  In the example above, imagine that we completed the first two stories: allowing the user to login with a correct password but preventing them from doing so with an incorrect password.  However, we were unable to complete the final story which would lock the user’s account after 3 incorrect attempts.  It will be easy for a customer to understand the portion of the work completed versus the portion that’s not when it’s demoed to them.  This would not be the case with horizontally split stories where we had completed the server side logic to validate the user’s password as well as the corresponding database updates, but still had yet to complete the associated UI story.

This Won't Be Easy

Slicing stories vertically is consistently one of the toughest mind shifts for a team new to agile to make.  One reason is that this tends to lead to stories that are more complex and therefore a little tougher to estimate.  It also pushes some developers out of their comfort zone.  For example, if a particular developer is an incredibly strong server side developer but doesn't like to deal with UI issues then they're not going to feel comfortable estimating a story that includes UI work.  In fact, they may not even want to work on it when it comes up in the sprint.

But, if you can get over the initial hump, this technique actually has a lot of advantages.  One of the biggest is that it forces developers to get better at skills they may have been able to avoid in the past, which raises your bus factor.  For example, you're no longer in as much trouble if the “user interface guy” suddenly gets the flu the week before a big deadline.

Another advantage is that it teaches developers to think of features holistically rather than just in architectural slices.  The result is that while at the beginning the estimates may suffer, as the team gets better at thinking about each feature as a whole you'll start to get more accurate estimates over the long run since the team has a greater appreciation for a new feature's impact across the entire system.

Finally, delivering stories which slice through all layers of the architecture tends to make them more complete and therefore easier to test.  This means that you can get feedback on your features even sooner which, in the end, is the real goal.

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 How to Best Slice User Stories

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