Jeremy Jarrell

Agile Made Simple

Tag: user stories

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

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!

Using Personas to Give Backstories to Your Users

You already know that roles are crucial to any User Story since they help us put context around who a given feature is for. However, did you know that you can also put context around your roles?

You already know that roles are crucial to any User Story since they help us put context around who a given feature is for.  However, did you know that you can also put context around your roles?  Using a technique called Personas we can create rich backstories for our users to help us better understand not only their role, but also their goals for using the product.

Creating Personas

In my latest Pluralsight course, Creating Effective User Stories, I cover how to create these Personas using the excellent template created by Roman Pichler.  You can see an excerpt from the Personas portion of the course below as well as download Roman's template here.

Personas are an excellent way to better flesh out your team's image of the actual users who will be interacting with the product.  Not only do they help us better understand how a user will interact with the features of our product but, more importantly, they help us understand their motivations for doing so.

And, by better understanding both our users' motivations and backgrounds we can better build products that makes sense for them.

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 Using Personas to Give Backstories to Your Users

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

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